What does an elite team look like today? 🥇
What does good look like in software engineering?
Over the past few weeks I have been interviewing several Refactoring community members. It’s mostly people who are responsible for engineering teams — EMs, tech leads, but also VPs of small to mid-size orgs.
I want to understand what’s top of their minds and what their biggest challenges are, so that I can help them better with Refactoring.
A question I always ask is: if you had a magic wand and could fix all the problems in your team, and make people work however you like, what would you do? Which is another way to ask: what does the perfect software engineering team look like to you?
How do people work together? What makes it amazing?
Most of the time, this question stops people in their tracks. They don’t know.
They might point at small improvements, like, would like to be a bit faster, have more tests, etc, but what’s the final goal? What does the best team look like? And yes, let’s accept there is no one-size-fits-all, but it doesn’t matter, you can still ask yourself: what does an elite team look like? And how close are you to that?
That’s because, without a vision, it’s hard to assess where you stand. Are you doing okay? How much untapped potential do you have? Can you do +10% (on what?!) with the same people, or—gosh—you might do 2x? 3x?
The truth is: nobody knows.
And if you think about it, this is infuriating.
As an industry, software development has no consensus on pretty much anything. Everything feels controversial: tests are controversial, docs are controversial, agile, tech stacks, team organization, and so on.
So we often look at stories from successful companies and draw our own lessons, but that too never feels 100% convincing. Google does this thing, but should we copy Google? “You are not Google, stupid!” Look what Anthropic does — yeah but that’s too weird. Basecamp? Man, those are like hippies, right?!
I don’t think we need a framework to fix this, but I think we can work our way from first principles and settle on a few mental models that can be helpful. Let’s try to figure out what good should look like — not to create a model to copy, but a direction to trend towards.
So here is the agenda for today:
🎽 Focusing on single teams — why nailing this is the most important problem in software today.
🏆 What makes teams good — the two qualities that are foundational for great teams.
🧱 Product vs platform — the two types of work that require different skills and workflows.
🪴 How to scale quality — turning expert judgment into process and constraints that empower everyone.
Let’s dive in!
🎽 Focusing on single teams
If I had to focus on one problem, that would be: how a single team works. How a small group of 5-10 people, working on a software product, can be effective at working together.
To me, this feels like the most important problem in software to solve.
In fact, on a scale that goes from individuals to entire orgs, the team seats in the middle and has an outsized influence on everything else: most of the choices you seemingly make at org level on one side, and individual work on the other, are actually downstream from how you want small groups of engineers to work together.
I’ll give a couple of examples.
Team Topologies, one of the most influential works of all time on how tech orgs should be structured, banks everything on the notion of stream-aligned teams. The big idea is how a single team should work, and the organization design just follows.
On the individual side, how engineers work largely depends on how the rest of their teammates work. What skills do they need (are they full-stack? or specialists?), what duties do they have (do you need tech leads? or EMs? or both?), how their career progresses, it’s all a consequence of the workflows of a core group of people. The atomic unit of your org.
And another reason why this matters is that, we always have big tech on our minds, but 90% of companies have less than 20 employees. For those companies, solving problems for a single team means solving them for the whole org. And we may also argue that all big companies start as small companies, so they have to graduate from there anyway.
I may throw also AI into the mix and preach on how it makes all of this even more relevant but I will spare you that — this is not an AI article (finally!).
So what makes single teams good?
🏆 What makes teams good?
There is a famous quote from Jeff Bezos about focusing on the things that are not going to change over time:
I very frequently get the question: ‘What’s going to change in the next 10 years?’ And that is a very interesting question; it’s a very common one. I almost never get the question: What’s not going to change in the next 10 years? And I submit to you that that second question is actually the more important of the two — because you can build a business strategy around the things that are stable in time.
In our retail business, we know that customers want low prices, and I know that’s going to be true 10 years from now. They want fast delivery; they want vast selection. It’s impossible to imagine a future 10 years from now where a customer comes up and says, “Jeff I love Amazon; I just wish the prices were a little higher,” [or] “I love Amazon; I just wish you’d deliver a little more slowly”.
— Jeff Bezos
A lot of things are changing in software right now, and are probably going to change over the next few years. So what are those that are not going to change, instead?
To me, there are two:
⚡ Speed — we’ll always want to ship fast.
❤️ Engagement — we’ll always want people to do engaging, challenging work.
The first one is obvious, the second less so. Let’s unpack both.