Staying Technically Sharp

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 and 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.

Why It Matters

Here are just a few reasons why it’s still worth it to keep your technical skills active:

• Unblocking Your Team: In many cases, developers will not ask for your help even when they need it. They worry about being perceived as needing help, or are unsure of your own ability to help in a given domain. So, it’s up to you to be forward and offer your help. That said, if you are rusty (or simply believe you are rusty, which is equivalent in this case), your ability to help will be compromised. Remember that you were trusted with leadership due to your own past achievements as an individual contributor. Your technical skills and experience are a valuable asset, and it’s likely there will be lots of problems that could be solved much faster with your input. Do whatever it takes to maintain them.
• Respect: The most powerful authority is earned, not given. Your title may serve to clarify expectations of your role relative to your team, but ultimately when difficulties arise, people follow those they trust. This is especially the case with engineers — even if you’re not discussing a code problem, they are more likely to take your advice / follow your lead if they respect you. The best way to earn and maintain the respect of your team is to demonstrate your technical capacity through solving technical challenges. Your past history can help, but its value erodes quickly over time, so it’s important to keep contributing.
• Scaled Learning: One of the things I sometimes hear from developers is that they worry about a management role limiting their learning. In my experience, I actually find that I can learn more as a manager (albeit a different kind of learning). At one stage, engineers were coming to me with only the most difficult problems they ran into. We would talk about it, design a solution, they’d try it, and come back to me with the results. I would learn from this, but I’d also be learning from 5-8 other engineers at once. So in essence, my learning potential had multiplied significantly when it came to software design & architecture.
• Personal Productivity: With management, we don’t often see the ‘fruits of our labor’ for months or years, if ever. Even when we do see them, good leadership ethics encourages us not to take credit and instead to congratulate our team. This can leave us with precious few opportunities to feel like we’re actually accomplishing anything. Writing (and shipping) code is one of the most direct and satisfying ways to feel productive. We can build something, push it out, and see the result of our work immediately. Yes, it’s okay to do something for yourself — your own motivation levels must be taken care of if you intend to motivate others.

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.

1. Low Priority Features

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.

2. Bug Squashing

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).

3. Internal Tools

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.

4. Pair Programming

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.

5. Newsletters & Blogs

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.

6. Books & Online Courses

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:

• Taking an online course on data science to truly understand the fundamental mechanics of machine learning and models, as I was working with a data scientist we had hired to build out new features
• Reading a book on Elixir, as it is an interesting new language that solves certain types of scale problems unlike any other (e.g. WhatsApp leverages it to handle its incredibly high scale messaging platform)
• Taking an online class about React Native, even though I’ve been fully immersed in native iOS development, because I wanted to understand what the value proposition really is and whether I should consider it for future projects

7. Side Projects

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!