You were once an engineer, and now you’re an engineering leader. Suddenly, you realize that management is not the next step in a development career, it’s actually a totally different path. You’re challenged in completely new ways, and often feel unprepared. You need to learn an entirely new set of skills – empathy building, effective communication, expectation setting, performance tracking, and so on. That’s a lot to learn all at once, which is why management is so challenging when you first get started (check out my posts on effective 1-on-1s and hiring for diversity & inclusion for some helpful tips).
It’s almost as if you’re starting from scratch. Almost. The truth is that your past as an individual contributor helps you tremendously as an engineering leader. It’s crucial to understand why, so that you can do what’s necessary to maintain your technical edge. Ultimately, your technical skills are a critical part of your engineering leadership effectiveness.
Here are just a few reasons why it’s still worth it to keep your technical skills active:
With these motivations in mind, let’s go over some of the best ways to sharpen our technical skills, given the limitations on time and bandwidth as leaders.
If you’re working in a small team, you likely never quite have the bandwidth you need to deliver everything on your roadmap. This is actually a good thing as it forces ruthless prioritization, but there’s no such thing as a perfect roadmap, and so the more bandwidth the better. This is where you come in — if there are small / low priority features that could have high value, you should take the opportunity to just go and get them done. Often, these can be tasks that would almost take as long to explain + write up a task to assign + prioritize with a developer than it would for you to just do it.
The low priority modifier here is key. What you absolutely want to avoid is being a blocker for a critical task. This will only serve to frustrate you, your team, and eventually deteriorate their trust in your ability to deliver. In short: help the marathon runners, but don’t get in the way.
While investigations can often seem hopeless, and production resolution plans can be tedious, I find few things in life are more satisfying than finding answers to challenging mysteries. Often, there are issues that have been plaguing a team or product for a while, but no one wants to invest the extra time to figure it out.
If you’re able to tackle one of them, your team will be incredibly grateful to you, and you’ll save them some bandwidth that they can then use to work on critical features. Again, like with features, do not take on a mission critical production downtime issue — instead, choose long-standing low-impact bugs that only come with a positive if you resolve them, and no real negative impact if you don’t (i.e. in the worst case, things stay the same).
As a leader, you’ll have a much better perspective of how the team is performing from a high level. You’ll be able to see process bottlenecks much faster than anyone inside the process. As such, you’re in the best position to not just recommend and document changes, but to implement and improve tools to automate and optimize the process. This can be a very rewarding exercise, as you’ll feel the productivity boost of putting this change in place, and then see the results in a more high-functioning team (thus, making your job as a leader much easier).
If the changes you’re working on succeed and grow significantly in impact, be wary of the potential for you to become a bottleneck on a critical path. Ultimately, if it becomes important enough to be considered a “high priority” task, then you should now be thinking about allocating your team resources onto it. Remind yourself that the goal here was to provide some value and exercise technically, not to own the component forever.
If your team doesn’t practice pair programming already, doing a few pair sessions with them could be a great way to start. While I’m not an advocate of pair programming 100% of the time, I do believe it can be a valuable way to decrease errors and increase speed for certain tasks. Generally, I find that if it’s a really complex new feature or a sensitive refactor, having two engineers work together for a few hours / days can be a great way to power through it and come out with a higher degree of confidence in the solution.
As a manager, you can ask to simply join in on whatever an engineer is working on for a day. It’s an easy ask, as it doesn’t really burden them too much (it’s up to you to provide value though), and can be a great way to improve your rapport with the engineer. Be warned — the real challenge will likely be your own schedule, which is not designed to allow you a full day of focus. You will have to be a bit ruthless about ensuring you’re not interrupted while pairing. Otherwise, it will just annoy both you and the engineer, and you likely won’t get that much out of it.
Personally, I found this difficult to do successfully at first, but over time it became easier. Eventually, it helped me get a lot closer to my engineers, contribute value, and stay updated with the code.
Sometimes it can seem like there’s no point in subscribing to all those technical blogs and newsletters if we’re not writing code day-to-day. However, I find them to be fantastic ways to stay up to date with the fast-moving pace of web and mobile development. It’s critical that you maintain perspective on the latest tools and frameworks: you need to ensure that new projects consider all options (and that you can have an informed conversation about them with your team), and you need to occasionally re-evaluate whether certain technologies you’re using are no longer being maintained.
Sometimes new technologies will come along that may change the fundamental paradigm of how you approach certain software problems. Even if they don’t necessarily fulfill their lofty visions, it can be valuable to understand them so that you are prepared for the future (whether this means using it in products you’re working on, or doing early preparation for future job opportunities). Some examples of resources I leveraged recently while operating as a CTO:
With all the work on our plates, it’s rare to have free time to engage in a coding side project. Still, if there’s an idea you’d like to build, this can be a really wonderful way to feel productive, build something useful, sharpen your skills, and have fun. Remember not to look at it as something you’re doing in order to launch a successful business - look at it as a means to play, with the other benefits being a bonus.
Side Note: If you understand how hard it is to find time outside your primary work to build side projects, hopefully you can see why it is just as hard for full-time developers to do so. Keep this in mind when interviewing.
As you can see, there are so many different ways you can keep learning technically as a leader. Hopefully it’s also clear how doing so can maximize not just your own potential but that of your team. Ultimately, your ability to find time for these activities really depends on how you are prioritizing work at your company.
What are your favorite techniques? Let me know in the comments!