How Teams Go Faster
Hi all š
As I’m rebooting my blog / newsletter, I am continuing to play around with the format. This week I simplified my site design (it had gotten a bit messy over the last few years of gradual evolution), and also clarified my theme: I’m going to be writing about engineering leadership and productive product teams. I also expect to be writing more short posts like the one below where I share interesting ideas I’m reading about and how I’ve seen them play out.
This is part of a gradual evolution of my blog’s content, so if you were here more for the front end development content, feel free to unsubscribe, or stick around. All impactful development eventually tends to result in working on teams, and we all have a lot to learn about what it looks like to do that well.
I appreciate the support of all of you who have chosen to subscribe š.
How Teams Go Faster
13/13 Feels like fast … is actually faster
I recently discovered John Cutler’s Twitter and blog. Everything I’ve read from him so far is excellent and highly recommended, but this table in particular felt like it was worth sharing. It’s amazing to me how unhelpful our intuition often is when we’re under pressure to speed up. I’ve observed clear examples of several of these items personally over the last several years.
-
I’ve seen my team go significantly faster with less stress by shifting projects to being serialized with pairing and collaboration rather than giving everyone their own project 1
-
I’ve watched attempts to get ahead on planning be thwarted by changing business priorities. This can be frustrating in the moment until you realize the problem is a planning process that can’t adapt to new information cleanly.
-
I’ve been part of another team that doubled in size and then got cut back in half without much discernable impact in actual output over time.
-
The most effective change my team has made this year has been de-emphasizing filling sprints in favor of being clear about what we’re trying to accomplish in the sprint. I don’t think we’ve gone far enough in that direction yet.
Some items I’d add to John’s list:
- Manual QA / Deployments vs Test Automation as part of development2
- Senior devs filling up on feature work vs Senior devs mentoring, enabling and unblocking other devs3
-
Besides the creative and redundancy benefits of pairing, shared resources like PMs/EMs/QA become bottlenecks as you parallelize. ↩
-
This relates to the “handing off” QA point in John’s list. If the original people responsible for creating the feature aren’t writing automation as part of development, there is likely to be inefficiency or gaps in the testing. ↩
-
Even worse if this is a manager doing this, something I struggled with as I transitioned from being a dev-manager hybrid to managing a larger team. ↩