The latest in this Lion King controversy is the greatest thing I've seen all week:
Lions and Tigers and Tiger teams, oh my!
Tiger teams, R&D teams - they're fashionable. Sometimes they mean pulling some of your best engineers onto a team to solve an existential problem. Sometimes they exist because the company wants to see what is possible with a given technology (AI anyone?) or in a given market - this is often just innovation theater. They have their benefits to be sure, and I've seen them work well at times. But, they have significant downsides.
First, they often involve breaking up existing, sometimes high performing teams. Those effects ripple through an org for months or years, with teams restarting forming/storming/norming phases. Harvard professor J. Richard Hackman's research showed that stable team membership is one of the single greatest predictors of high performance and that reforming teams can set them back by six months!
Second, they mangle incentives for engineers, in several ways:
- They move the "fun part" to a single team. That is, one team learns new technologies, gets to experiment, and doesn't have product deadlines. It's an engineer's dream. But, what is given to one team is taken away from others.
For example, one of the times I have seen a tiger team arguably work well is fixing an existential issue with a company's primary data store - a project that lasted a year. They solved the existential problem...success! However, the counterbalance to the tiger team was a team dedicated solely to KTLO. That team fixed bugs, all day, every day. If you want to spike attrition, that's precisely how you do it. - It creates an ivory tower anti-pattern in which the R&D teams often don't have to live with the consequences of their architecture decisions; other teams do, often under business deadlines (see Team Topologies).
- Third, when it comes time to hand over work to a maintenance team, the project loses all tribal knowledge. "Documentation is the answer" you say? Let's speak plainly. Engineers abhor writing documentation. Any excuse not to is good enough. And, even if they do and it is high quality (it isn't), nobody reads documentation.
The result is an architecture created in a vacuum, probably not battle-tested, handed to a team that knows nothing about it and who inherits the least enjoyable part of software development.
In my opinion, these types of teams can score quick wins, but there is no free lunch. Like most short-term fixes, the cost is higher in the long run. They are a tool in the toolbox, but reach for them with caution - and likely limit their lifespan. Modern frameworks like Basecamp's Shape Up or Intercom's product cadence heavily advocate for six-week cycles generally, treating six weeks as the hard ceiling for a tiger team's lifespan is a great place to start.
Comments
Post a Comment