The counter-point to my 3 Characteristics of a High-Performing Software Team. I have never worked in a company that operates this way, but I know plenty of people do.
What happens when a team is bogged down by hierarchy, bureaucracy, and poor decision-making?
Decisions are centralised at the top - leaders with little exposure to the actual work dictate technical and process decisions.
Engineers are excluded from decision-making and expected to follow orders rather than contribute ideas.
Bureaucratic approval processes mean even small changes require sign-off from multiple layers of management.
Decisions are made without context, often leading to poorly informed choices.
By the time leadership approves something, the problem has already changed - but the team is still stuck implementing an outdated decision.
Engineers feel disempowered and disengaged, reducing motivation and slowing innovation.
Developers execute tasks without real ownership, resulting in work that meets minimum requirements but lacks long-term thinking.
No one owns bugs, security issues, and performance problems - responsibility is passed around rather than addressed.
Instead of "you build it, you own it", the mentality becomes "not my problem".
Code quality deteriorates, leading to growing technical debt that slows future development.
Problems are ignored or covered up rather than proactively solved.
Without ownership, developers lose pride in their work, leading to a demotivated and passive team.
Multiple layers of management must sign off on every small decision before the team can act.
Engineers spend more time writing justification documents than actually building and improving software.
A culture of process over progress means even obvious improvements take weeks or months to implement.
The team loses agility, missing out on opportunities to innovate and react to changing business needs.
Engineers stop taking initiative because they know everything will be blocked by red tape.
By the time an idea is approved, the industry and customer needs have moved on - but the team is stuck implementing something outdated.
Communication flows one way - top-down. Engineers are expected to execute without questioning.
Different teams (e.g. frontend, backend, IT Ops) barely talk to each other, leading to misalignment.
Information is hoarded rather than shared, resulting in duplication of work and inefficiency.
Teams work in isolation, leading to integration issues, wasted effort, and inconsistent user experiences.
Reinventing the wheel - teams build similar solutions separately instead of collaborating.
A lack of transparency means small misunderstandings escalate into major blockers.
Engineers are afraid to speak up, question decisions, or challenge bad practices for fear of blame.
Mistakes are punished, not treated as learning opportunities.
People default to playing it safe, following rigid processes instead of thinking critically about the best approach.
Talented engineers leave - the best people want to be in an environment where they can grow and contribute.
Teams avoid innovation - if failure isn’t tolerated, no one takes risks.
The business misses out on potential breakthroughs because engineers are too afraid to push boundaries.
Instead of empowered engineers solving real problems, you get a bureaucratic machine stuck in slow motion. The best developers quit, product quality declines, and users suffer.
✅ Empower teams – push decision-making closer to the work.
✅ Encourage ownership – foster a "you build it, you own it" mindset.
✅ Eliminate unnecessary approvals – reduce friction in decision-making.
✅ Break silos – foster cross-functional collaboration.
✅ Build trust – create a culture where engineers feel safe to experiment and improve.
Join the Leadership Insider List
Be first to hear about fresh articles, free guides, and limited-time course offers - all crafted to help you build high-performing teams.
© 2025 M.J. Ashton | Helping thoughtful professionals lead with impact.• Privacy policy • Terms of service