Manager.dev is proudly supported by CodeRabbit!
In 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.
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.
In 15+ years in tech and 7 years of managing engineering teams, I've worked in (and managed) both kinds of teams.
In 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):
Signs of a Jelled Team
A few very characteristic signs indicate that you have got a jelled team:
There is a feeling of 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 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 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 obvious enjoyment that people take in their work. Jelled teams just feel healthy. The interactions are easy and confident and warm.
You 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.
Peopleware
I strongly agree with every part except the last one. I believe that engineering managers CAN build excellent/jelled teams.
An ‘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.
Excellent 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.
Inspired by Julie Zhuo's excellent article about what separates okay growth teams from excellent ones
1. Okay teams patch. Excellent teams know when to fix the root cause.
In 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.
Over 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.
It 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.
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.
This genius table is the excellent team’s best friend:
You can see here that weekly 15 minutes is worth 2 days of your time to fix (across 5 years).
Life 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.
In many cases, killing the tiny annoyances is one of the highest-ROI things you can do.
2. In okay teams engineers DO things. In excellent teams engineers OWN things.
In 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.
(I have this tendency myself, not judging here)
In excellent teams, engineers own kingdoms. 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.
The 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 is that they don’t feel challenged and growing anymore.
The more you let your engineers own, the more connected they’ll feel and act.
3. Okay teams unblock themselves. Excellent teams unblock others first.
A great team that everybody in the organization hates is not a great team.
Here’s a painful example (that I shared in the delayed opinions givers): 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.
If 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.
Excellent teams put the needs of other teams before their own 90% of the time (yeah, I know that’s freaking hard).
If 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.
4. Okay teams execute the roadmap. Excellent teams shape it.
In 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’.
In 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.
Okay teams fall into the victim trap, 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…
5. Okay teams stick to the plan. Excellent teams are willing to kill it.
Have you seen a roadmap like this?
You 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.
This 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.
A decision to stop working on a feature is one of the best signs of a strong product culture. It means the decision-makers are listening to feedback and considering carefully what's the best way forward.
Before excellent teams start to work, they ask:
How are we going to measure this?
How is the success of the first phase defined?
What will happen if the criteria are not reached?
What can make us decide not to continue with this feature?
That last question is the toughest. I would be surprised if you get an answer in most companies.
6. Okay teams launch features. Excellent teams land them.
Okay 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.
Excellent teams treat deployment as the halfway point.
They ask:
Is anyone actually using this?
Are they using it the way we expected?
Did it move the metric we cared about?
Are there friction points we didn't anticipate?
I've seen teams ship feature after feature, each one "done", while the product barely improves - the features launched, but they didn't land.
7. Okay teams treat tech debt as a 20% tax. Excellent teams treat it as product work.
"20% for tech debt" doesn't work.
Okay 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.
In excellent teams, (almost) every technical initiative has a clearly defined business value, and it lives on the product roadmap, prioritized alongside everything else.
This 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".
This requires a very strong EM-PM partnership, which is a critical building block for excellent teams.
Discover weekly
The steepest slope - from being fired 6(!) times to COO. On unconventional careers.
Tokenmaxxing, Promomaxxing, and Misaligned Incentives in Tech. An interesting take on tokenmaxxing (the good and bad sides of it).
Atrophy - Mental Model: Use It or Lose It. It’s been only a few months but I don’t think I can write working code manually anymore 😅
