I’m an engineer, how do I become a tech leader?

I had questions when starting my career, more since and plenty today. I’ll give my personal story for the ones I’ve experienced and bug a friend or two for the ones I haven’t. A few other topics I’ll be covering:

• Now I’m running tech, what will my day-to-day be?
• Hiring is hard, can I make it easier?
• I have my first reports, how do I get the best out of them?

I’m an engineer, how do I become a tech leader?

Is leadership right for you?

As a young programmer at the start of uni, jobs that involved more than just programming seemed unattainable to me. It was fortune that got me in to startups where I became exposed to more than just writing code.

My friend at uni showed me a cardboard box full of snacks like fresh fruit, dried seeds and chocolate that the company had picked based on his preferences. The box had a personalised insert inside with his name, info on the snacks and his own referral codes for him to tear off and give out. I could see that this company involved stuff way beyond your normal snack company. A bespoke e-commerce site, an algorithm picking the snacks, a factory printing the inserts and pulling everything together. The company that was blowing my mind was graze.com and I knew I had to get involved.

What I didn’t realise was that by choosing a product based startup for my first job I had chosen a role that involved more than just coding. This is the first thing that you need to ask yourself. Regardless of whether you become strictly a technical leader (like a lead developer) or a more people orientated leader you’ll be doing more than just programming. If that’s not your vision of the future, if you think that interaction with the product, with marketing and with other leaders of business is not what you have in mind for your day-to-day then I would suggest a different track.

There are plenty of other ways to grow as a programmer. You can become a “technical architect”, a “principal developer” or any number of other titles. You’ll always have to interact with product and people to a degree but not to the same extent. There are plenty of great articles about why leadership might not be for you, and that’s really ok.

The first steps

Still with me? My first job threw me in to programming in a way I didn’t expect. I had done a fairly theoretical computer science degree and I thought I knew the way things were meant to be done. However, I knew nothing about how that applied to business and even less about how it applied to a resource strapped business.

My first lesson in business was prioritisation. Our todo list was mountains bigger than our done list and the tech team was only 5 people. We had to be brutal about what got done and that meant everyone in the team had to prioritise. My first taste of management was negotiating my own time with other people. I’m sure if I had pushed back at this stage and said “I’m not very good at prioritising, it’s best if you just give me stuff to work on” I would still have kept my job but I certainly would have stayed a programmer. Instead by choosing to engage with other people and the product I had to learn a new skill, business itself.

How this affected my programming was learning about the relationship between startups and pragmatism. No matter the size of the company, you need to make decisions about how much you can do. For instance, we could accept bad code to some extent but we could not accept sloppy looking product. As it happens we still mostly wrote good code but we definitely adjusted for the time we had, for getting stuff to market. I might have tried to push for more time to code better but that would have wasted the time of my colleagues. It was much quicker for me to look at the business and make that call myself.

I call this leadership scope creep. My job demanded that I become a leader in order to work effectively with the resource available to us. That’s what it is to be a programmer in a tiny company. You need to decide whether you want to stop being in control of prioritisation (read: strategy) as the company grows or whether you want to expand it and become a leader. Another question that will determine your future just as much: Do you enjoy managing people or do you just enjoy technical mentorship?

The programmer’s dilemma

The difference may seem subtle at this stage but it’s an important one. First up are some definitions. I was not managing people back at graze, I was providing mentorship. Managing people, to me, is where your performance is directly tied to the performance of those people. Technical mentorship is less direct, where their performance impacts the code or environment you are working in but doesn’t directly reflect back on you.

You can zoom out at this stage and ask yourself which you are comfortable with, management or mentorship. If you are uncomfortable with someone else reflecting poorly on you, management might not be for you. I didn’t know the answer at this stage, but I knew I wanted to be more involved in product and to mentor more people.

Taking the plunge

I loved my first job. It was a crazy place where we built crazy things that I only dreamed I could be involved in. Deciding to quit was a painful decision that underlined a commitment I made to myself to explore business further. That’s what leadership meant to me at that stage. I respected and admired my bosses at graze and wanted to emulate them. I thought the best way to do that was to learn on the job just as they had done.

Three years after joining, I quit graze and took a CTO role at a small startup selling school yearbooks. Although I was excited about the product it was secondary to learning about the business. Being a startup CTO isn’t a great deal different than being a senior developer in a bigger company. There is no team to begin with, you will be inputting on strategy/product and you will still be a technical architect. The difference will be that it will no longer be on the microcosm of your own work but on the macro of everything the company has to achieve.

Don’t panic, just follow these simple steps:

1. Do some strategy, architecture and programming to make sense of the most important parts of the code
2. Hire someone to take them over when you’re at a “good point”
3. Provide mentorship for the incoming people and help guide their decisions on what to work on
4. Repeat

I did all of this pretty badly. I spent way too long on point number 1, completely underestimated number 2 and didn’t align number 3 with the company objectives. However, we did enough of everything that technology stopped being the bottleneck of the company. What I mean by this was that the success or failure of the company previously rode on the fact that technology was getting in the way of innovation. We were now able to innovate fast enough, even if we didn’t take the most efficient route there. I loved this.

Iterate to level up

Coming out of that first CTO job I really felt like I knew what I had done badly and what I had done well and I was excited to take on my next challenge. Sort of by accident I went back to basics as a senior developer at the flower company Bloom & Wild. This turned out to be really great as I was able to grow in to my role again. It also allowed me to focus on the things I really needed to focus on. I avoided the hardest parts of hiring because the CEO did most of it and I was able to ease in to managing people over time.

I also came at the problem differently. I focussed heavily on getting the foundations down as quickly as possible, this meant writing a lot of code and getting stuff shipped. There was one other developer and some contractors doing the iOS app. We projected ahead as best we could but essentially it was getting done the stuff that counts. I then followed the same formula as before: hired people to work on the bits that we had laid foundations for, provided mentorship, gave guidance and repeated.

By not spending too long laying foundations, and by hiring at the right time, I had enough time to contribute to the company’s business strategy. We saw great success as a result and it was enough to secure me a promotion to Head of Engineering and put me back on track again.

There were failings, however. The first of these was a lack of technical architecture. I had the strategy nailed, but no one was standing back and thinking through how that strategy turns in to code. This didn’t need to be me but it did need to be someone and it didn’t always happen. For instance, our rush to get code down left us with a frontend that was complex and prone to bugs. Fixing this hasty code was a painful false economy I was not going to repeat.

Leaving Bloom & Wild was as difficult as leaving graze, but I had to continue to iterate. I took a position at NearSt, a tiny startup where I was CTO of just me again and got stuck in to all of the above. Hiring, strategy, management, technical architecture and, of course, coding. All of the metrics I had been watching about my own performance were continuing to improve. Now I’ve moved jobs again, joining Paws as Head of Engineering, and I finally feel that I’m doing more than just learning. Satisfying.

Rounding it up

1. Do you actually want to be a tech leader? It’s no shame if you don’t, it’s not for everyone. Dip your toes in to the water by getting more involved with product, mentoring and the business at large.
2. Take charge! People won’t take a punt on you so you need to grow your role. When you find a job make sure the core work is within your current skillset, be really clear on the additional stuff you want to learn and make sure opportunities to do so happen.
3. Be prepared to suck. Wearing all the hats of a startup CTO is tricky. You’ll be shocked by how difficult hiring is, you’ll screw up managing your first 1 or 2 reports and, with the distractions, you’ll be a worse coder. It’s self reflection and iteration that will help you improve!

One final piece of advice is to seek advice. Find a mentor for yourself and ask them for help with each inflection point. I’ve found mentors to be invaluable and I love that I am able to reciprocate now that I am succeeding at my job slightly more than I am screwing it up.

Next time I’ll be writing about the day-to-day aspects of all of the above by answering “Now I’m running tech, what will my day-to-day be?”

I’d love your feedback! Comment here, get me on twitter @adamdunkley or email me at adam at dunk dot ly.