Team structures, writing comfort, and task-relevant maturity 💡
Monday Ideas — Edition #108
1) 🎨 The Four Types of Teams
The best book I read last year was Team Topologies, which significantly changed how I think about structuring tech teams.
One of the main ideas from the book is that you can identify four types of teams: stream-aligned, enabling, complicated-subsystem, and platform teams.
Let’s look at them:
🏆 Stream-aligned Teams
These are teams who own and work independently (e.g. cross-functionally) on a slice of the business domain.
One of the key lessons from the book is that stream-aligned teams are the most important teams. Other teams are basically there to reduce the cognitive load of stream-aligned teams.
🧑🏫 Enabling Teams
Enabling teams are about developing skills.
They research new best practices, or new tech, and are consulted to improve the output of other teams. The final goal is to transfer such knowledge to stream-aligned teams, not to retain it themselves.
🧶 Complicated-subsystem Teams
These are teams that work on niche problems that require specific skills, that would otherwise bottleneck the work of other teams.
Examples are areas where you need specialized skills but only occasional involvement. Think of specific algorithmic work, audio-processing, or infrastructure tuning.
🏗️ Platform Teams
These are teams that build infrastructure that is used by other teams and enables their work. Infrastructure here is meant broadly: think of CI/CD, tooling and any product/framework born for internal use.
Platform teams are similar to stream-aligned teams in that they own their work — with the difference that their customers are other teams, so they are inward-facing.
You can find the full book review here 👇
2) ✏️ Optimize your writing for your comfort
Being a full-time writer, people often reach out to me for advice about starting a blog / newsletter.
Many find it hard to start because they're not sure what to write about, what the perfect topic is, the perfect niche, and so on.
I know it well, because I was one of them.
In hindsight, my advice is simple: write about what you are comfortable with. At least at the beginning, optimize for your own comfort, rather than your hypothetical niche.
The reason for this is that writing is a long game. It compounds over time, but it requires you to show up every week. Talk with any writer and they will likely tell you that consistency is the #1 reason behind their success.
I believe most professionals who start writing face a higher risk of not being able to be consistent, rather than not finding an audience. In fact, almost everyone has something interesting to say. Each of us has a unique experience: as long as we speak with honesty, we will likely say interesting things.
Last year I published a full free piece about how I write Refactoring (I might do a refresh this year 🤔), which you can find below 👇
3) ✅ Task-relevant maturity
In his seminal book High Output Management, Andy Grove coined the fantastic term task-relevant maturity to express an employee’s overall readiness to take on some responsibility.
Grove breaks TRM down into many factors, but I will simplify and consider two main ones:
🎓 Skill / Familiarity — the employee’s chops that enable her to take on the task.
📋 Quality of the Context — how mature and well documented your definition of good is.
Both items are crucial.
Say you need to create a design doc around a new product feature. You may have the best engineer in the world, who has done hundreds of them in their career, but they still need context from you:
Task-specific: what set of tradeoffs should they consider? What about speed? Or scale?
Principles: what do design docs look like on our team? How do you plan rollouts? What about rollbacks? How does the code get instrumented?
So, the right amount of management depends on the level of TRM:
🔴 Low TRM — your teammate (or group) hasn’t done this before and/or there is no existing procedure for it. In this case, give detailed instructions, possibly pair regularly, and establish a close feedback loop. Don’t let them do too much work without hearing from you, correct often and update the procedure with your feedback continuously.
🟡 Medium TRM — your teammate has completed similar tasks before and has an idea of what good looks like, coming from experience and/or good docs. In this case, give the best possible context about the goals to be achieved, and leave them free to execute. Keep communication lines open to give support whenever needed.
🟢 High TRM — your teammate has completed plenty of similar tasks in the past, with good results. In this case, other than giving full autonomy, you can challenge them to improve the definition of good. What can we do better?
I wrote more about delegation, autonomy, and micromanagement, in this recent piece 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the paid version — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca