A Survival Guide to Build Healthy Tech Organizations
In today's fast-changing technology world, how we organize our teams and build our software can make the difference between success and failure. Many companies learn these lessons the hard way, through expensive mistakes and delayed projects. Let's explore some opinionated fundamental principles that could help build better products and create healthier work environments, starting with the technical foundations and building up to the cultural practices that make organizations successful.
These are not new concepts, but ones that I consider to be part of the canon. It's stronger on the “what” and “why” than the “how”.
The Technical Foundation: High Cohesion and Low Coupling
Before we can understand how to organize teams or share knowledge effectively, we need to grasp two fundamental principles that guide all good software architecture: high cohesion and low coupling. These aren't just technical concepts, they shape how we think about organizing entire companies.
High cohesion means keeping related things together. If you have code that handles user authentication, all of that code should be in one place, maintained by one team. It's like keeping all your cooking utensils in the kitchen. They belong together because they serve the same purpose. Low coupling means minimizing dependencies between different parts of the system. Each component should be able to work independently as much as possible. Think of it like electrical outlets in your home. You can plug in a lamp without needing to know how the television works. When systems have low coupling, you can change one part without breaking everything else.
These principles don't just apply to code, they apply to how we organize our teams and define their responsibilities. This brings us to one of the most important decisions a tech company makes: how to structure its domains.
Understanding Domains: Boundaries, Autonomy, and Accountability
When we talk about domains in a tech company, we're talking about different areas of the business that have their own specific purposes and knowledge. Think of domains like different departments in a hospital: emergency care, surgery, and administration all serve different functions and require different expertise. The way we define these domains should follow our principles of high cohesion and low coupling, keeping related capabilities together while minimizing dependencies between different areas.
One common mistake companies make is creating organizational domains based on "actor domains", that means organizing teams around who uses the system rather than what the system does. For example, imagine an e-commerce company that creates separate teams for "customer systems," "seller systems," and "admin systems." This seems logical at first, but it violates our principle of high cohesion. The same business logic, like calculating prices or managing inventory, gets duplicated across multiple teams. When pricing rules change, three different teams need to update their code. This leads to inconsistencies, bugs, and wasted effort. Instead, it's better to organize around business capabilities like "pricing," "inventory," or "ordering", regardless of who uses these features.
But here's what many organizations miss: effective domains need clear boundaries. A boundary is like a fence around your property. It defines what's inside and what's outside, what you're responsible for and what you're not. In software terms, this means each domain should have a clear understanding of what concepts, data, and rules belong to it. The pricing domain owns everything about how prices are calculated, stored, and validated. It doesn't just have some pricing code scattered among other things; it has complete ownership of the pricing concept. When another team needs pricing information, they don't reach into the pricing domain's database or duplicate its logic. They ask the pricing domain through a well-defined interface, like calling an API or subscribing to price change events.
These boundaries are crucial because they enable something powerful: autonomy. When a domain has clear boundaries and owns its concepts completely, the team responsible for that domain can make decisions independently. The pricing team can change how they calculate discounts without asking permission from the ordering team. They can refactor their code, change their database schema, or even rewrite everything in a different programming language, as long as they maintain their contracts with other domains. This autonomy allows teams to move fast and innovate without being blocked by dependencies on other teams.
Similarly, the platform domain, the technical foundation that supports other teams, should focus on providing technical capabilities, not business logic. Think of the platform team as the people who build the roads, not the ones who decide where the cars should go. When platform teams start including shared business capabilities, they create unwanted coupling and violate domain boundaries. Every time the business needs change, multiple teams have to wait for the platform team to update the shared code. It's like having only one kitchen in an apartment building, everyone has to wait their turn to cook.
But autonomy without alignment is just chaos. Imagine if every domain team optimized only for their own goals without considering the bigger picture. The pricing team might create the most sophisticated pricing engine in the world, but if it takes five seconds to calculate a price, the customer experience suffers. This is where alignment becomes critical. All domains need to work toward the same company goals, even while maintaining their autonomy. If the company goal is to provide instant checkout, then the pricing domain needs to balance sophistication with speed. The inventory domain needs to ensure stock checks are fast. The payment domain needs to process transactions quickly. Each team has autonomy in how they achieve these goals, but the goals themselves are shared.
This balance between autonomy and alignment requires clear accountability. When a team owns a domain with clear boundaries and has the autonomy to make decisions, they also become accountable for the outcomes. If the pricing service goes down during Black Friday, the pricing team can't blame the platform team or the database team. They own their domain completely, including its reliability. This accountability might seem harsh, but it's actually empowering. When teams know they're truly responsible for their domain's success, they make better decisions. They think about monitoring, testing, and reliability from the start, not as afterthoughts. They document their decisions because they know they'll have to live with the consequences.
The relationship between boundaries, autonomy, alignment, and accountability creates a powerful dynamic. Clear boundaries enable autonomy by defining what each team owns. Autonomy enables teams to move fast and innovate. Alignment ensures that this speed and innovation serve the company's goals. Accountability ensures that teams take their responsibilities seriously and build sustainable solutions. When all four elements work together, you get teams that are both independent and collaborative, fast and reliable, innovative and responsible.
But even when we organize our domains correctly with clear boundaries and balanced autonomy, we still need to make strategic decisions about where to focus our efforts. Not all domains deserve equal attention.
Identifying What Really Matters: Understanding Domain Types
To make smart decisions about where to invest your resources, you need to understand that not all parts of your business are equally important. In domain-driven design, we typically classify domains into three categories: core domains, supporting domains, and generic domains. Think of these like the different components of a restaurant. The signature dishes that customers come for represent core domains, the custom reservation system might be a supporting domain, and basic accounting software would be a generic domain.
Core domains are the areas that make your company special and different from competitors. For Netflix, the recommendation algorithm is a core domain. It's what keeps customers coming back. For Amazon, logistics and delivery might be core domains. These areas deserve the most attention, the best developers, and the most investment. Core domains are where you want to innovate and excel because they directly impact your competitive advantage. If you're not the best in the world at your core domains, or at least trying to be, your business is in trouble.
Supporting domains are important for your business but don't differentiate you from competitors. Imagine an online retailer's return processing system. It needs to work well because poor return handling frustrates customers, but having a slightly better return process than competitors won't win you the market. Supporting domains need to be good enough to not cause problems, but they don't need to be revolutionary. You might build these in-house if they have specific requirements unique to your business, but you won't put your top talent here.
Generic domains are areas where your needs are the same as everyone else's. Every company needs email, basic accounting, or employee time tracking, but these don't make your business special. For generic domains, buying or using existing solutions almost always makes more sense than building your own. It's like a restaurant buying dishwashers instead of inventing their own. The problem has been solved, and solving it again adds no value to your business.
Understanding these distinctions helps you avoid one of the most common mistakes in tech companies: spreading resources evenly across all domains. When companies fail to identify and prioritize their core domains, they might spend equal time perfecting their internal expense reporting system as they do on the features that actually attract and retain customers. It's like a restaurant spending as much time organizing their storage closet as they do perfecting their signature dishes, it doesn't make business sense.
But here's where it gets interesting: domains don't stay in the same category forever. What's core today might become supporting tomorrow, and what's currently custom-built might become available as a generic solution next year. This is where Wardley mapping becomes incredibly valuable. Wardley mapping is a strategic planning technique that helps you visualize your business components and understand how they evolve over time.
Imagine you're running a company in 2010 that does real-time video streaming. Back then, the technology to stream video efficiently was a core domain (it was hard) and few companies could do it well, and it provided competitive advantage. But over the years, as cloud providers began offering video streaming services and the technology became commoditized, it evolved from core to generic. Companies that recognized this evolution early could shift their resources from maintaining streaming infrastructure to building better content or user experiences. Those that didn't wasted valuable resources maintaining something that they could have simply purchased without creating a point of return.
Wardley mapping helps you see this evolution visually. You map out all your business components on a chart that shows both how visible they are to users and how evolved they are from custom-built to commodity. A brand new machine learning algorithm might be on the left side of the map showing it's custom and innovative, while email hosting would be on the right showing it's a commodity. By creating these maps, you can see which components are evolving, where you should invest, and what you should stop building yourself.
The real power of combining domain classification with Wardley mapping is that it helps you make strategic decisions about the future, not just the present. You might identify that your current core domain is rapidly becoming commoditized and realize you need to find new areas for differentiation. Or you might spot an emerging technology in a supporting domain that could become core to your business if you invest early. It's like a surfer reading the waves, you need to position yourself where the wave will be, not where it is now.
This strategic thinking about domains connects directly to how we organize our teams. When you clearly identify which domains are core, supporting, and generic, understand how they're evolving, and establish clear boundaries with appropriate autonomy and accountability, you can make better decisions about team structure, hiring, and resource allocation. This clarity helps prevent one of the biggest organizational challenges: silos.
Breaking Down Walls: The Danger of Silos
Silos happen when different teams or departments work in isolation, rarely communicating or collaborating with each other. Picture a company where the development team never talks to the operations team, and the operations team never talks to customer support. When a customer reports a problem, it takes days or weeks to fix because information moves slowly between these isolated groups. Even well-designed domains can become silos if we're not careful.
Breaking down silos means creating an environment where information flows freely and teams work together toward common goals. This doesn't mean everyone needs to know everything, but it does mean removing artificial barriers that prevent collaboration. When teams share knowledge and work together, problems get solved faster, and everyone learns from each other's experiences.
The antidote to silos isn't just telling people to communicate more. It's building systems and cultures that make collaboration natural and effortless and removing unnecessary layers. But here's something crucial that many organizations miss: you can't effectively break down silos if different teams operate with fundamentally different technical values and practices. This brings us to an essential but often overlooked principle: the need for a homogeneous technical culture.
Building a Unified Technical Culture: From Recruitment to Daily Practice
When we talk about a homogeneous technical culture, it's important to clarify what we mean and what we don't mean. We're not talking about hiring people who all look the same, think the same, or come from the same backgrounds. Diversity of perspectives, experiences, and backgrounds is crucial for innovation and problem-solving. What we're talking about is creating alignment around technical values, practices, and approaches to problem-solving. Think of it like an orchestra: you want different instruments playing different parts, but they all need to be reading from the same sheet music and following the same conductor.
Imagine a company where half the developers believe in extensive testing and code reviews, while the other half believes in moving fast and fixing things in production. Or where some teams document everything meticulously while others rely entirely on tribal knowledge. These aren't just different approaches, they're fundamentally incompatible worldviews that create friction every time these teams need to work together. It's like trying to build a house where some workers are using metric measurements and others are using imperial. Even if everyone is skilled and well-intentioned, the result will be a mess.
A homogeneous technical culture means that everyone in the organization shares certain fundamental beliefs about how to build software. This might include agreements about code quality standards, testing practices, documentation requirements, how to handle technical debt, approaches to security, or methods for making technical decisions. When everyone shares these foundational beliefs, collaboration becomes smooth and natural. Teams can move between projects without culture shock, code can be shared without extensive rework, and decisions can be made quickly because everyone is working from the same playbook.
This cultural alignment needs to start from the very beginning at recruitment. Many companies make the mistake of hiring purely based on technical skills, assuming they can teach culture later. But technical culture isn't just about following rules; it's about deeply held beliefs about what good software looks like and how it should be built. If you hire someone who fundamentally believes that documentation is a waste of time into a culture that values comprehensive documentation, you're setting up both the individual and the team for frustration and conflict.
Smart recruitment for technical culture doesn't mean asking trick questions or requiring specific technologies. Instead, it means exploring how candidates think about software development. How do they approach debugging a complex problem? What's their philosophy on testing? How do they balance speed versus quality? What's their experience with code reviews, and what value do they see in them? You're not looking for perfect answers, but for alignment with your organization's values. A brilliant developer who believes in cowboy coding might not be a good fit for a team that values careful, methodical development no matter how talented they are.
But recruitment is just the beginning. Once people join your organization, you need to actively reinforce and develop the technical culture through comprehensive onboarding and continuous training. Too many companies treat onboarding as a bureaucratic checkbox here's your laptop, here's the wiki, good luck. But effective onboarding is where new team members internalize not just what your culture says, but how it actually works in practice, two way synchronization is needed.
Imagine joining a new company and spending your first two weeks pair programming with experienced developers, participating in code reviews, attending architecture discussions, and seeing how decisions actually get made. You're not just learning the codebase; you're absorbing the culture through osmosis. You see that when someone says "we value testing," they actually mean it, tests are written first, they're comprehensive, and pull requests without tests don't get merged. You learn that "we document our decisions" means there's an architectural decision record for every significant choice, not just a vague suggestion to write things down sometimes.
Continuous training and reinforcement keep the culture strong as the organization grows and evolves. This isn't just about sending people to conferences or online courses, though those can be valuable. It's about creating regular opportunities for teams to align on practices and share knowledge. Maybe you have weekly tech talks where teams present their approaches to solving problems. Perhaps you run internal workshops on testing strategies or debugging techniques. You might organize coding dojos where developers practice new techniques together in a safe environment.
The power of a homogeneous technical culture becomes especially apparent when things go wrong. In organizations with fragmented cultures, incidents become blame games. The "move fast" team blames the "move carefully" team for being too slow to respond. The "comprehensive testing" team blames the "ship it now" team for causing the problem in the first place. But in organizations with aligned technical culture, everyone shares the same values about quality, the same understanding of acceptable risks, and the same commitment to learning from failures. Instead of finger-pointing, there's collaborative problem-solving.
This cultural alignment also dramatically speeds up decision-making and reduces organizational friction. When everyone shares fundamental technical values, you don't need to debate basic principles in every meeting. You don't need extensive approval processes because teams can be trusted to make decisions aligned with organizational values. You don't need heroes to bridge between incompatible team cultures because there's only one culture. The organization can move faster because it's not constantly dealing with internal friction from conflicting approaches.
However, building and maintaining a homogeneous technical culture requires constant attention and investment. As organizations grow, especially through acquisitions or rapid hiring, it's easy for subcultures to develop. Different offices might evolve different practices. Teams working on different products might drift apart in their approaches. This is why successful companies treat technical culture as a strategic priority, not an HR afterthought. They invest in bringing teams together regularly, they're deliberate about which practices are mandatory versus flexible, and they constantly reinforce cultural values through their actions, not just their words.
The connection between homogeneous technical culture and our other principles is profound. When teams share technical values, breaking down silos becomes much easier because there's a common language and shared understanding. Transparency works better because everyone values and practices it consistently. The dangers of hero culture diminish because the culture emphasizes collective ownership and knowledge sharing. Even architectural principles like high cohesion and low coupling are easier to maintain when everyone understands and values them equally.
But maintaining this cultural alignment while avoiding stagnation requires thoughtful leadership. This brings us to a management approach that seems like it should create consistency but actually creates more problems than it solves.
Moving Beyond Command and Control: Why Traditional Management Fails in Tech
Command and control management comes from military and industrial age thinking, where work was predictable and repetitive. In this model, managers at the top make all important decisions, create detailed plans, and pass orders down through layers of hierarchy. Workers at the bottom follow these orders precisely, with little room for creativity or independent thinking. Think of it like a traditional factory assembly line where every movement is predetermined and workers simply execute predefined tasks.
This approach might work when building thousands of identical widgets, but software development is fundamentally different. Every problem is unique, technology changes rapidly, and the people closest to the code often have the best understanding of what's possible and what's needed. When a manager three levels up decides how long a feature should take without understanding the technical complexity, or when teams need approval for every small decision, the organization grinds to a halt.
Command and control creates several serious problems in tech companies. First, it destroys innovation because people stop thinking creatively when they're just following orders. Imagine a developer who sees a better way to solve a problem but knows they'll need three meetings and two weeks of approvals to try it. They'll probably just do what they were told instead. Second, it slows everything down because decisions bounce up and down the hierarchy like a ping-pong ball. By the time approval comes back, the market opportunity might be gone. Third, it demotivates talented people who joined the tech industry specifically because they wanted to solve interesting problems and build innovative solutions, not to be cogs in a machine.
Perhaps most dangerously, command and control creates an illusion of predictability and control that doesn't actually exist. Managers feel comfortable because they have detailed plans and status reports, but these often hide the real problems. Teams learn to report what management wants to hear rather than what's actually happening. It's like navigating with an outdated map, you might feel confident about where you're going, but you're actually lost.
So what's the alternative? Modern tech companies need to value risk management over control and fear. They need management approaches that embrace uncertainty and empower teams while still maintaining alignment and accountability. One powerful alternative is servant leadership, where managers see their role as supporting and enabling teams rather than commanding them. Instead of saying "do this," servant leaders ask "what do you need to succeed?" They remove obstacles, provide resources, and protect teams from organizational dysfunction while trusting them to make good decisions.
Another effective approach is that leadership sets clear objectives and constraints. The "what" and the "why", but leaves the "how" up to the teams. For example, instead of telling a team exactly how to build a feature, leadership might say "we need to reduce customer churn by 10% this quarter, and we have this budget to work with." The team then figures out the best way to achieve that goal, using their expertise and creativity.
Some organizations adopt collaborative decision-making. These approaches clarify who needs to be involved in different types of decisions and how those decisions get made, but without creating rigid hierarchies. A technical decision might be made entirely by the engineering team, while a pricing decision might involve product, sales, and engineering together. The key is that decisions are made by the people with the most relevant knowledge, not just the highest rank.
These alternative management approaches help prevent another organizational disease that often emerges from command and control structures: internal politics. When organizations create the right structures and incentives, they can minimize the toxic effects of political behavior and create environments where merit and collaboration triumph over manipulation and self-interest.
Eliminating Toxic Politics: Building Merit-Based Organizations
Organizational politics in tech companies is like a virus that spreads quietly but causes tremendous damage. It happens when people advance their careers not by building better products or solving harder problems, but by managing perceptions, building alliances, playing power games, and spreading Peter principle. Picture a company where the best engineers don't get promoted because they're too busy coding, while those who spend their time in meetings talking about other people's work climb the ladder. Or where technical decisions aren't based on what's best for the product, but on who has the most political capital, yes sir folks or who's best friends with the VP.
The toxicity of politics manifests in many ways. You might see engineers spending more time crafting emails or slack messages to look good than writing code. Teams hoard information because sharing knowledge means losing power. Technical debt accumulates because no one wants to own unglamorous but necessary work that won't get them promoted. Innovation dies because new ideas threaten existing power structures. Information must cross multiple hierarchical layers to be on the air, unless it is ignored or modified along the way. The best talent leaves because they're tired of seeing political operators succeed while genuine contributors are overlooked.
So how do you create an environment where politics can't take root? A powerful antidote to politics is radical transparency in decision-making. This doesn't mean every conversation needs to be public, but the principles, processes, and outcomes should be clear and visible to all affected parties. Also, in addition to being futile, multi-layer management is a barrier to transparency and collaboration.
Creating multiple paths for advancement also reduces political behavior. In many tech companies, the only way to advance is to become a manager, which creates perverse incentives for excellent engineers to abandon what they do best. By establishing parallel tracks, where a principal engineer can have the same status and compensation as a director, you remove the pressure to play political games to climb a single ladder. People can succeed by excelling at what they love, whether that's coding, architecture, mentoring, or management.
The connection between eliminating politics and our other principles is clear. When you have transparent decision-making, clear domain boundaries with accountability, and a homogeneous technical culture, there's less room for political maneuvering. When teams have genuine autonomy and alignment, when the management culture is against command and control, there is no room to play political games. When failure is seen as learning rather than blame, people don't need to engage in political cover-ups. Each principle reinforces the others, creating an environment where merit and collaboration naturally flourish.
Choosing Openness: Transparency Over Opacity
Transparency means making information visible and accessible to those who need it. This includes everything from code and documentation to decision-making processes and project status. When teams operate transparently, everyone can see what's happening, why decisions were made, and how they can contribute. Transparency is the foundation that makes collaboration possible and enables the autonomous decision-making we just discussed. Many patterns could help such as ADRs or Arc42.
Opacity, keeping information hidden or hard to find, creates confusion and mistrust. It's like trying to assemble furniture without instructions; you might figure it out eventually, but it takes much longer and causes unnecessary frustration. Transparent organizations move faster because people spend less time searching for information or redoing work that's already been done. More importantly, transparency allows teams to make good decisions independently because they understand the full context of their work and they make the most of other experiences.
Transparency helps teams learn from each other's successes and failures. But this learning process can go wrong when teams start copying practices without understanding why they work. This brings us to a dangerous trap that many organizations fall into.
The Cargo Cult Trap: Why Context Matters
Cargo culting in software development happens when teams copy practices from successful companies without understanding the principles behind them. The term comes from Pacific island societies that built replica airports hoping to attract cargo planes, not understanding that it was World War II, not the airports themselves, that brought the supplies.
In tech companies, cargo culting looks like adopting daily stand-up meetings because Google does them, without understanding that stand-ups work when teams need tight coordination. Or implementing microservices because Netflix uses them, ignoring that Netflix has thousands of engineers and your startup has twelve. These teams go through the motions of successful practices but don't get the benefits because they haven't understood the underlying problems these practices were meant to solve.
One of the most common examples of cargo culting is how companies adopt Scrum. They hear that successful companies use Scrum, so they immediately implement all the ceremonies: daily stand-ups, sprint planning, retrospectives, and sprint reviews. They hire Scrum Masters, pay thousands for Jira, create backlogs, and start estimating in story points. But they do all this without understanding the problems Scrum was designed to solve or whether those problems actually exist in their organization. These teams end up spending more time on Scrum ceremonies than actually building software, wondering why this "proven" methodology isn't making them more productive.
The danger of cargo culting is that it gives teams a false sense of progress. They feel like they're following "best practices," but they're really just performing rituals. A company might implement Spotify's squad model without having Spotify's culture of autonomy and trust. They get all the overhead of the new structure but none of the benefits. Even worse, cargo culting can actively harm organizations when copied practices conflict with their actual needs. A small team adopting the communication processes designed for a 500-person organization will drown in unnecessary meetings and documentation.
Instead of blindly copying what successful companies do, teams should understand their own problems first, then look for principles and adapt solutions to their specific context. Ask "what problem were they solving?" not "what did they do?" This thoughtful approach to adopting practices connects directly to another dangerous misconception: the search for silver bullets.
Avoiding Silver Bullets: No Single Solution Solves Everything
A silver bullet in software development is the belief that one tool, technology, or methodology will solve all your problems. It's thinking that adopting Kubernetes or Serverless will fix all your deployment issues, or that switching to microservices will automatically make your system scalable, or that hiring from a specific company will transform your culture overnight.
One of the most pervasive silver bullet beliefs in the industry is around project management tools, particularly Jira. Companies experiencing problems with project visibility, team coordination, or delivery predictability often think, "If we just implement Jira properly, all our project management problems will disappear." They spend months configuring workflows, creating custom fields, setting up dashboards, and training everyone on the tool. But six months later, they find that projects are still late, communication is still poor, and now they have the additional overhead of maintaining a complex Jira setup. The tool didn't fix the underlying problems: unclear requirements, poor stakeholder communication, or unrealistic deadlines. In fact, teams often find that Jira becomes another source of friction, with developers spending hours updating tickets instead of writing code, and managers becoming obsessed with burndown charts that don't reflect actual progress. The real issues like why estimates are always wrong or why requirements keep changing mid-sprint – remain unaddressed because everyone thought the tool would somehow solve these deeper organizational problems.
The silver bullet mentality is seductive because it promises simple solutions to complex problems. Leadership loves silver bullets because they seem like decisive action. "We're moving everything to the cloud!" sounds much better in a board meeting than "We're going to carefully evaluate which of our systems would benefit from cloud hosting and migrate them incrementally over two years."
But real organizations are complex systems with interconnected challenges. Performance problems might stem from poor database design, not your programming language. Team velocity might be slow because of unclear requirements, not your project management tool. Customer satisfaction might be low because of poor product decisions, not your technology stack. When companies chase silver bullets, they often undergo expensive, disruptive changes that don't address their real problems. They might spend months migrating to a new framework while their competitors focus on building better features.
The alternative to silver bullets is understanding that improvement comes from many small, thoughtful changes rather than one dramatic transformation. It means solving specific problems with targeted solutions, measuring results, and adjusting based on what you learn. This measured approach to change connects directly to how we think about failure and learning.
Learning from Failure: The "Fail Fast" Philosophy
Creating an environment where teams can experiment with solutions, rather than searching for silver bullets or copying others, requires a fundamental shift in how we think about failure. "Fail often, fail fast" doesn't mean being careless. It means trying new things, discovering quickly when they don't work, and adjusting course without blame or shame.
When teams fear blame, they hide problems until they become catastrophes. They avoid trying innovative solutions because the risk of failure seems too high. They might even fall back on cargo culting or silver bullet solutions because these feel safer after all, if everyone else is doing it, you can't be blamed if it doesn't work. But when organizations embrace failure as a learning opportunity, magic happens. Teams experiment freely, problems surface quickly while they're still small, and everyone learns from both successes and mistakes.
This philosophy of learning from failure connects directly to how we build our teams. When people aren't afraid to make mistakes, they're more willing to take on challenges, admit when they need help, and share their struggles with others. This creates an environment where knowledge spreads naturally and no one person becomes a critical dependency.
Building Sustainable Teams: Beyond Hero Culture
Hero culture emerges when there's a systemic problem or gap in a system and an individual decides to fill that gap. It often manifests as "incident-driven development", when something breaks, everyone stops what they're doing, and the person with the most context becomes the hero who saves the day. While this might seem efficient in the moment, it creates a dangerous pattern.
The problem isn't that someone knowledgeable fixed an issue. It's that organizations start relying on this pattern instead of addressing why problems keep happening. When heroes consistently step in to save the day, they become the sole repositories of critical knowledge, creating dangerous single points of failure. These heroes often work longer hours, take on more stress, and feel pressured to always be available, leading to burnout. Meanwhile, other team members don't develop the skills they need because they rely on the hero to handle difficult situations.
Hero culture creates a self-reinforcing cycle: quick fixes by heroes prioritize immediate solutions over long-term maintainability, leading to more technical debt, which causes more incidents, which requires more heroics. Teams with strong hero cultures experience significantly higher burnout rates than those with distributed responsibility patterns. The organization might praise and recognize crisis management, but nobody asks the critical question: why did this crisis happen in the first place?
Sometimes hero culture emerges from cargo culting. Companies copy the "rockstar developer" culture they've heard about without understanding its problems. Other times, it's seen as a silver bullet, "if we just hire the right genius, all our problems will be solved." But sustainable organizations build systems and processes that address systemic gaps rather than depending on individuals to fill them. They document knowledge, share responsibilities, conduct root cause analysis after incidents, and ensure multiple people can handle critical tasks.
This approach might seem slower at first, but it creates resilient teams that can handle challenges even when key members are absent. When you combine high cohesion and low coupling in your architecture, organize domains around capabilities with clear boundaries and balanced autonomy, prioritize core domains while appropriately managing supporting and generic ones, build a unified technical culture from recruitment through continuous training, eliminate toxic politics through transparency and merit-based systems, break down silos through empowering leadership rather than command and control, maintain transparency, avoid cargo culting and silver bullets, and embrace learning from failure, hero culture naturally disappears. The system itself becomes robust, not dependent on any individual person.
Bringing It All Together
These principles form a complete system for building effective tech organizations. We start with the technical foundation of high cohesion and low coupling, apply these principles to how we organize our domains with clear boundaries that enable autonomy while maintaining alignment and accountability. We identify which domains truly matter for our success through careful classification and strategic tools like Wardley mapping. We then break down the walls between teams, but recognize that this requires a unified technical culture built through deliberate recruitment and continuous reinforcement. We replace command and control with empowering management approaches like servant leadership and mission command, while actively eliminating toxic politics through transparency, clear criteria, and merit-based advancement. Through transparency, we enable teams to make good decisions independently, while avoiding the traps of cargo culting (like blindly adopting Scrum) and silver bullets (like expecting Jira to solve all project management problems).
By creating a culture where failure becomes learning and heroes become mentors instead of saviors, we build organizations that can adapt and grow. Each principle supports the others, clear domain boundaries enable autonomy, which requires accountability and alignment. A homogeneous technical culture enables transparency, which prevents politics, which enables autonomous decision-making, which requires moving beyond command and control. Learning from failure reveals that complex problems need multiple solutions (not silver bullets), and sustainable team practices prevent hero culture from taking root.
The journey to implement these principles isn't always easy, and no company gets everything right immediately. The key is to understand your own context, solve your specific problems, and learn from both your own experiences and the principles (not just the practices) of successful organizations. Start with one area, but always keep the bigger picture in mind. As each piece falls into place, the others become easier to implement, creating a positive cycle of improvement that benefits everyone, from individual developers to customers to the business as a whole.
Remember: there's no silver bullet that will transform your organization overnight, and blindly copying what works for others won't solve your unique challenges. But by thoughtfully applying these principles to your specific context, you can build a tech organization that's both effective and sustainable for the long term. The strength doesn't come from any single principle, but from how they work together to create a coherent, resilient system that can handle whatever challenges the future brings.
