All power to the Teams

Teams should be the core entity. The primary unit of work within an engineering team.

Teams should be cross-functional: all needed roles should be there – and when I say all, I mean every role – not only coding. The customer should be there. If not possible, a customer advocate (say, a Product Owner) is a valid, common alternative.

The Software

Software teams should focus on producing running, working, and tested code as soon as possible.

Every week better than every month, every day better than every week. Every hour better than every day. As. Soon. As. Possible.

The value provided through delivered software should be aligned with whatever goal the team is trying to achieve. Teams should have product-focused conversations. Getting closer to goals in a sustainable pace should be the center of every discussion.

The software should be clean, its design should be simple so that it can evolve freely. The team should always design and code for today and not for tomorrow. Refactor should occur relentlessly. Slow is smooth, smooth is fast.

The Stability

They should be stable. There’s sooo much benefit in having a stable team over a period of time. This is where accountability, ownership, and predictability grows. It is the only time I’ve seen a team run like a well-oiled machine. Stable teams over project teams.

Does it mean teams should never change? No, it doesn’t.

Does it mean team stability should be a top priority? From my point of view, it should.

Does it mean teams should have a voice when decisions are made about the team itself? Oh, folks, yes it does. Sure it does. A team’s autonomy diminishes after each imposed decision.

I’d rather have a team change its goals rather than split its members apart.

The Big Picture

Teams should not forget the big picture. They do not live in isolation – there might be other teams, other goals, urgencies. Yet, they should be the ones figuring out the best way to help the organization move forward.

Make sure teams have a purpose, enough autonomy, and hunger for mastery.

Say it louder! Make sure their purpose is clear, and over-comunicate it. Can’t stress this enough. Autonomy without purpose is like running in circles. You might see some sort of movement, but it will get you so far.

Also: a team should know the constraints they work with. What is the team supposed to do? What’s its goal? What are the organization expectations of it? What’s the circle of competence people is expecting from it?

---

Take this with a grain of salt, it is not The Truth™. This is just me yelling at clouds.