Those following along at home will know that I recently wrote about the place of responsibility and ownership in software development. While valid throughout software engineering, ownership is especially important in the context of a rapidly scaling software business – we need to be able to rely on developers to get things done without a massive layer of management whom we neither have the time to recruit, nor the culture to support.

The seminal Netflix culture  slide deck (yeah it’s a doozy – I’ll wait while you read it), illustrates this wonderfully as the point where the growth rate of the business out-paces the density of high-performing individuals. This is traditionally the point where layers of management and process are introduced to deal with the ensuing chaos.

First ever 747The clue to solving this is imbued throughout that Netflix deck too: trust. Without trust we can’t expect responsibility to flourish. Without trust we sit on the shoulders of developers, imposing restrictions and demanding feedback. Proponents of Agile would call this an impediment.

So what does trust look like in a rapidly growing engineering team?

Solving the right problems

Newly minted development managers coming from a technical background (and there’s an argument they should only be from a technical background), often feel to manage developers one needs to prove one’s technical prowess. I’ll admit to falling into this trap myself, especially when working with a new team. If they don’t respect me as a coder, how can I have any authority?

Here’s the thing: the problems you need to solve as a technical manager are by definition non-technical. You need to create an environment in which the engineering team can execute to their potential, and otherwise just get out of their way. The last thing you need is technical authority. I suggest you get your technical jollies forking MEAN at home, and use your fading technical knowledge when liaising with the business, but otherwise close Sublime Text or Visual Studio and walk away.

Do you trust your team to choose the right libraries, architect solutions, solve loosely-defined technical problems, and code to their best abilities? How about do you trust the team to deliver a solution that is the best mix of JFDI and polish for a given timeframe? If you don’t, then you have a problem infinitely larger than your technical abilities could ever solve.

So, what problems should you be solving in order to build responsibility and ownership in your engineering team, and build a self-propelling engine of international awesome?


Work with the business to make sure the engineering team are working on the right thing, right now. Help them understand how to build the right way. The right thing of course means the number one (or two or three) thing that must be built to bring delight to your customers (new or old).

Here’s one I prepared earlier.


You are undoubtedly right to abhor a 50-page technical specification, but you do need to demand enough information so that engineers can understand the scope of the task at hand, and ensure they can connect to the right people to get the detailed answers as they build. This might be Product Management, or perhaps direct customers. Facilitate and engage, then leave them to it; don’t dictate.

You need to be a navigation buoy in the flow between engineering and their stakeholders, rather than an hourglass through which all information must travel.


Provide space and time for the team to lay their foundations. Documentation, tooling, code reviews, training, recruiting, onboarding, communication, experimentation. All of those things that are “invisible” to customers but oh so incredibly important to the smooth operation of a dev team and the production of world-class software.

You need to be the advocate for this behaviour, explaining to the business why it is essential. But trust, trust that the team can execute this foundation work themselves.


If you’re getting a lot of the above right, then your team will be a fecund swamp of talent. Engineers will be popping up and seeking out challenges. It can be super tricky to find opportunities for growth in a small team and company, but one simple way to promote growth is to delegate ownership as much as you can, because this supports the growth of both the team and the individual – things you need to be happening as the team size grows.

You can also facilitate internal presentation sessions to foster talent within the team, then support your engineers if they want to present externally.

Use your gut feel and previous technical experience to pinpoint areas for improvement and work with each engineer individually to help them improve those areas. We’ve found some benefit in plotting a modified Urban Airship Tech Ladder across four axes, which can show where an engineer perhaps excels in some areas but can improve in others. Great food for growth!

Output will flow

I imagine some readers are having heart palpitations because I haven’t mentioned delivery, or deadlines, or output. My assertion is that if you get the above right – especially focus and clarity – output will flow. Sure you can tweak the dials on time spent on foundation vs delivery work, but only for short periods of time.

Trust the team. They will deliver.

TL;DR version: Are your engineering managers solving the right problems, or are they an impediment?






When I lack focus, I often feel like I’m doing all the right things, but getting nowhere. Swimming in a vacuum is the best way I can describe it: no amount of attention to technique or increased pace is going to make a difference if I don’t have a medium to pull against. My personal focus is my task list. I’m not perfect, but when I compare those days where I religiously tick off my prioritised tasks with the days that I drift, the difference in output is stark.

bokehLikewise, without focus a software engineering team can look and feel like they’re doing great, but not make headway. You can have all the right pieces set up just the right way, but all for naught. No amount of engineering talent, no fantastic working environment, nor great team culture can make up for a lack of focus. It’s that important.

So, you’ve got – quite literally – infinite possibilities in front of you. How do you focus? I’m still working on it, but I reckon it comes down to this: build the right thing, the right way, right now. I laugh at how simple that sounds, but so many times I’ve been caught out by how uncommon common sense is. You may too very well scoff, but let’s take a look at these things in detail.

The Right Thing

The number of paths to take can be utterly overwhelming, so how do you choose the next one? Regardless of how you choose, know this: you must choose. Without a clear priority order of problems to solve (aka engineering tasks), you doom your team to endless half-assery and direction change.

It’s ok though, you don’t have to choose once and never change, you just have to choose the next thing. The next thing is what your engineers are building right now, which could be multiple things at once if you have multiple teams. Define it and get building it (the right way, right now), then you can go back to choosing the next right thing. Even if you chose the not-quite-right thing, getting that clarity for engineers means you can move on to the next right thing rapidly, while accruing some value from a completed feature. Getting to Done is fundamental.

Deciding the right thing is specific to your project and is a real product management art, but choosing a metric will help. Rank your opportunities according to those that will move that metric the most in the shortest amount of time, and pick the top one. You’ll quickly discover if your metric is incorrect.

The Right Way

Great engineers understand the difference between technical debt and slop. Never do slop. Slop is crappy method names, 10k-line JavaScript files, and nested for-loops with SQL queries in each. Technical debt however is a considered approach to build something in a sub-perfect way. Technical debt is choosing not to build this feature to cater for all the possible future uses. Debt (technical or not) is leverage, and your engineers should understand that leverage – used wisely – grows companies.

If you don’t have automated testing, continuous integration, and push-button deploys then you’re absolutely not doing it the right way.

The Right Way also speaks to culture. If you’re burning out, not communicating with everyone in the business, or not building the skills of others in your team, then you’re not building the right way.

Lastly, the right way means engineers understanding the problem that is being solved. Product management has a huge part to play here, defining and articulating the business opportunity represented by building the right thing. Done well, this serves as an inspiration to the engineering team, whereas a poorly defined problem leaves engineers adrift.

Right Now

Some call it “Lean”, but we call it JFDI: Just Fucking Do It. Don’t wait, don’t agonise over every nook and cranny. Make mistakes, fix them – rely on your fantastic devops and test procedures to help catch them. Deploy urgently and measure.

You’ve decided the number one priority for the business, you know how to build it, so dig in and do it right now.

Check Yoself

So, with an understanding of what lies behind the sentence, we can check on the quality of our focus by continuously asking: “am I building the right thing, the right way, right now?”.

Well, are you?




So, this happened.

It was a mix of completely surreal and utterly mundane. Well, as mundane as you can get at a pool party with 3 indicted internet millionaires catered by their butler.

We talked about all the things you’d expect – the heavy-handedness of the original raid, how they coped for months without internet (“it was really boring”), and their prospects for the future. They are confident nothing will come of the charges, but are keen to defend themselves legally to whatever degree they need to.

Perhaps the most amazing part of the night were Bram and Finn’s compliments about the Hallertau IPA we took along. I was surprised to see a German drinking terrible piss-water (Heineken), and happy they liked a good drop.

If you want to know how it happened, the Listener’s inimitable Internaut column, and The NBR have it all.