Introduction

I am a software developer. That simple statement is a key part of my self-identity. From the time of my first computer, an Olivetti purchased when I was 8 or 9 on which I learnt programming in Basic, designing and building software has been an important source of joy in my life.

As I turn 40 this year, the Covid pandemic is providing me with plenty of time for self-reflection. It seems likely I’ve now reached the midpoint of my career - I’ve been working for the last 24 years and I’m likely to be doing so for another 25. It feels like the right time to look back on the path that took me to this point and start figuring out the rest of the journey. My hope is that this might help others in the same situation think through their own motivations and go through a similar exercise.

Origin Story

Aside from a brief interlude when I was a teenager during which I wanted to be a writer or a fighter pilot, I’ve always wanted to be a software developer. My plan to win a Nobel literature prize was ditched when I realized I wasn’t a very good writer. Reading as much as I did quickly made me familiar with a wide range of literature, and I didn’t think I would ever be able to do anything similar - I gave that one up quite early! The second goal was a non-starter when it was pointed out that my poor eyesight and lanky frame meant I’d probably not be the first pick for climbing into a cockpit.

So I focused on computing. I disassembled and reassembled my computers. I read RFCs under the covers at night, learning about TCP/IP and packet routing and socket programming. I followed the exploits of the hacker and phreaker communities, religiously reading my 2600 magazine issues. I thought the Hacker Manifesto was profound. I railed against “the system” when Kevin Mitnick was convicted, and thought war dialing was a legitimate hobby. In short, I was a typical teenage geek.

My first paid engagement as a software developer was when I was 16, building a website for a friend’s dad. I then went to university in Montreal, studied Computer Science, co-founded a short-lived digital media company while there, and then came back to my home town. The next 13 years were spent moving from company to company and industry to industry, rarely staying anywhere for very long. I suffered from a bad case of imposter syndrome and did not apply for the roles I could have landed in the large tech firms - I don’t really remember what I thinking at the time but I cycled through a succession of smaller companies, always going from strength to strength in terms of title and compensation, more focused on enjoying myself and surrounding myself with good friends and company rather than where my career was headed.

I’ve worked in telecoms, in gambling, in financial management, in real estate, in advertising, in healthcare. I’ve co-founded two companies, one short-lived and the other more successful but just as ephemeral. I’ve worked in startups alongside one other person, and I’ve worked in enterprises counting 120,000 employees. I’ve delivered telecom systems in Java, academic assignments in C, advertising systems in .NET, web applications in PHP, Microsoft Office monstrosities in VBA, distributed systems in Ruby, infrastructure platforms in Python, and countless programs in Javascript. I became a full-stack developer (at the time it was much easier than it has now become), as comfortable with frontend engineering as I was diving into large-scale distributed systems. I fell in love with testing and quality, focusing on software craftsmanship and programming theory. I’d like to think I became reasonably good technically. And I met some wonderful people along the way - I can’t give names here as I would invariably fail to do justice to everyone I met, but I can only say they all shaped me and helped me grow, both as a developer and as a person.

An important turning point was joining a leading technology company in 2013 after the startup I joined was acquired. I spent 5 years there which were both the most frustrating (in the early years) and the most rewarding of my career so far. I met the best developers I know and some of the best human beings I will likely ever meet. Salesforce is where I became an engineering leader. It was a struggle, with many ups and downs, but the culture of the company and the environment fostered by my immediate leadership meant that I had the support and the space needed to grow. I went back to school and did a MSc in Organizational Behavior in order to become a better engineering leader - I was confident in my abilities when it came to technical matters but I had no education or background to fall back on when managing a large team. Most of the management I had been exposed to previously had been extremely poor, and I wanted to learn how to lead properly rather than just trying to avoid the unhelpful behaviors I’d seen in many of my previous managers. So I took the plunge and dedicated two years of evening work to gaining that knowledge; it was one of the best decisions I’ve ever taken and helped equip me with the skills and knowledge to round me out as an engineering leader.

At the same time, I needed a change. I felt I was drifting too far away from my passion and I went to back being an individual contributor. It lasted less than a year, but the time I spent as a principal engineer building out the infrastructure and developer experience frameworks for my group was incredibly rewarding. I learnt about platform engineering hands-on, diving deep into the internals of tools such as Terraform, Chef, Vault, Ansible, Puppet and others. I explored infrastructure testing, read up on SRE and observability, implemented new deployment patterns and infrastructure operations. The fun didn’t last long as I was asked to lead the Platform Engineering team after 9 months and went back into management, but it was a formative experience.

Unfortunately, all good things come to an end. I was let go, along with the rest of the London-based engineering group, as the company looked to consolidate their R&D teams in the US. We all moved on to other opportunities and I ended up as a senior engineering leader at a global multinational, which is where I currently stand on the cusp of my fortieth birthday.

What Did I Learn?

Working on such a wide variety of systems and products has helped me settle on several principles which I intend to use to to guide my future career.

Principle 1 - The Type of Work I Enjoy

The first is that I want to be engaged in either a) building internal developer platforms and creating developer tooling or b) building a product in a tech company.

It turns out that helping other engineers to do what I myself love, designing and building software, is something I feel passionate about. Platform engineering, infrastructure engineering, site reliability engineering, DevOps, developer experience - all of these these terms are really different ways of delivering a similar outcome: how can engineers accomplish their job easier and faster, focusing on the impactful design, build and manage activities which provide business value instead of spending their time dealing with the interminable friction linked to operations and deployment. Working in many companies today is death by a thousand cuts and sucks the joy out of software engineering - you want everything to “just work” so you can do your job.

The other option I would feel passionate about is building a product for a tech company. I’ve now spent long stretches in companies where technology was seen as a cost center, despite all the leadership rhetoric to the contrary. And it makes sense - if your core business is manufacturing widgets, anything outside the core competency of making and then selling widgets is a cost. IT becomes a second-class citizen which everyone agrees is essential but constantly needs to justify its existence and is not seen as a competitive advantage but something to be outsourced or “managed”. Depending on the circumstances and your business strategy, it can be the sensible approach. It’s just not for me.

I want to work in a tech company focused on building digital products, working alongside designers, user experience researchers, product managers, marketers, all of the various roles and responsibilities which makes working on a product such an exhilarating experience. You’re building something from scratch, and the success or failure of the product depends on you and your team and your colleagues - there is a sense of common purpose and unity which is absent when tech is a support function and only an indirect contributor to the company’s bottom line.

Principle 2 - Business over Technology

The second principle for me is being in a role where I’m close to both the technology and the business. That’s to say, a role where I’m close enough to the cliff-face that I can keep learning new technologies and provide guidance on technical approaches while being close enough to the business that I can align my teams to the overall strategy and ensure they solve impactful problems.

I’ve been in too many roles surrounded by technically-minded folk, brilliant at their craft, who were unable to see the wood for the trees and didn’t spare a thought for why they were solving a problem. Admittedly this was mostly early in my career - I then ended up in roles where largely my peers had become professional managers and were clueless about their space, unable to have a discussion on technical topics without delegating to someone else.

Our core purpose as software engineers in industry is to solve business problems using technology. This means all the technical solutions my teams provide must be framed in terms of business impact. Approaches like continuous integration and DevOps come to mind. They are undoubtedly best practice in the engineering world but non-engineers do not care about that - they want to understand how it impacts the bottom line, and they are right to do so. How many weeks are we cutting off shipping times by introducing these practices? What objective measures of quality can we use such as customer NPS to guide the implementation of these approach? How much unnecessary costs am I trimming and saving the company by stopping multiple teams from reinventing the wheel and moving faster towards their goals? These are all the questions that need to be rigorously answered in order to communicate the value of the work being done.

This focus on quantifying the benefits of software craftsmanship and best practices is something that I feel is essential, and sorely lacking in many of the places I’ve operated in, especially technology companies. Thought leaders like Jez Humble, Nicole Forsgren and Gene Kim are doing a great job of quantifying these advantages and I very strongly recommend any of their works, including the book “Accelerate”. It’s not easy to pull off - but being able to explain to a business stakholder the value of your work is one of the most rewarding things you can do as an engineer.

Principle 3 - Engineering Leadership

Having the time and space to successfully deliver a software product doesn’t happen in a vaccum, despite what many individual contributors - including myself a decade ago - would say. Engineering managers and leaders are the ones creating that space through organizational design, obtaining and justifying budgets and funding, and dealing with organizational politics to shield their teams and ensure they can focus on delivering software.

It’s something I knew I had to become good at in order to support my teams the way I wanted to. So I went back to school. I learnt about employee relations, human psychology and motivation, organizational citizenship behaviors, performance management, corporate culture and strategy. I am now lucky enough to find this part of engineering management enjoyable - pulling together and then growing teams of high-performing engineers is incredibly rewarding. It’s the engineering manager as sports coach model - the job is not to be out on the field but to pull together a team of great people and make sure they have all the support they need to perform at a high level. In the end, it’s the same as building and designing your own software, but different - you don’t have that direct hands-on joy of being a maker but you can have an outsize impact on building much bigger and more valuable products.

Principle 4 - Always Keep Learning

One of the key reasons I love software engineering is that it’s a field that never keeps still. Some areas - I’m looking at you frontend engineering - take this to an extreme and have a dizzying pace of change for little discernible gain, but generally the pace of innovation means you have better tooling and techniques appear every year.

Specialization has become essential - gone are the days where “fullstack engineer” meant you could be an expert up and down the stack. Are you interested in mobile programming? Frontend development? API development? Database tuning and optimization? DevOps? SRE? And these are only the topics I’d like to think I’m decently familiar with! There’s a vast galaxy of specializations in the software engineering world I have never touched.

This leads us to our last principle - always be learning. My main interests at the moment are data engineering and AI, specifically machine learning. Any role providing exposure to these topics would definitely take priority in my mind, but there’s a considerable amount of learning to be done before I can successfully operate in these spaces. There’s a wide variety of courses out there, MOOCs like Coursera or training provided by vendors on their specific tooling such as the GCP Data Engineer certification. My aim is therefore to keep on learning, keep on taking courses and reading as much as I can on the topics, and be ready when the opportunity presents itself to do more work in these areas.

Conclusion

Just writing all of the above has helped me think through the original question I sat down to answer when I opened up my laptop - what’s the next phase of the journey?

I can safely say I’ve never had a plan - or rather, if I did have any semblance of one it was made up day by day, winging every new situation and reacting to events rather than planning them. What better time than now to try something new? I’ve worked in many industries and companies, and worked alongside many wonderful people over the years who have all taught me an incredible amount, both about myself and about my craft. It’s time to use all of this knowledge and chart a course to do what I love, what I’ve loved doing since I was a child - designing and building software.

I’ve drifted away too much from pure technology to easily be able to go back to being an individual contributor as an architect or principal engineer. I have no interest in being a professional manager or senior executive focused on supplier management, contracting strategies and budgeting. It feels, in a way, that I’ve found the sweet spot I’ve been looking for: leading one or more teams of software engineers focused on product development in a tech company or working on developer experience tooling and internal cloud infrastructure platforms.

A director-level role in a large company aligned to my values or a head of engineering role in a smaller business feels like the best fit for my interests and skills at this point - VP and CTO roles are just not for me at this point in my life, even if anyone was to offer me such a role.

Well, that’s it really - thank you for reading. Going through this exercise has been incredibly useful for me, helping me organize and think through my career options going forwards. Maybe it can help do the same for you.