TBM 52/53: Real Teams (Not Groups of One-Person Teams)
I was chatting with a product development organization recently.
I asked how many teams they had.
"10. Around 60 people total."
It turned out they had ~50 teams. Why? Their teams didn't operate as actual teams. Instead the teams operated as groups of one person teams (with managers doling out and managing the individual backlogs).
I remember an engineering manager (from a different organization) explaining their predicament:
How am I supposed to performance manage people unless they have their own projects? Also, it is important that I match the projects to the team members. They are all eager to move up, and want to prove themselves.
When I asked about pairing, I got:
Good engineers shouldn't need to pair. They don't like it. People like to have their own project.
This dynamic/perspective is very common. It gets ingrained in incentive structures, the org chart, and career ladders/progression. In my experience, working this way puts you at a serious risk for:
Knowledge silos, less knowledge share, less cross-training
High work in progress (WIP)
Fewer diverse perspectives. Not leveraging team perspectives
Premature convergence (have to keep people loaded up)
Less valuable work prioritized (to keep people busy)
Competitiveness between team members
Premature specialization
Less ability to reorg to meet new challenges
Overworked designers (catering to lots of teams)
Micromanagement. Managers "manage" individual backlogs
Less resilience. Over-reliance on managers as coordinators
Success theater. Fights over high-profile efforts
Rush to adopt novel technologies (as individual projects)
Less sense of team ownership for decisions
Culture of heroics
So why do people work this way?
Because it is easier on many levels. There's less confrontation. It fits into common ideas about the role of middle management. It is easier to manage individual employees. One could argue it is "less risky". As a developer friend recently put it:
It backs up the idea of individual developers as mountain movers if left alone. It supports stereotypes of developers as anti-social and disinterested in collaboration. And it supports the idea of manager as individual caretaker vs. team supporter.
And another developer friend:
In the short term, working this way is faster. You can do more at once.
That is a lot to counteract (with short-term benefits). In orgs with high turn-over, it seems way easier. But I believe that to have great product teams, you have to work as a team. No that doesn't mean you have to pair or mob program (though I do like these approaches). But striving for fluidity and less Tetris playing can go a long way.
Start with not pre-binding individual efforts to individual engineers.
