The 4 States of Engineering Teams
As I make my way through An Elegant Puzzle I'm going to be documenting some of my thoughts and reactions. Today's is around what Will Larson calls "The Four States of a Team".
In the book, he prescribes system fixes to each of these states (even when things are going well). I'm going to be looking at these states as they apply to teams I've been on as an engineer.
Falling Behind
Conditions: Growing backlogs week over week, people working hard without making progress, low morale, stakeholders and users are upset.
After I read how Will described this state, I audibly said: "I've been on that team. I quit that team." It was hard because I got along great with my manager and my team, but when I looked at the big picture of our organization I saw the epitome of "working hard without making progress".
From what I could tell (with my narrow scope) was a technical debt problem the size of Mt. Everest, where most of the mountain top is obscured by clouds. From what I could tell, this was an organization-sized problem that required a company-sized solution.
Absent any structural problems, if your team's backlog is growing and people are spinning their wheels to get things done; it makes sense to follow Will's advice to add more people to the team.
I've actually had conversations with my current manager over the last few months where the consensus is: "I don't really know if we would benefit from new hires." Not because we don't need them, but because we're not ready to fully utilize them. It's only been recently that we've identified gaps that we can fill by hiring someone with the skills we need on the team.
The most interesting thing to me about how Will writes this, is that the team isn't falling behind because of individual performance; but a failure to meet the external demands of the team. He seems to focus a lot on aspect of delivery teams which I really like.
Treading Water
Conditions: Critical work gets done, but not able to pay down technical debt or begin major projects. Morale is higher but people are still working hard.
The line "critical work gets done, but not able to pay down technical debt" really stood out to me. If I were to project this onto my current team, I'd say that we don't culturally tackle technical debt because we're a sponge for new feature work. A lot of the work we do is generated organically, so it's not like we have a large product organization that's waiting for us to ship features.
That's something that I want to tackle in 2021, namely because I think a lot of good things happen when there's a healthy back-and-forth between product and engineering. There's some negotiating of features coming down the pike which also sets realistic expectations for what technical debt can be tackled.
After looking back at the book, Will's suggestion is to do exactly what I wanted! Reduce the WIP (Work in Progress), by allowing the engineering team to focus on work and get it out the door. Instead of having a bunch of folks work in a bunch of different directions.
Repaying Debt
Conditions: Team is able to start paying down technical debt and benefitting from the debt repayment. Where each piece of debt paid leads to more time to pay more debt.
I think this is probably how I would describe the first engineering team I was hired on to. Right before I joined, the team did this major refactor which made it easier to test a UI component locally (without an online test environment). We mocked out all of our network calls, and essentially wired up the components against that.
The test environment was incredibly faulty, and we'd often joke about how there needed to be sirens for when the environment was back up and we could test our code. Thankfully, because of the debt repayment done beforehand our team was able to ship way ahead of schedule. We were constantly evaluating new tools and techniques that would keep the codebase clean.
One of the best compliments I've ever gotten about a product I worked on was: "this codebase looks like it was written by one person."
Even though this seems like a pretty optimal place to be, Will says that the system fix is to add time. You're supporting users and paying down debt, and you just need to let that machine work over time.
Innovating
Conditions: Technical debt is sustainably low, morale is high, and work is satisfying new user needs.
This is the last state! I don't know that I've ever been on a team that reached this nirvana moment; so I don't have much to add personally. Despite knowing very little about cars, I often describe engineering teams as engines. You have basic inputs of work items and engineer hours, and an output of feature work. If there is a massive imbalance there, the engine is not going to perform well if at all.
Will's system fix in this case is to add slack, allowing the team to keep doing what they're doing and maintaining the level of low technical debt that keeps them innovating.