7 Principles for Effective Tech Teams

I’ve been leading teams longer than I’ve worked in tech. Needless to say I’ve made a lot of mistakes and learned a lot about what works and what doesn’t.

I’ve boiled down some of these learnings into a set of 7 principles that I use when building effective tech teams.

I hope you’ll find them as useful as I have!

1. Move fast, with direction

Most technology companies have an obsession with speed. “Move fast and break things” still echoes in the corridors long after Facebook abandoned the mantra. But what does it really mean to move fast? To produce more code? To release more features?

No. Speed is about getting from where you are to where you want to be. It doesn’t matter if you’re running at 200km/h if you’re running in the wrong direction.

One step in the right direction will always be more valuable than ten steps in the wrong direction.

2. Complete before you start

WIP (Work In Progress) is the hidden killer of productivity. Every started but not completed project is a cognitive burden weighing down your team. It’s also a sign that something is wrong in your process.

Often it’s about a lack of shared understanding of what actually needs to be done. Or worse - developers thinking they’re being judged on lines of code written instead of value delivered. By rewarding completion and limiting how much work is in progress at the same time, you lighten the cognitive burden and give yourself more opportunities for course correction.

3. Learning over punishment

A proper incident can cost millions, so it’s understandable that leaders fall into a punishment mindset. But if you punish people for mistakes, they’ll stop taking risks. And without risks, you’ll never innovate.

What you need to realise is that pain is a natural part of growth (ever gotten sore from a workout?). But being in pain doesn’t mean you have to suffer. If you choose to see every incident as an opportunity to learn, you’ll start celebrating the temporary pain because you know it leads to long term gain.

4. Blameless, not nameless

To build robust systems, we need to know when something goes wrong. And the more serious the mistake, the more important it is that we know about it quickly. But this can only happen in a culture where people feel safe to admit their mistakes.

A blameless culture doesn’t mean we don’t take responsibility - quite the opposite. It means we take responsibility for learning from our mistakes and ensure they don’t happen again.

5. Nothing is ever “done”

There’s a dangerous myth in the tech world: that things can be finished. But the truth is that the day you stop iterating on something is the day it starts to die. When you release a new feature, it’s not the end. It’s the beginning. Now you can finally start getting real feedback from your users. And that’s when you can truly start building something valuable.

This applies to both your product and your processes.

6. Want to, not should do

The words we use shape how we think. When you say “should” you implicitly give away your power to someone else and you’ll start feeling resistance towards the thing you “should” do.

But when you say “want to” you take back that power. “I want to backup the database” is an active choice to build the future you want. It’s a very different energy than “I should backup the database”.

7. Ownership, not tasks

It’s easy to hand out tasks. “Build this feature”, “fix this bug”. But when you do that, you miss out on your greatest asset - your team’s creativity and problem-solving ability.

Instead, let your team own the problems and the outcomes from solving those problems! When you give ownership of the problem instead of the solution, you open up for personal growth and innovation.