Leading at the code-face

Balancing technical leadership with writing code

I write code. I’ve been doing it since about as far back as I can remember. It’s what I do. For a few years I backed off the code and decided I was a “designer”, but at some point it dawned on me that “designing” was the same as “coding”, and that actually writing code is just a subset of design.

I threw myself back to the code-face and away from dealing with clients, back to the minutiae of bugs, setting up your environment and googling for answers. Back to the joy of solving a hard problem. Back to the frustration of realising you’ve spent a week solving the wrong problem and having to start again. Forwards into constantly learning and being part of big project—the Web.

As is the way with a career, and as the things you work on grow, and your skills and knowledge grow too, at some point someone is going to suggest that in order to progress, you’ll have to consider the m-word. Management.

To code or to lead?

Many software and startup people shy away from that word. As well as writing code, I’ve also been responsible for leading several teams, and I’ve also got a love-hate (mostly hate) relationship with the word.

As a hacker, someone who loves the immediacy of creating things with software, I’ve repeatedly struggled with the difficulty of at once trying to get into a flow state of personal productivity, and yet also trying to guide a team towards a good ongoing momentum of productivity.

There’s a realisation that kicks in as your startup grows. As your role moves from “just me writing code” to “me and a handful of others writing code”, and on to “a team of people writing code and I’m in charge” something becomes more and more clear.

To really get anything done, to really build something valuable and useful, to build the right things in the right way it, probably means not writing so much code and spending more time helping other people to write their code.

But there’s no way that I can build Makeshift, and develop new things in our hacky, rapid, seat-of-the-pants way, without actually writing code! It’s not why we set up the company. We’re makers. There has to be a happy medium, so I’m developing a few principles that could help keep the balance.

Unstick the team

I suspect this is true in any career, I just use my own story by way of example. I have a simple principle, though, that seems to enable me to keep up the craft of being a hacker, as well as helping a team to grow:

Unstick others
before you get stuck in

People get stuck. In software possibly more than other fields. Sometimes, something just won’t work. And the complexity involved can be baffling. We often talk about the “stack”—the collection of inter-related pieces that form a piece of software.

When there’s a bug you have to be able to investigate every single piece of that stack to find out where the problem is, and then work out how to fix it. For that task, two people working together often makes more sense than one alone, because you can often miss a tiny detail by yourself.

If you’re on a team, and your aim is to be building something together, it’s important that people aren’t blocked from doing good work by tripping over these sticky bugs too often. So when I see it happening, if I can, I stop what I’m doing, accept the cost of the interrupt to my own code-productivity, and assist others. In time, I’m hoping that this will encourage us all to be working similarly. More on that later…

Be headphones-on

Sometimes, you need to put the shutters up and focus. If I’m headphones-on (an odd turn of phrase, I know) you can’t interrupt me. I’m literally wearing a bright yellow pair of headphones, and you can’t miss the fact that I need a little privacy!

If someone really needs to interrupt me, then it’s implied that it should be reasonably important, not a “tap on the shoulder chat”. Asynchronously, sure, maybe via Hipchat, but unless it’s a blocker like the one above, you should know that I’m in the zone and might not appreciate it.

I get good work done when I’ve got headphones on, as do many people, and the wearing of headphones is a good visual message to those around you to respect the fact you’re in that mode and not to interrupt. As we know, interrupts are best avoided in order to encourage flow and solving complex problems.

Use an away desk

For me, the opposite of headphones on, is being at home during the day. My home is now a little busy with noisy kids, and I don’t have a space there that’s quiet except in the evenings, like now.

One thing I may start trying is going to a third space to get things done—a co-working space, an arts centre, a cafe, on a train, booking a meeting room, and using that time to make a dent in a project. It’s probably to be encouraged in others too.

Having a studio (not an office!) is a great idea, and the bouncing around of ideas, the emerging shared culture of an early stage startup, the serendipity of the place, yet sometimes, it’s important to have a non-work, non-home space to work in. I call it an away desk—you’re at work yet you’re slightly removed.

Distribute responsibility

I’m one of those “consensus-seeking” people, and I’d much rather bring people along with me than tell everyone what to do. In part I think that’s because I want to build a company where there is a distribution of responsibility and a practice of mutual code-review, design-review, collaboration and decision-making.

I’ve been reading a little about the Holacracy movement recently. Aside from the faintly religious feel to the way it’s communicated, I suspect there’ll be a change coming around how people who work in technology expect their teams to be structured. I’m sure people laughed at Agile a few years back, so I’m keeping an open mind.

For now, my big challenge is to make sure I’m not a bottle-neck in getting things done, and that’s something that is tackled by methods of team organisation like this. I’m hoping that technical responsibility for the things we make can be distributed amongst the team, that there is a sense of peer-review and peer-ownership of what we build and the code we write.

Being a hacker, and trying to build a company of people of a similar mindset, I hope by encouraging the distribution of the process of making digital products, we can find that ultimate place where we’re doing what we enjoy, what we’re good at and what we can make money doing.

Keep maker-founders makers

I think it’s a strong thing for an early stage tech company like mine that the people who founded the company are also the ones building it line of code by line of code, git commit by git commit, pull request by pull request.

Paul Graham’s phrase “hacker eyes”, although sadly surrounded by a twitter storm, reinforced this for me this week. It suggests to me that good businesses and investment opportunities come when you get a team of hackers/makers in a room, working well and writing code together to solve problems that they have themselves.

So I’ll continue on trying to find the balance. If you’ve found something that works for you, let me know!