I repeatedly build high-performing teams
A while back I rebranded my online presence, and somewhere in the rewrite I lost a snappy line I’d written years ago about how I lead engineering teams. I’m at peace with the loss, but the idea behind it is worth keeping, and worth updating.
The original line went something like this:
Cj consistently builds high-performing, motivated teams, with a vision that team culture, morale, and employee engagement drive productivity.
I’m writing this near ninety days into a new role as a VP of Engineering, not really as an article, more for myself. I’m about to do the thing I do again: take an organization and build it into a high-performing, highly motivated team. To do that well, I need to reflect on what I’ve done before, keep what still holds, and adjust where I’ve grown.
Does it mean every team I join is broken?
If my whole thing is building high-performing, motivated teams, you might assume every team I walk into is under-performing and demoralised. Sometimes, sure. But often they’re already good. The point isn’t rescue; it’s good to great. You don’t hire a new leader just to backfill; you hire them to do more. (I tend not to take pure backfill roles anyway.)
So whether the intent is to transform or simply to maintain, change is inevitable, and my output stays the same. I want a high-performing team, and I want a highly motivated team. Two north stars. Although, as someone once pointed out to me, if you have two stars only one of them can be north. Add a third and you can triangulate your position. I’m still looking for the third.
Culture is still the engine
I believe today what I believed then: get culture, morale, and engagement right, have people who are happy and actually enjoy coming to work, and they’ll deliver more, and more consistently. That’s the path to productive, and eventually to highly productive.
The one word I’d change is “consistently.” I’ve now done this enough times that “repeatedly” is the more honest word. So: I repeatedly build high-performing, highly motivated teams.
Engineering as a service to product
Here’s what’s new in my thinking. I’ve come to see it as my responsibility, as the engineering leader, to build these teams for my product counterpart, to enable them to deliver the product against the roadmap. Instead of treating engineering as an isolated function, I position it as a partner to product leadership. In practice that means wearing three hats:
- Talent architect, assembling, motivating, and retaining high-calibre engineers.
- Execution enabler, making sure teams can ship effectively, without unnecessary obstacles.
- Force multiplier, ensuring tooling and infrastructure accelerate product development rather than hinder it.
This is the part many leaders get wrong: they optimise engineering in isolation instead of aligning it to the business it’s meant to serve.
The capital-cards model
One more idea I keep coming back to. Taking over a team is a bit like starting a board game, you begin with a small stack of capital, a few “get out of jail free” cards. You spend that capital with bold decisions. Make a tough call promptly, rather than letting it rot into management debt, and you burn a card without losing your team’s respect. Burn more cards than you hold, though, and you start losing faith.
The interesting part: over time, good decisions earn capital back, and your team stops being a single block, everyone holds their own cards and reacts differently to the same call. It’s also, I think, why leaders bring in trusted new hires. A new person arrives with their own fresh stack of capital. They can spend a card you don’t have to. And when they earn one back through a good decision, somehow, you get one too.
None of this is a step-by-step playbook. A leadership book isn’t chapter one, then chapter two, it’s more like a choose-your-own-adventure. It depends on who you have, what you’re facing, and which trade-offs you’re willing to make. This is just where mine stands today.