From Engineer to Manager: keeping your technical skills

I became an Engineering Manager over two years ago. One of my main challenges during this time has been to find the balance between my leadership duties towards my team and my desire to keep coding. I figured I must not be the only one struggling with this, so I thought I’d give my two cents. Why engineering managers should be technically competent In my opinion, (and the ones who escape the most of the time). As a technically competent manager you will: hands-on, technically competent managers are the best leaders for engineering teams Dilbert Principle Be able to understand the associated with the tasks your team has to perform, making it much easier to communicate with the team members, and simplifying that message for non-technical stakeholders like Product or Marketing. hidden complexity your team of engineers more effectively and be able to in the technical domain. Mentor lead by example Be aware of new tools and frameworks your team might be using and be able to give . better technical direction Be more . That is not to say that non-technical managers can’t be respected or trusted. likely to be trusted and respected by their team of engineers Keep your to go back the Individual Contributor track in the future. options open Ok, we agree it is a really good idea to keep and improve your engineering skills. But that doesn’t come without challenges. Coder vs Mentor The first challenge you will likely face is the conflict between your and the : Your engineer self will want to solve all the interesting technical challenges your team faces. In the other hand, your mentor self should want to give the problems to team members who can use them to improve their skills and become better developers. engineer self mentor self This problem can be acute in teams with many junior members and a lack of senior engineers to mentor them. In that case, the engineering manager will have to put even more emphasis on the mentorship aspect of her role. Make your team successful Your team and your people come first, before any coding. It’s a necessary condition: your team is successful you can dedicate some time to coding. If and Only If As a manager you are not building a product, you are building a team that knows how to build products. Thus, making your team succesful should be your primary goal and metric to evaluate yourself against. If you lead a successful team of happy engineers, the team’s success will speak by itself and you will need to spend less time in meetings trying to explain or your achievements to your peers and superiors. sell A self-sufficient team of empowered individuals where you are not the decision bottleneck will give you some additional bandwidth to spend doing something else. Your words have more weight Another challenge for me was being too vocal or expressing my opinions too strongly when the team was discussing how to tackle technical problems. I was unaware of this problem until a team member let me know during an open feedback session with the whole team. She said something like “ ” You are too opinionated during our technical discussions… you should give more room to others While some managers are indeed very vocal and use , I learned the hard way that it will prevent others from expressing any different/dissenting opinions they might have and you will probably end up with a worse solution to your problem. power speech My advice? Always speak last and ask questions rather than give answers I can’t stress enough how important this is. Hands-on managers have to be fully aware that every word they say or write is potentially silencing her team member’s ideas or proposals in some way. James Everingham goes even further and suggests that just by observing, a manager is already changing the outcome of a project in his : Quantum Mechanics analogy The observer effect is real in the workplace, and you can affect the outcome of any project as a manager simply by inserting yourself. Often, a manager will take their team into a room and say, “Here’s what we need to do,” or “Here’s what I’ve been thinking,” or “Here’s one way we can think about this…” as they start sketching on a whiteboard. They’re trying to add value. We always want to add value. But if you’re in any position of authority and you do this, you’ve just limited the number of outcomes and your path to success pretty dramatically. Maker vs Manager A more logistical challenge I faced was trying to blend the . In Paul Graham’s words (emphasis added): Maker’s schedule with the Manager’s Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started. In short, (which is a kind of ). One could say the characteristics of the manager’s and maker’s schedule are antagonistic: an engineer needs as few distractions as possible while a manager who doesn’t attend meetings or doesn’t interact with other teams can get her reputation penalized for “not being visible enough” in the organization. the fragmented, reactive and meeting-driven schedule of managers simply doesn’t bode well with the concentration coding requires Deep Work Don’t mix the two schedules http://dilbert.com/strip/2012-05-30 Don’t even try. It’s a recipe for feeling frustrated and unproductive. Like water and oil, the best is to keep them in their natural state: separated and independent from each other. I try to separate my schedules with natural interruptions like lunchtime break. Grouping all my meetings back-to-back in the morning, while exhausting mentally, leaves my afternoon free to wear my Maker hat and concentrate in tough programming problems. I try doing so at least twice a week. I found that having an ample lunchtime break, having a walk outside the office if at all possible, is perfect for my mind to disconnect and reset from meetings and come back refreshed to code productively. While wearing your Maker hat you should avoid all possible distractions. To begin with, turn off email. Then, close all the distracting tabs from your browser — — or open a new browser window just to consult the documentation you need. Lastly, I would also turn HipChat/Slack off. Of course you should always leave some communication channel open for urgent issues, for the right people (your team) to reach you if necessary. ehem, Facebook, ehem Being able to be productive and focused depends heavily on the context you are physically and mentally in. By tweaking and adjusting your environment (working from a different desk/place, listening to certain type of music, whatever works for you), you can go a long way to triggering the right mental context to be as productive as you can. You can get many more tricks on how to deal with vs work in . shallow deep Cal Newport’s Deep Work Being the code bottleneck Given your busy schedule you will probably find it difficult to finish any coding tasks in a timely manner, which means you will probably be blocking some feature from getting merged and deployed to Production. Even worse, if something goes wrong, you might not be able to tend to urgent technical issues like live site issues or pipeline breaks. As the team leader you should be busy shielding your team from distracting meetings and conversations while they can focus on coding. Again, your job is not to code but to ensure that your team can code effectively, and help your team socialize their achievements. Your code doesn’t have to ship A good friend gave me this advice when we were talking about hands-on, technical managers: You can’t be your team’s bottleneck. You need to coach and mentor your team members to be able to tackle all technical challenges without your help. You should never be needed to write production code . A great use of your coding time is the non-feature dirty work. Make the build faster, extract some shared behavior into a nice library. Look for things that will make things more productive or more fun for the team. You can also keep your technical skills by focusing on coding Proofs Of Concepts, explore new technologies for your team to use, or work on side projects within the company or on your own. I took that advice to heart and I couldn’t be happier with the results. Not only do I feel less stressed knowing that I am not the technical bottleneck of the team, but my team members have had many more opportunities to face challenges by themselves, learn and become better developers in the process. In order to pass down my technical knowledge I pair code on interesting problems and I also run “Clean Code Sessions” where the whole team solves technical problems together through mob programming or just share some technical knowledge and opinions. Nowadays the bulk of my coding is on side projects, either in Expedia (like the ) or my own side projects like or my . Expedia Alexa Skill markpress useless-but-cool-looking Rolex GMT Chrome Start tab extension Conclusion Being a manager who can code is like having . It requires hard work, and lots of dedication. It’s very easy to feel overwhelmed or if you don’t manage well the fine balance between leading and growing your team and honing your tech chops. two jobs burned out I’d say you need to love both leadership and coding to pull it off, as you will need to spend lots of your improving your manager self and/or your maker self, but hey, it’s worth it! And after all, . free time this is life Further reads — Article by Stackoverflow’s Developer turned manager David Haney — Article by Facebook’s Average vs Great manager Julie Zhuo — Article by Paul Graham Maker’s schedule, Manager’s schedule — Book by Cal Newport Deep Work — Book by General Stanley McChrystal Team of Teams: New Rules of Engagement for a Complex World — Article by Head of Engineering at . The Principles of Quantum Team Management James Everingham , Instagram If you enjoyed this article you may also like my take on high performing teams and their culture .