The Beautiful Mess

Share this post

TBM 52/53: Real Teams (Not Groups of One-Person Teams)

cutlefish.substack.com

Discover more from The Beautiful Mess

The beautiful mess of cross-functional product development
Over 35,000 subscribers
Continue reading
Sign in

TBM 52/53: Real Teams (Not Groups of One-Person Teams)

John Cutler
Dec 24, 2020
13
Share this post

TBM 52/53: Real Teams (Not Groups of One-Person Teams)

cutlefish.substack.com
Share

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:

  1. Knowledge silos, less knowledge share, less cross-training

  2. High work in progress (WIP)

  3. Fewer diverse perspectives. Not leveraging team perspectives

  4. Premature convergence (have to keep people loaded up)

  5. Less valuable work prioritized (to keep people busy)

  6. Competitiveness between team members

  7. Premature specialization

  8. Less ability to reorg to meet new challenges

  9. Overworked designers (catering to lots of teams)

  10. Micromanagement. Managers "manage" individual backlogs

  11. Less resilience. Over-reliance on managers as coordinators

  12. Success theater. Fights over high-profile efforts

  13. Rush to adopt novel technologies (as individual projects)

  14. Less sense of team ownership for decisions

  15. 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.

13
Share this post

TBM 52/53: Real Teams (Not Groups of One-Person Teams)

cutlefish.substack.com
Share
Comments
Top
New
Community

No posts

Ready for more?

© 2023 John Cutler
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing