Becoming an individual contributor (again!)
tldr
Today, I’m firing the starting gun on my career goal to transition away from Engineering leadership back to being a hands-on software engineering Individual Contributor (IC). This post lays out the high level background, motivations and approach I’m intending take to achieve that goal.
You can follow this journey by …
- Following me on Twitter
- Following the GitHub organisation
- Following me on LinkedIn
- Subscribe to this blog
Whilst this is the inaugural post, it’s important to note this is likely to be one of the least technical posts I ever publish here!
How it started
🌍 Birth of the Commercial Internet
My career as a professional software developer started in 1995 working on web based applications, I remained fully hands-on for the next 10 years until 2005.
It was an exciting time. Internet usage was minimal (1.9% of the UK population) while ideas, opportunities and dreams were endless for the “new” global technology infrastructure. I struggle to fully articulate the experience of being a developer during this period, particularly to Gen Z who don’t (at least in western countries) remember a world without near constant internet connectivity and access to digital services that are integral to their lives today.
The planet was buzzing, a generational technology revolution was taking place in real time. In a 1999 interview with the BBC David Bowie eloquently described the internet as an “alien life form” that had landed on earth 👽!
I experienced and participated in (a very small way) to the birth of the commercial internet, which was like a digital gold rush cumulating in the dotcom bubble and over a decade later the emergence dominance of the FAANG. That digital gold rush promised to remove friction from many day activities, and has done a pretty good job in achieving that so far!
What a time to be alive! What a time to be a developer!
📚 Real physical books
I’m proud to be a self taught developer with no degree in Computer Science, indeed I have no STEM qualifications at all.
I used real books bought from real book shops as my primary learning tool - no YouTube videos, no Mooc, no open source which was coined in 1998). These books were very expensive, and yet littered with incorrect code snippets as the technology was moving far faster than the book authoring process - ironically a perfect use case of the value of the internet!
At the time this was infuriating, in retrospect this was an (unintentionally) an excellent way to learn. Curiosity, research and tricky debugging were daily necessities that honed my software development skills. I was totally obsessed and committed to the pursuit of mastering software engineering, in retrospect to almost unhealthy levels. I would study and practice late into the night, 3am not being uncommon, while working a relatively mundane full time day job 💤.
🐛 Caught by the bug
I was intoxicated by the constant learning, problem solving and being able to build solutions that solved real world challenges.
I caught (pun intended) the bug of software engineering and it has subsequently shaped my life, professional and personal, and I loved being a software developer.
I feel immensely grateful to have had a job I loved, travelled the world while being paid to do it 🙏. Yet, this post isn’t about the halcyon past, it’s about about my plans for the future.
How it’s going
🎢 Bumpy start
The last meaningful software product I developed was in early 2009, a common application framework using the Microsoft .NET written in C#. The libraries where consumed by other dev teams, and formed the foundation of many mortgage related software solutions at Barclays.
From 2005 onwards I increasingly moved into engineering management & leadership. Being candid, in the beginning, it was an archetypal example of an unplanned and underprepared for transition. It transpired for the worst of all reasons… I was a decent senior developer, and somehow that was supposed to mean I would be a good manager 😂.
☑️ It’s a hard transition
There was not the appreciation, support or resources of today’s industry on just how hard and difficult this transition can be, but now this is recognised. If you are considering taking this career path, here is some recommended reading…
- The Manager`s Path: A Guide for Tech Leaders Navigating Growth and Change
- The Making of a Manager: What to Do When Everyone Looks to You
- Managing Humans: Biting and Humorous Tales of a Software Engineering Manager
👥 Joy of building engineering teams
After the bumpy start, I came to really enjoy hiring, building, coaching and leading large engineering teams. It’s now (almost) as pleasurable and rewarding as building software itself. Managing engineering organisations of c.200 people clearly has an entirely different set of challenges, successes and rewards.
Specifically, it’s been such a privilege to work with so many talented, smart and committed software engineers from around the world - many who have remained friends long after we’ve finished working together.
I continue to provide large scale engineering leadership today, you can find out more on about my career history on LinkedIn. I remain very focused on and motivated by creating the best possible culture where we delivery quality and individuals thrive.
Yet, throughout the leadership and management phase of my career the joy of and urge to return to hands-on software engineering has remained… running on an infinite background worker thread.
Inspiration
I have missed developing being a core part of my day job since the day it stopped being so. For years I have incubated the idea of returning to be an Individual Contributor (IC) role.
I read with interest in July 2021 that Mitchell Hashimoto, one of the co-founders of Hashicorp, who’s surname is the source of the “Hash” in “Hashicorp” was to move from an exec role back to a technical IC role.
- From individual contributor to manager, and back again
- Individual contributor vs. tech lead - which one’s you?
- Making the Move From Manager to Individual Contributor
I am not Mitchell, his achievements are significantly greater than mine, yet I found his story a reference point and inspiration - if he could do it, why couldn’t I?
Back to reality
Core challenge
The core challenge is that unlike Mitchell, as his GitHub contribution map shows, he remained a very prolific contributor whereas I have remained a sporadic dabbler.
🐦 Technical capability of managers
Whether it’s necessary to be technical to manage technical teams is a disputed topic. Recently this particular flame war was reignited on twitter…
I strongly believe that all managers in a technical area must be technically excellent. Managers in software must write great software or it’s like being a cavalry captain who can’t ride a horse!
I personally believe engineering leaders are more effective if they have meaningful understanding of engineering practices, patterns and technologies… and the only way to get that is by getting hands-on. Additionally, I also believe historical technical experience should not be relied on given the rate of innovation, scientific understanding of software delivery, evolution of technical practices and improvement in dev tools.
Therefore, I believe engineering managers & leaders should constantly be upgrading their software engineering knowledge. This does not mean maintain the ability to deliver a full production solution, as I rule of thumb this means use current tooling to develop a medium to high complexity Proof of Concept (PoC).
💻 Keeping technical (enough)
Luckily I have followed this principle myself and haven’t entirely become detached 😜…
- I sporadically get hands-on with some exploratory projects, these repos are hosted on my GitHub organisation
- This year I contributed a couple of merged & released PRs to the official GitHub CLI, here and here
- I’ve taken various technical certifications over the last few years, mainly Google Cloud Platform and Hashicorp certifications
- If time allows, I do also make minor contributions to internal projects at Capco. That is increasingly rare given my other commitments
Coding vs Engineering
Whilst I’m not starting from ground zero, I’m also not naive. I certainly do not subscribe to the view that software engineering is “easy” to learn, let alone master.
The biggest misconception I come across is that “coding” == “software engineering”. It is not, I’d recommend reading Software Engineering at Google: Lessons Learned from Programming Over Time which clearly distinguishes between the two. I intend to be software engineering IC, at a senior and high standard. That is why on the surface my estimate of how long this transition will take may seem excessive.
⏳ Time can’t be bought
I’m realistic it’s going to take a significant investment in time to reach the level I want/need to be to become an IC again. Software engineering needs head space, practice and learning all which require copious amounts of time. I suspect Warren is far busier than me 😉 but certainly time will be the biggest constraint to achieve my goal.
It’s the only thing you can’t buy. I mean, I can buy anything I want basically but I can’t buy time.
Goal, approach & timing
🥅 Goal
In the next 3 to 4 years develop and demonstrate the skills & experience needed to return to being a professional senior hands-on software engineering individual contributor.
📝 Approach
The overall approach is…
- Build up knowledge and experience of a range of technologies across the stack, see my GitHub profile for details
- Where I’ve previous experience, deepen that knowledge rather than start from scratch e.g. I know Go & Python, I’m not going to learn Rust (yet at least!)
- Leverage the a wide set of rich training resources to acquire expert knowledge and then reinforce this learning by working on various projects
- Participate in a broad base of activities that not only refresh my technical skills but also distributed team collaboration (Open Source, Hackathons etc)
🕐 Timing
When asked “Why attempt to climb Everest”…
Because it’s there.
There are some specific reasons why now feels the right time to prepare for this transition…
- 💪 Career motivation comes from new challenges, it’s a tough challenge to career change
- 📍 Offers more remote / location flexibility which is increasingly very appealing to me
- 👩 Greater location flexibility means I can support my wife’s career trajectory better
- ❤️ It’s probably getting boring now… I know that it is something that I love
And finally
The canny reader might have noticed the blog and/or some links in this post using the ‘delineate’ domain, some years back I acquired a set of top level domains (.io, .dev, .app, .run, .pub).
‘portray or describe (something) precisely.’
Under this domain a number of the digital services (GitHub, Cloudflare, [GCP](“https://“) etc) have been setup that I’ll be using these for my learning endeavour.
A simple landing page has been also been created at https://www.delineate.io using Vercel. Key benefits of this approach is the opportunity to become familiar and skilled in enterprise features of these services and potentially have the ability to collaborate with others using these tools. For example, this is why my GitHub source code repos are hosted at delineateio rather than simply at jf-delineate so I can leverage GitHub organisation features.
So expect to see delineate.io in virtually all subsequent posts as I embark to this transition. Thanks for reading, all feedback welcome!