{"slug": "okay-vs-excellent-engineering-teams", "title": "\"okay\" vs excellent engineering teams", "summary": "Engineering teams that fix root causes rather than patching issues build lasting excellence, according to a manager with 15+ years in tech. The article contrasts 'okay' teams that repeatedly patch the same problems with excellent teams that invest time to solve underlying issues, citing a cost-benefit table showing weekly 15-minute fixes justify up to 2 days of repair work over five years.", "body_md": "[Manager.dev](http://Manager.dev)* is proudly supported by CodeRabbit!*\n\nIn every team I've managed, the same friction kept showing up: decisions made in Slack threads that nobody can find a week later. You end up re-debating things your team already solved. That's exactly the kind of root cause excellent teams fix.\n\n** CodeRabbit Agent** lives in your Slack channels and remembers what your team decided, pulling context from code, tickets, docs, and monitoring. From the team behind 2M weekly code reviews, 6M repos, and 15K customers.\n\nIn 15+ years in tech and 7 years of managing engineering teams, I've worked in (and managed) both kinds of teams.\n\nIn [Peopleware](https://newsletter.manager.dev/p/the-7-best-engineering-management#2-peopleware) (one of the all-time best books about engineering management), the authors defined an excellent team as follows (they call it a ‘jelled’ team):\n\n**Signs of a Jelled Team**\n\nA few very characteristic signs indicate that you have got a jelled team:\n\nThere is a feeling of\n\n**joint ownership of the product** built by the jelled team. Participants are pleased to have their names grouped together on a product or a part of one.There is\n\n**low turnover during projects** and in the middle of well-defined tasks. The team members aren’t going anywhere till the work is done.There is a\n\n**sense of eliteness**, team members feel they’re part of something unique. They have a cocky, SWAT Team attitude that may be faintly annoying to people who aren’t part of the group.The final sign of a jelled team is the\n\n**obvious enjoyment that people take in their work**. Jelled teams just feel healthy. The interactions are easy and confident and warm.\n\nYou can’t make teams jell. You can hope they will jell; you can cross your fingers; you can act to improve the odds of jelling - but you can’t make it happen. The process is much too fragile to be controlled.\n\nI strongly agree with every part except the last one. I believe that **engineering managers CAN build excellent/jelled teams. **\n\nAn ‘okay’ team is not a bad team. It’s not dragging the organization down. It delivers new features, owns some product areas, solves customer problems, and slowly drifts along, like a fish in the stream.\n\nExcellent teams are the ones that change the trajectory of the company, and the ones every engineer in it will remember for the rest of their career. It’s definitely not about working twice as hard or having only ‘10x engineers’. In my experience, it’s just a few small habits, which are definitely up to us.\n\n*Inspired by **Julie Zhuo's excellent article** about what separates okay growth teams from excellent ones*\n\n## 1. Okay teams patch. Excellent teams know when to fix the root cause.\n\nIn [Shadow work in engineering teams](https://newsletter.manager.dev/p/the-shadow-work-in-engineering-teams), I shared an example from my own team. We had an annoying issue that took ~15 minutes to fix manually, and each hotfixer would just solve it and move on.\n\nOver months, the team burned 10+ hours on the same issue. Fixing the root cause would have taken 5-6 hours, but there were always more urgent things to do. This is how okay teams work. They patch, they move on, and then they patch again (and again). As time passes, the small fixes take more and more of their time.\n\nIt extends beyond bugs, it’s also the alerts you keep ignoring, the flaky test you restart instead of fixing, the manual process you keep doing because automating it \"isn't worth it yet\", and so on.\n\n**There are also ‘okay’ teams that take the other extreme.** If you spend all your time refactoring and solving issues, you’ll have barely any time for product work.\n\nThis genius table is the excellent team’s best friend:\n\nYou can see here that weekly 15 minutes is worth 2 days of your time to fix (across 5 years).\n\nLife is, of course, not as simple as a table - you don’t always know how often something will happen, or how long it’ll take to fix. In excellent teams, there is always a debate and a concrete decision, not just inertia.\n\nIn many cases, [killing the tiny annoyances](https://newsletter.manager.dev/p/killing-the-tiny-annoyances-in-work) is one of the highest-ROI things you can do.\n\n## 2. In okay teams engineers DO things. In excellent teams engineers OWN things.\n\nIn okay teams, everything goes through the Engineering Manager. You prioritize, triage, and decide what everyone works on, and they execute. You are basically a [human Jira router](https://www.practicalengineering.management/p/we-are-done-as-managers-according).\n\n*(I have this tendency myself, not judging here)*\n\nIn excellent teams, [engineers own kingdoms](https://newsletter.manager.dev/p/give-your-engineers-a-kingdom). A \"kingdom\" can be an application, a microservice, a 3rd party integration, or a critical tool. The engineer who owns it makes decisions about it, monitors its health, works closely with the PM, and is the go-to person for other teams.\n\nThe key is decision-making, not just responsibility. If you ask people to be \"responsible\" for just the bad parts (the on-call, the bug fixes), nobody will want it. The magic happens when you give them the authority to make real decisions. The [top reason why engineers quit](https://newsletter.manager.dev/p/why-developers-quit) is that they don’t feel challenged and growing anymore.\n\n**The more you let your engineers own, the more connected they’ll feel and act.**\n\n## 3. Okay teams unblock themselves. Excellent teams unblock others first.\n\nA great team that everybody in the organization hates is not a great team.\n\nHere’s a painful example (that I shared in [the delayed opinions givers](https://newsletter.manager.dev/p/the-delayed-opinions-givers-engineering)): My team had to work on another team's codebase. Their EM was busy, asked us to talk only to him, and then took 2 weeks to review our first PR. We were so frustrated that we just merged it and moved on. The quality suffered, and the relationship suffered even more.\n\nIf that team had dropped what they were doing and reviewed the PR within a few hours, what would it have actually cost? Maybe 2-3 hours of focused work time.\n\nExcellent teams put the needs of other teams before their own 90% of the time (yeah, I know that’s freaking hard).\n\nIf it happens repeatedly, the reputation you gain is of a team that always helps other teams. Being an engineer on such a team is a much more joyful experience. And of course, it’s not one-sided, other teams will be quicker to unblock you when things switch around.\n\n## 4. Okay teams execute the roadmap. Excellent teams shape it.\n\nIn okay teams, the PM creates the roadmap and engineering delivers it. The EM's job is to estimate, plan sprints, and make sure things ship on time. PMs are responsible for ‘what’, and we are for ‘how’.\n\nIn excellent teams, the EM and engineers are partners in deciding what gets built. They talk to customers, they understand the business, and they push back on features that don't make sense or when they don’t agree with a decision.\n\nOkay teams fall into the [victim trap](https://newsletter.manager.dev/p/the-victim-engineering-manager), complaining about bad product decisions. Excellent teams take ownership and do something about it. They are not satisfied with beautiful code and scalable systems. If the roadmap is wrong and you know it, it's your problem too…\n\n## 5. Okay teams stick to the plan. Excellent teams are willing to kill it.\n\nHave you seen a roadmap like this?\n\nYou pre-define phases 1,2,3, and follow through no matter what. When you get customer feedback after phase 1, you hear what you want to hear. Any negative signal about the future phases gets ignored, and the chances you will stop after phase 1 are very small.\n\nThis might seem like a product management problem - but very often the engineers are to blame! Because engineers complain so much when the code they wrote gets thrown away, it puts pressure on the PM to make the wrong decisions.\n\n[A decision to stop working on a feature is one of the best signs of a strong product culture.](https://newsletter.manager.dev/p/great-software-teams-dont-release) It means the decision-makers are listening to feedback and considering carefully what's the best way forward.\n\nBefore excellent teams start to work, they ask:\n\nHow are we going to measure this?\n\nHow is the success of the first phase defined?\n\nWhat will happen if the criteria are not reached?\n\nWhat can make us decide not to continue with this feature?\n\nThat last question is the toughest. I would be surprised if you get an answer in most companies.\n\n## 6. Okay teams launch features. Excellent teams land them.\n\nOkay teams treat deployment as the finish line. When the feature is in production, the PR is merged, and the ticket is closed, they celebrate and move on.\n\nExcellent teams treat deployment as the halfway point.\n\nThey ask:\n\nIs anyone actually using this?\n\nAre they using it the way we expected?\n\nDid it move the metric we cared about?\n\nAre there friction points we didn't anticipate?\n\nI've seen teams ship feature after feature, each one \"done\", while the product barely improves - **the features launched, but they didn't land.**\n\n## 7. Okay teams treat tech debt as a 20% tax. Excellent teams treat it as product work.\n\nOkay teams end up with 2 separate backlogs, and nobody on the business side understands or cares about the tech backlog. Your initiatives are always the first to be deprioritized when something \"urgent\" comes up.\n\nIn excellent teams, (almost) every technical initiative has a clearly defined business value, and it lives on the product roadmap, prioritized alongside everything else.\n\nThis requires the EM to actually explain the business impact of technical work. Not \"we need to refactor the monolith\" but \"if we move this logic to a new service our team owns, we can ship future features 3x faster without being blocked by other teams\".\n\nThis requires a very strong [EM-PM partnership](https://newsletter.manager.dev/p/working-with-your-pm), which is a critical building block for excellent teams.\n\n## Discover weekly\n\n[The steepest slope](https://suzansfieldnotes.substack.com/p/the-steepest-slope)- from being fired 6(!) times to COO. On unconventional careers.[Tokenmaxxing, Promomaxxing, and Misaligned Incentives in Tech](https://read.engineerscodex.com/p/tokenmaxxing-promomaxxing-and-misaligned). An interesting take on tokenmaxxing (the good and bad sides of it).[Atrophy - Mental Model: Use It or Lose It](https://read.perspectiveship.com/p/atrophy). It’s been only a few months but I don’t think I can write working code manually anymore 😅", "url": "https://wpnews.pro/news/okay-vs-excellent-engineering-teams", "canonical_source": "https://newsletter.manager.dev/p/okay-vs-excellent-engineering-teams", "published_at": "2026-05-26 06:01:00+00:00", "updated_at": "2026-06-21 09:43:30.528808+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents"], "entities": ["Manager.dev", "CodeRabbit", "CodeRabbit Agent", "Peopleware", "Julie Zhuo"], "alternates": {"html": "https://wpnews.pro/news/okay-vs-excellent-engineering-teams", "markdown": "https://wpnews.pro/news/okay-vs-excellent-engineering-teams.md", "text": "https://wpnews.pro/news/okay-vs-excellent-engineering-teams.txt", "jsonld": "https://wpnews.pro/news/okay-vs-excellent-engineering-teams.jsonld"}}