The Software Factory

Becoming AI-Native: Why AI Won't Fix Your Org Chart

2026-07-06T00:00:00-07:00

Going AI-native is not the same as switching AI on.

Most companies that say they are adopting AI just bolt it onto the business they already have. Same software. Same meetings. Same org chart, with an AI assistant wired to the side. They count success in logins. So far, the result is a company that costs a little more to run and moves about as fast as it did before — whatever a given team feels. If that is what your AI program bought you, you did not go AI-native. You bought a very smart fax machine.

The fax machine was a real upgrade. It also changed nothing about how the office worked. Bolting AI onto your company works the same way. To get more than a faster fax, you have to change the company, not just the tools it runs on.

AI won't fix your org chart

A company leaves its fingerprints on what it builds. How it is organized shows up in the product: who talks to whom, who owns what, how work moves from one desk to the next. There is an old rule about this from software. Conway's Law² says an organization can only build things shaped like itself. Put plainly: you ship your org chart. If two teams only talk through a formal handoff, the two things they build will meet through a stiff, formal handoff too.

AI does not change this. It just makes the building faster. Point AI at a tangled organization and you get tangled work, now produced at speed. A messy company with AI is still a messy company. It is only messy faster.

So the first thing is plain: AI will not fix your inefficiencies. A faster tool runs on top of the way you already work. It does not redraw it for you. If the company is slow because of how it is built, speeding up the pieces leaves that in place. That is the fax machine again. A different result takes a different organization, and no tool does that part for you.

AI doesn't sharpen skills — it swallows them

Most AI plans assume AI makes your existing people better at their existing jobs. A power tool for the same work. That is not what happens. AI does not sharpen a skill. It swallows it. The skill that used to be rare and valuable becomes something anyone can buy cheaply.

This is not new. It is what every important tool has done. The master craftsman spent a decade learning a trade by hand. Then the factory made that skill routine, and the value moved to whoever could design the production line. The same thing happened to programmers who could squeeze speed out of a machine by hand, until better tools did it for them. Each time, a hard-won skill turns cheap, and the people who built their careers on it feel the ground move.

A recent MIT study puts the current version well: AI automates skills, not jobs.¹ Any job is a bundle of skills. AI picks them off unevenly. It takes some, helps with others, and leaves the rest. So the change happens inside a job long before the title on the chart changes. The software coding everyone points to now is just the visible tip, about two percent of the economy's wages. The larger mass sits out of sight: the every-day thinking that runs finance, operations, administration, and the professions.

If a job is mostly a container for one skill, and AI swallows that skill, the job is mostly hollow. What is left is not the skill. It is the judgment around it.

What's left is judgment

Building used to be the expensive part. Writing the code, making the draft, producing the thing: that took time and a scarce skill. AI drives that cost toward zero. When the expensive part of a job gets cheap, the bottleneck moves to whatever is left. What is left is judgment.

Judgment is the part that decides what to build. It breaks the work into sensible pieces and defines what "good" even means. Then it checks the result. That last step is the one the AI sales pitch skips. Describing what you want without checking what came back is just guessing with extra steps.

And the checking matters more with AI, not less. AI is excellent at producing work that looks right. Whether it is right is a separate question, and the tool cannot answer it about itself. Plausible and correct are not the same thing. The gap between them is where the trouble lives. A confident but wrong draft, waved through fast, is how accidents happen. Someone has to be able to tell real quality from a convincing fake.

So the scarce skill is no longer doing the work. It is judging it. That changes who is valuable. The old bar was deep technical credentials. The new bar is judgment: understanding the business, saying clearly what needs to happen, and knowing good work when you see it.

Reorganize, or buy a fax machine

The three points meet here. AI makes building cheap. It swallows the skills that used to fill jobs. What stays valuable is judgment. And a company can only be as good as its scarcest input. When building was the bottleneck, the strong companies organized around builders. Now judgment is the bottleneck, so the strong company organizes around judgment. Hand AI to the people you already have and keep the same chart, and your scarce resource stays buried under task-work. The work has changed, so the shape has to change with it.

In practice, that means organizing around jobs that lead with judgment instead of jobs that were mostly task-work. The people who decide and check move to the center. The roles that existed to carry a now-cheap skill get thinner, or fold into something else. That is a different org chart. And that reshaping — not the tools bolted on top — is what changes the result.

This is why AI-native is an organizational change, not a software one. You can buy the tools in an afternoon. Reshaping the company around them is the actual work, and no vendor sells it. There is a test in this. If the companies that reshape around AI end up no more effective than the ones that only bolted it on, the argument fails.

So the real question is not "have we adopted AI." Everyone will say yes. The narrower one is this. Are you reorganizing the business around what AI now does cheaply? Or just bolting it onto the business you already had? If it is the second, you have not started. You have a very smart fax machine.

MIT Media Lab, Iceberg Index (Project Iceberg), arXiv:2510.25137 (October 2025); iceberg.mit.edu. The study models AI's exposure across skills rather than jobs, putting roughly 2.2% of wage value in the visible "tip" against a far larger submerged mass — about 11.7% — below the waterline. ↩
Melvin E. Conway, "How Do Committees Invent?", Datamation (April 1968); author-hosted at melconway.com. ↩

How Do You Know Your Engineering Team Is Effective?

2024-09-20T00:00:00-07:00

Measuring software team effectiveness presents real difficulties. Developers often resist metrics, arguing that complex creative work cannot be reduced to simple measures like lines of code or completed tickets. Their concerns are justified—poor metrics can backfire, creating stress and degrading quality.

Surface-level metrics (bug counts, severity levels) fail to capture broader software delivery dynamics. Effective measurement requires a nuanced approach tracking how features move from concept to production, plus insights into release stability and quality.

Leadership must clarify measurement purposes and align them with business outcomes—maximizing use-value and quality. Metrics should reflect the outcomes you're trying to achieve.

Deming and Quality Philosophy

W. Edwards Deming, the "Father of Quality," pioneered statistical process control and continuous improvement. His post-WWII work transformed Japanese manufacturing from poor to high quality.

Deming warned against overreliance on numerical targets, noting that "management by numerical targets can encourage behaviors that sacrifice long-term quality." He emphasized that "It is not enough to do your best; you must know what to do and then do your best."

Key insight: Metrics must be considered holistically. Focusing on any single metric in isolation leads to short-sighted optimizations that harm overall system performance.

What Effectiveness Means

Effective software engineering achieves high-quality outcomes providing long-term value while maintaining sustainable development. Effectiveness involves:

Consistency in Quality: Reliable software with minimal defects
Efficient Processes: Short feedback cycles with rapid delivery
Adaptability to Change: Reducing technical debt and enabling evolution

Three Key Metrics

Defect Density

Defect density measures bugs per thousand lines of code (kLOC)—essential for understanding software stability across development, verification, and post-release phases.

Benchmarks:

Verification phase above 2: Further testing needed before launch
Post-release above 1: Immediate attention required

Defect density is a lagging indicator reflecting past issues. Component-level analysis (front-end, back-end, infrastructure) makes it actionable by directing team focus where needed most.

Patterns indicating problems:

Post-release defects exceeding verification defects suggests insufficient testing
Low development defects but high post-release defects indicates missed early issues
Minimal defect reduction from verification to post-release points to inadequate testing coverage

Improvement strategies:

Improve test coverage comprehensively
Automate tests throughout the pipeline
Create production-like test environments
Implement continuous delivery

Cycle Time

Cycle time measures duration from task start to completion (typically deployment readiness). Shorter cycle times indicate efficiency; longer ones reveal bottlenecks.

Breaking down by phase reveals where delays occur:

Development cycle time: From starting work until code merges to main branch
Testing cycle time: From completion until passing all tests
Deployment cycle time: From passed tests to production deployment

Tracking cycle time trends over releases shows whether improvements sustain or if new inefficiencies emerge.

Key consideration: Sudden cycle time drops might indicate corner-cutting rather than genuine improvement. Teams must distinguish between real, sustainable gains and temporary fixes.

Lead Time for Changes

Lead time for changes measures duration from code commit to production deployment—critical for assessing team responsiveness and agility. Shorter lead times enable faster feedback loops and adaptation.

Common measurement pitfalls:

Inconsistent endpoints: Some teams start measuring from ticket creation, others from code commit. Standardization is essential. DORA recommends measuring from code commit to production deployment.
Ignoring variability: Different components (front-end vs. infrastructure) experience different lead times. Breaking down by component reveals specific bottlenecks.
Overlooking non-technical delays: Business approvals, requirement clarification, and resource constraints also impact lead time. Holistic measurement captures all delays.
Sacrificing quality for speed: Rushing changes into production without adequate testing increases defects and customer dissatisfaction, undermining long-term success.

Component-level breakdown helps identify specific improvement opportunities. For example, back-end changes consistently taking longer might indicate complex dependencies requiring optimization.

A Continuous Improvement Framework

These three metrics interconnect—improving one often improves others. Together they create comprehensive visibility into bottlenecks and performance.

A data-driven approach ensures continuous improvement in both delivery speed and output quality. This feedback loop, combining leading and lagging indicators, drives long-term success.

Clear Benefits

Increased Visibility: Metrics expose efficiency, speed, and quality issues throughout the pipeline, enabling bottleneck identification.

Holistic Quality Management: Defect density monitoring prevents technical debt accumulation while supporting continuous improvement.

Faster, Reliable Releases: Shorter cycle and lead times accelerate feature delivery while improving responsiveness.

Better Resource Allocation: Component-level breakdowns direct efforts where most needed, optimizing system-wide performance.

Improved Collaboration: Clear metrics help engineering, QA, product, and operations align, reducing cross-functional bottlenecks.

Important Cautions

Speed versus Quality: Reducing lead or cycle time without considering defect density degrades quality. Rushing changes without sufficient testing increases defects and customer dissatisfaction.

Misinterpreting Metrics: Inconsistent definitions of cycle time and lead time produce false conclusions. Standardizing measurement points ensures accuracy.

Focusing on Averages: Average metrics obscure outliers and critical bottlenecks. Breaking down by task size and complexity provides nuanced views.

Ignoring Non-Technical Delays: If business approvals and requirement clarification aren't included in lead time calculations, teams may incorrectly identify purely technical bottlenecks.

Treating Metrics as Ends: Metrics serve continuous improvement, not as final goals. Improving metrics without understanding broader implications creates short-sighted optimizations.

Final Thoughts

Effective measurement of software teams requires thoughtful metric selection. Rather than tracking surface metrics, focus on comprehensive indicators like defect density, cycle time, and lead time for changes—balancing productivity with quality.

Leadership must ensure metrics align with organizational goals rather than serving as pressure points. Transparency, collaboration, and alignment with business outcomes enable teams to deliver value while maintaining excellence without burnout.

As Deming demonstrated, "quality and long-term success stem from consistent, thoughtful systems, not just the pursuit of speed."

Prioritize Relationships over Transactions

2024-05-15T00:00:00-07:00

In today's fast-paced business world, quick wins often measure success—how many sales were closed this quarter or how much revenue rolled in last month. But what if we took a step back and looked beyond these short-term gains? What if we prioritized relationships instead of focusing solely on transactions—the deeper, more meaningful connections with customers, employees, and partners? It might not deliver instant financial results, but the long-term value could be far more significant.

To truly understand the value of prioritizing long-term relationships, we must connect it to a broader business philosophy: prioritizing long-term growth. Just as strong relationships with customers, employees, and partners are critical to sustained success, so is a company's ability to invest in its future. The company must do more than focus on short-term profits; it must commit to continuous improvement, innovation, and quality. Building and maintaining trust-based relationships is just one aspect of a long-term growth strategy emphasizing resilience over quick wins.

Companies that prioritize long-term growth understand that the benefits of investing in relationships extend beyond customer loyalty. A healthy organizational culture, where employees feel valued and trusted, is equally critical to achieving sustainable success. The need to focus on culture is where the teachings of W. Edwards Deming come into play. Deming believed that an organization should focus on continuous improvement and constancy of purpose—working steadily toward long-term objectives rather than being distracted by the pressures of quarterly earnings. The relationships companies cultivate with their employees are crucial to this, as engaged employees drive innovation, productivity, and, ultimately, customer satisfaction.

The Challenges of Prioritizing Relationships

Of course, this long-term focus comes with its own set of challenges. Many companies face significant pressure to deliver immediate financial results, especially from investors who expect quick returns. This pressure can make it tough to justify long-term relationship investments, especially when the payoff isn't immediate.

Most businesses must acknowledge the short-term financial pressures of competitive markets. Investors and shareholders often expect immediate returns, and companies must balance delivering those short-term results and securing long-term value. The key to achieving this balance is recognizing that short-term gains should not come at the expense of long-term goals. Leaders like Jeff Bezos have demonstrated that companies can prioritize growth while still meeting short-term expectations by investing in customer relationships and future capabilities, as seen in Amazon's Amazon Web Services (AWS) and Prime development.

The Deadly Disease of Short-Term Thinking

In Out of the Crisis, W. Edwards Deming emphasizes that short-term thinking is one of the deadly diseases afflicting Western management. He argues that focusing on short-term profits, driven by the pressure to meet quarterly earnings and deliver immediate returns to shareholders, undermines a company's long-term growth. This obsession with short-term gains leads to decisions that compromise quality, stifle innovation, and ignore the broader goal of continual improvement.

Deming gives examples of companies rushing to boost quarterly dividends by cutting critical long-term investments, such as research, education, and process improvement. For instance, management may ship incomplete or low-quality products to show high quarterly sales figures, deferring crucial investments in maintenance and innovation. This practice jeopardizes customer satisfaction and weakens the company's future competitiveness.

He contrasts this short-term mentality with the constancy of purpose needed for a business to thrive in the long run. In Deming's view, management should focus on improving processes, products, and services that meet future customer needs, thus ensuring the company's survival over time.

Deming argues that long-term stability and success come from a commitment to continuous improvement, not from chasing immediate profits at the expense of future growth. His critique of short-term thinking resonates today, especially in industries where companies face pressure to deliver fast results.

Unintended Consequences of Short-Term Focus

In A Practical Approach to Large-Scale Agile Development by Gary Gruver, there's a detailed example of failure resulting from short-term thinking during HP's transition to a large-scale agile methodology for re-architecting its firmware systems.

Initially, HP attempted a top-down, mandated agile approach, focusing on short-term business metrics like reducing Work in Process (WIP) without securing long-term organizational buy-in. This top-down approach led to the failure of their early agile implementations because the top-down directive needed more engagement and understanding from teams about the value of agile processes. The result was a disconnection between the leadership's push for immediate productivity gains and the ground-level need for a sustainable long-term transformation.

In Software Engineering at Google, a notable failure resulting from short-term thinking is seen in how the company addresses technical debt. Google emphasizes the danger of focusing solely on short-term feature development without considering long-term code health. When teams prioritize quick delivery over building maintainable and scalable systems, they accumulate technical debt, which can become overwhelming as the codebase grows. When code dependencies or architecture changes are repeatedly delayed in favor of short-term wins, it leads to chronic difficulties in maintaining and adapting the system as new features or fixes are required.

One specific practice highlighted is the risk of paying off technical debt. Over time, the cost of maintaining poorly structured code multiplies, making it harder to add new features, fix bugs, or refactor. In the long run, this leads to decreased productivity and hampers innovation. The engineers at Google experienced these issues firsthand. They had to implement strategies like continuous integration and automated testing to mitigate the effects of rapid development that neglected long-term sustainability.

Opposing Forces

CEOs often feel trapped between these two opposing forces. On one hand, they know that long-term investments in employee and customer relationships are critical. But on the other hand, they need to deliver short-term results to keep shareholders happy. In The CEO Tightrope, Joel Trammell talks about this balancing act and how focusing on employee engagement leads to better customer satisfaction, which drives long-term financial success.

A key example from The CEO Tightrope that illustrates the balance between long-term relationships and short-term financial pressure is Trammell's discussion of shareholder expectations. CEOs regularly face intense pressure to deliver quarterly results, but this focus can come at the expense of customer and employee satisfaction. Trammell emphasizes that companies must avoid shifting entirely toward short-term gains for shareholders, as this erodes long-term growth potential. Instead, he advocates for a balanced approach—prioritizing all stakeholders, including employees and customers, to ensure sustainable success.

In this example, Trammell explains that focusing too heavily on making quarterly numbers might deliver immediate financial returns. Still, it can eventually cause the business to deteriorate, leading to dissatisfied customers and disengaged employees. Balancing short-term performance with the broader goal of long-term relationship-building, as he advises, helps to create a stable, thriving company.

Striking the Right Balance

So, how can companies find that spot between delivering short-term results and building long-term relationships? The answer lies in balance. Companies like Amazon have demonstrated this by driving long-term growth strategies while meeting short-term financial expectations. It's not an easy task, but it's one that more businesses must embrace to thrive in the long run.

How did Amazon do it? Early on, Jeff Bezos clarified that Amazon would focus on customer obsession and long-term growth, even at the expense of short-term profitability. This philosophy allowed the company to invest heavily in infrastructure, including developing Amazon Web Services (AWS), which eventually became a highly profitable venture.

For over a decade, Amazon sacrificed immediate profits to build logistics networks, enhance customer service, and expand its product offerings. These investments positioned the company to handle massive order volumes and ensure customer satisfaction. This approach wasn't without risks—Amazon often faced scrutiny for its lack of short-term profits. However, Bezos' long-term vision, exemplified by innovations like Prime Membership, has paid off. By 2021, Prime had more than 200 million members globally, driving consistent revenue and increasing customer engagement.

The key takeaway from Amazon's strategy is that they secured growth by maintaining a long-term focus and found ways to deliver short-term financial results through innovations like AWS and Prime. This balance between long-term infrastructure investment and short-term revenue generation allowed Amazon to thrive, illustrating how companies can strategically blend both priorities.

Long-Term Relationships Are Key — But Not at the Expense of Short-Term Results

Prioritizing relationships over transactions is the smart move for businesses looking to succeed in the long term. But that doesn't mean ignoring short-term financial performance. The best companies are the ones that can build trust with their customers and employees while still delivering the results investors expect.

The key takeaway? Focus on building meaningful relationships while keeping an eye on short-term performance. It's not about picking one or the other—it's about finding the balance that works for your business. This balance will lead to sustainable growth, happier customers, and a more engaged workforce.

Mastering the Digital Realm (UNCAGED Interview)

2024-04-11T00:00:00-07:00

Recently, I met with Bant Breen at UNCAGED. We discussed the past, present, and future of software development.

Cultivate Shared Purpose and Collective Responsibility

2024-02-10T00:00:00-08:00

As a leader, one of the most important things you can do is cultivate a shared sense of purpose that aligns your organization's goals with the broader good for your stakeholders and the society you serve. The key here is co-creating your mission with all stakeholders, ensuring it reflects shared values. When people feel like they're part of shaping the company's goals, they are more invested, motivated, and ready to contribute. This approach is emphasized in W. Edwards Deming's work on Total Quality Management (TQM) (Out of the Crisis), where co-creating value and fostering a shared purpose is crucial for achieving long-term success and quality improvement.

This isn't just about making people feel good. Value creation isn't merely a financial transaction; it's a meaningful social process. Deming argued that emphasizing collective goals fosters cooperation and reduces process variation, improving overall performance and quality. Focusing on a collective mission minimizes the risk of individuals pulling the organization in different directions for their own benefit. Everyone stays aligned, sharing responsibility for the team's success. Research shows that teams working toward a shared goal tend to make better decisions, have higher morale, and collaborate more effectively.

However, maintaining that shared purpose in a large, diverse organization is challenging. Peter Drucker, a major influence on management theory, highlights the importance of consistently reinforcing shared objectives to ensure alignment. It's easy for the mission to get lost in the daily grind, especially if leadership isn't consistently reinforcing it. And let's be honest—reaching a consensus in a large group can be slow. Decision-making might get bogged down as you try to accommodate everyone's perspective.

Balancing collective responsibility with efficiency is tricky. If you spend too much time getting everyone on board, you risk delaying important decisions. Worse, your organization may start drifting away from its core mission without clear leadership. Employees might feel disconnected and disengaged if they don't see tangible progress. As discussed in The Phoenix Project by Gene Kim, large organizations must balance collaboration with maintaining a fast pace of decision-making, or they risk stagnation and inefficiency.

There's also the challenge of recognizing individual contributions within a shared mission. People want to feel valued for their efforts, and some team members might feel overlooked if the focus is always on the collective. This is a common challenge in large-scale agile and DevOps transformations, as described in Gary Gruver's A Practical Approach to Large-Scale Agile Development.

Cultivating shared purpose and responsibility remains among the most potent ways to build a resilient, motivated team. The key is to strike a balance: keep reinforcing your mission and give individuals room to shine. Doing so creates an environment where collaboration thrives, and everyone still feels recognized and empowered.

Shared purpose is creating a workplace where everyone feels part of something bigger. When that happens, you're not just fostering a mission—you're building a culture that drives long-term success.

Embedding a Culture of Mutual Aid in your Engineering Organization

2024-01-10T00:00:00-08:00

The concept of mutual aid in the workplace goes beyond simple acts of kindness or occasional favors. It's about creating a culture of generalized reciprocity—a system where helping others becomes a natural part of how a team operates. This type of reciprocity doesn't rely on keeping score; instead, it thrives on the shared understanding that everyone contributes, and everyone benefits over time.

So, what is generalized reciprocity?

Generalized reciprocity, as described by anthropologist David Graeber in Toward an Anthropological Theory of Value, is a form of exchange where people give without expecting immediate or equivalent returns. It's similar to the communal sharing principles outlined by Marshall Sahlins in Stone Age Economics, where the focus is on building trust and solidarity within a group. Gillian Tett, in Anthro-Vision, further explores how understanding these social dynamics in modern organizations can lead to more effective teamwork and collaboration.

Think of it like a team sport—when a player passes the ball, they don't expect the same player to pass it back immediately. The expectation is that the team, as a whole, will benefit from the shared effort. In engineering, this might look like a senior developer taking time to mentor a junior colleague, with the understanding that the junior developer will eventually contribute their skills back to the team in other ways.

The Power of Mutual Aid

Research supports the power of mutual aid in engineering teams. Nicole Forsgren's Accelerate highlights that high-performing DevOps teams, those that embrace collaboration and knowledge sharing, achieve remarkable results:

30x more frequent code deployments
8,000x faster lead times from commit to deploy
2x the change success rate
12x faster mean time to recover from failures

These outcomes aren't just about technical prowess—they are the result of teams that prioritize helping one another, sharing knowledge, and working toward common goals.

But It's Not All Perfect

While mutual aid has clear benefits, it's not without challenges. Power dynamics within a team can influence who gives and who receives help, potentially leading to inequities. David Graeber warns that even in systems of generalized reciprocity, underlying power structures can create imbalances.

Additionally, there's the risk of burnout. If certain team members consistently give more than they receive, they may become overwhelmed. Forsgren's research in Accelerate emphasizes the need for sustainable practices—teams that push too hard without balance often experience diminishing returns.

Gillian Tett, in Anthro-Vision, suggests that organizations need to be mindful of the social dynamics at play. Creating spaces for open communication and feedback is essential for maintaining a healthy balance of mutual aid.

Art Imitates Life

Gene Kim's The Phoenix Project offers a fictional yet highly relatable example of what happens when mutual aid breaks down in an engineering organization. The character Brent is the go-to person for everything—he's the one everyone relies on to solve problems, from network issues to database crashes. While Brent's knowledge is invaluable, the team's dependence on him becomes a bottleneck.

This is a classic example of what can go wrong when mutual aid isn't properly managed. Instead of distributing knowledge and skills across the team, everything funnels through one person. The result? Brent is overwhelmed, the team can't function without him, and the organization's ability to deliver value grinds to a halt.

Kim's solution in The Phoenix Project is threefold:

Distribute expertise: Cross-train team members so that no single person becomes indispensable.
Create repeatable processes: Automate and document tasks so that knowledge is accessible to everyone.
Build stronger communication channels: Encourage open dialogue and collaboration across teams.

Finding the Right Balance

So, how do we find the right balance? Google's famous "20% time" policy is one example. By allowing engineers to spend a portion of their time on projects outside their immediate responsibilities, Google encouraged innovation and knowledge sharing. This policy led to the development of products like Gmail and Google Maps, demonstrating the tangible benefits of fostering a culture of mutual aid.

Forsgren's Accelerate also highlights the importance of reducing "deployment pain"—the stress and friction associated with releasing software. Teams that automate their deployment processes and share the responsibility for releases tend to have lower burnout rates and higher job satisfaction.

Gillian Tett adds another dimension to this discussion by emphasizing the importance of creating social bonds within teams. In Anthro-Vision, she argues that teams that invest in understanding one another's perspectives and building trust are more likely to engage in mutual aid naturally, without the need for formal structures.

It can be challenging, but it is worth it

Creating a culture of mutual aid in engineering organizations isn't easy, but the rewards are significant. As Forsgren's research shows, teams that embrace collaboration and knowledge sharing consistently outperform their peers. And as Tett reminds us, understanding the social dynamics at play is crucial for building sustainable, effective teams.

Titus Winters, in Software Engineering at Google, emphasizes the importance of building systems that encourage collaboration. Google's code review process, for example, is designed to spread knowledge across teams, ensuring that no single person becomes a bottleneck.

Key Takeaways

Mutual aid works best when it's structured: Create formal channels for knowledge sharing, like code reviews, pair programming, and cross-training programs.
Watch out for the "Brent" problem: Ensure that expertise is distributed across the team to prevent bottlenecks and burnout.
Be mindful of social dynamics: Power imbalances and uneven contributions can undermine mutual aid. Regular feedback and open communication are essential.

Final Thoughts

Embedding a culture of mutual aid in your engineering organization is about more than just being nice—it's about building resilient, adaptable teams that can deliver value consistently. By drawing on insights from anthropology, DevOps research, and real-world examples, we can create environments where collaboration thrives and everyone benefits.

The key is balance: fostering a culture of generalized reciprocity while being mindful of the challenges that come with it. When done right, mutual aid becomes a powerful driver of innovation, quality, and team satisfaction.