TLDR – Yes but choose the right things to work on
Over the last few years I have been mulling over how much hands on coding I should be doing in various technical leadership roles.
Charity Majors some years back wrote an article I really like titled the Engineer/Manager pendulum.
One of the things Charity proposes is that some of the best managers are never more than 2-3 years from individually contributing and vice versa.
This makes sense to me as:
- I think its an unavoidable truth that in software development over a short time your technical skills will atrophy, you’ll get rusty and whilst you might read some articles you came across on Twitter about some new way of doing things in React that seems overly complex its really not the same as getting your hands dirty with some good old development and breaking some stuff
- Software doesn’t exist in a vacuum and understanding how to get things done and the constraints and challenges a wider organisation faces will change how you approach development (honestly every dev should probably try it at some point you’ll be better dev for it)
Whilst it’s almost impossible to be a very good manager and amazing developer at the same time (i’ll discuss why shortly) I want to discuss why if you are in a software development leadership role of some description I think its important that you remain hands on to an extent and explore some ways you can do this.
Before I get into my er mind dump/rant that i’ve re-written several times I want to note that I have never done a CTO or head of engineering role so can’t comment on what’s required here. I’m writing primarily for the perspective of Team Leads and Dev Managers and whilst I suspect some of what I will talk about still applies for more senior roles it seems likely that coding may not be the best use of a very senior leaders time.
I have worked in various development roles including various levels of Developer, Practice Lead, Team/Technical Lead & Principal consultant for organisations of various sizes. I have led small and large teams and been responsible/supported up to 7 concurrent teams/projects (would not recommend).
In my current role I have a mix of responsibilities but spend probably just under half my time coding with the rest of time made up of a mix of people lead and non-coding project tasks.
Technical Role “Progression”
So most organisations tend to organise development roles around some variation of the following structure:
Junior/Grad -> Developer -> Senior Developer -> Team/Tech Lead -> Dev Manager -> Group lead
At some point you will be promoted/encouraged/pushed/ into some kind of technical leadership role (some with considerable effort have managed to avoid this and seem very happy with this decision which is awesome).
As the roles get more senior you probably (whether you like it or not) have some additional responsibilities or even an entire change in focus.
You likely get paid more for taking on additional responsibilities or responsibilities for others (whether things should be this way is another discussion).
You’ve shifted from being paid to write code to helping others build stuff.
At times this is going to feel like you have made a deal with the devil.
Additional responsibilities in no particular order could include but are not limited to:
- Working out what you are building and which items to prioritise (surprisingly time consuming)
- Working with team members to make sure they understand what you should be building (who’d ideally be engaged in the working out stuff but frequently are not). This is also surprisingly time consuming
- Supporting/advising/mentoring your team
- Actually doing some dev work and building something (although you feel as if you have less and less time to do this due to the various other items..)
- Attending various status & update meetings
- Catch-ups and People Leadership with your team (surprisingly time consuming despite the 20-30 min per person your HR department pretends will be sufficient)
- Quarterly/Annual Reviews
- Interviewing new candidates/contributing to recruitment
- Various other company initiatives
- Working on proposals/contracts
- Architecture discussions
- And there’s probably a heap of other items..
All of this means that you of course have a lot less time to code.
Oh and did I mention the context switching you’ll have to do?
One minute you may be trying to work out why John just cant get on with Sandra and the next you may be interviewing a new front-end developer candidate who’s turned up late.. but wait Functional Dean wants to talk to you about why everything should be written in Haskell (this would be cool but there’s more important stuff and only Dean knows Haskell).
Adding additional responsibilities can result in a lot of a context switching which as we know makes coding really hard and I think its fair to say that Management and Software Development are opposed in many ways.
So er should you be doing coding anyway?
You may be advised by some well-meaning colleagues and perhaps your boss to stop coding altogether so you can spend more time doing what you “should be doing” – uplifting, enabling etc etc.
I’m almost certain they are wrong.
Let me explain – there is a reasonable perspective that if you are in some form of technical leadership role your focus is the team rather than as an individual contributor.
The thinking is that you should be enabling and uplifting your team and that you need to see the big picture rather than be in the detail about why say the project shouldn’t be upgraded to .NET 6 yet.
Additionally, if you are doing all the coding yourself then this can mean you are not giving the opportunity for your team to learn how to resolve problems themselves (I had a manager who did all the interesting work then left us to fix the numerous bugs and it was very annoying).
Long term this will also have long term repercussions for your organisation if you were to leave and the team cannot work alone.
However this ignores some big items:
Tech changes rapidly
You no longer understand how the solution works which makes it hard to assist the team
Over time you wont speak the same language as the team
Like most things in life however there is a balance to be had here and as a warning it is not easy to find.
Why you should remain coding
Whilst your hands on coding time will (and should) reduce in a leadership role I do think its important you remain coding/hands on.
- It will be less than when you were an individual contributor
- It will feel uncomfortable as you’ll likely no longer be the most technical person and up to date with the latest library features/changes
- You’ll need to ask for help and advice from the team at times – they are working with this stuff every day and you will benefit from their input
I believe the advantages of remaining hands on outweigh the small-time commitment this can take:
- You’ll understand better how the systems you and your teams are responsible for actually work – reading documentation/your orgs confluence pages can help but really isn’t the same as getting your hands dirty and getting first hand experience of a deployment pipeline that fails at random points
- You will understand the issues your team are dealing with. I loved that a previous manager pulled down the solution code and worked through the setup himself. At the time it was challenging to get the solution going. This manager now had first hand experience of this pane and could advocate why this needed to be fixed up asap
- You will know better how to empower your teams and help resolve issues when they occur
- Software and practices move quickly and your skills and knowledge will certainly atrophy over time and this is unescapable
- At times management/leadership can feel very lonely and empty. You’ll get a lot of satisfaction combining both enabling others and making small contributions/refinements (we’ll discuss this in a minute)
I’ve got too much stuff to do already how do I fit some dev in?
But I hear you ask how do you do this when you have thousand things to do?
First of all no one is going to say to you “hey Alex make sure you are making time to do some coding ” (especially if your name is not Alex) so you’ll have to do it yourself.
If you are worried about using company time then think how much time is wasted by various other activities that you er “have to do”. Yep that’s right your company can spare a few hours and if they wont then find another company (seriously).
Hopefully however you can work this out so let’s talk about what you should be working on.
What should I work on?
Remember that now you are in a lead role your focus is your team and organisation.
You do need to be interruptible and flexible at times if your team need your guidance or help which means that there are some items that are very much more suitable for you to work on when you are in a leadership role.
As a general rule you don’t want to be taking on any critical, core or very large items as:
- You’ll get in the way of your team(s)
- It will stress you out as you’ll know you need to complete these other items but have a heap of other work as well and John and Sandra are still arguing over something that really doesn’t seem that big a deal and Dean as we speak is converting everything to Haskell when there’s more important stuff he should be doing..
- You take away an opportunity for a team member to learn
Some suggestions on how to do this
- Find some stuff to work on – good candidates for items to work on include:
- Smaller tasks such as bug fixes or small features
- Documentation updates (you know this hasn’t been done in a while)
- Build, deployment and process improvements
- Security and performance improvements
- Book regular time to think, read-up and do some dev and train your organisation/teams that you are not available during this time. You will need blocks of at least 30 minutes and you really want at least 2-4 hours a week and more depending on your role
- Select an area or initiative that you are passionate about and see what you can do to drive it within your organisation. I’m enjoying learning about security the last few years so have focussed on this but maybe for you its Devops, Observability or database tuning – what can you do around this for your organisation?
- Depending on your circumstances you might enjoy small fun projects/open source in your own time. This isn’t for everyone and family responsibilities etc can leave little time or energy for this. Something fun however doesn’t feel like work and can be relaxing
- Consider being hands on for a longer stint to get your skills up to date again (a smaller pendulum?)
In conclusion whilst it can be hard to find the time to code in technical leadership roles I propose the benefits will outweigh a small time commitment.
I really like Charity Majors article the engineer-manager pendulum – check it out at
Managing Humans is a great book that has several discussions around this area: