The coding Engineering Manager
As a software engineering manager leading a team of around dozen ICs, the conventional advice given to you is to lay off the IDE. The more you code, the less time you have, to get your management on. But some managers are the epitome of keyboard fiends. We crave an analytical challenge. Regardless of what we achieve as engineering managers, we still feel exhilarated when a user is hooked on software that we have written. So, what do you do when you were a fiend/ before becoming a teen/ and now your coding passion is melting like ice cream? Below are some of the tactics I have learnt that engineering managers with strong technical itch tend to apply.
We also possess the skill of scavenging accomplishment out of mundanity -Anonymous
Your career has evolved, your ever-changing role is not what it was yesterday, you need to look at the bigger picture and reconfigure your success criteria. At the end of the day, you always believe your identity to be a technical engineer. If the core of your excitement as a technical engineer is to write useful software and contribute to society, then you should derive satisfaction from your team’s shipment of great products. You are responsible for the success of engineers in your team, this success should translate into your accomplishments. This is not really reconciliation; this is actually you seeing the light. Look outside of the window of your upper floored-high rising-metaphoric empire state building. Look below, that is what you and your team in collaboration with your organization has built. Take that in, let it sink in.
Being aware of all the technical challenges at an analytical level that your directs face is a super power. It requires some serious engineering chops and comes with some caveats. Most of the times your directs will be working on different technologies, hence having a superior technical breadth of knowledge is mandatory. This breadth of knowledge is more important than depth of knowledge which is required to quench your engineering thirst. If you wish to embrace this approach, you must be proficient in the following. As a disclaimer, please be aware of commitment, trade-offs, and chops required for this approach.
- Code reviews — Code reviews will give you deeper understanding of your ICs work and challenges. Your understanding of the challenge and code is based on the quality of your code review. Your goal should be to understand the codebase and be able to spot or smell flaws and always provide suggestions and examples.
- Architecture reviews — Preferably, your senior engineer or architect will be the head honcho in these reviews. You don’t want to overstep your manager boundary and push your tyrannical views. Your goal here should be to completely understand the architecture and identify the pros and cons of architectural decisions. You should also be able to provide proposals.
- Communication — Part of being a manager is being a great communicator. But the communication in this section refers to the technical dialogue between you and your directs. This communication can be on or off the books. I usually utilize any opportunity to talk to my directs. Whether it is during a coffee break or just a hallway banter, I try to indulge in conversation regarding the current problem that the individual is tackling. I am careful enough to not always talk about work, at these moments I make sure I divide my conversations between work and off-work topic. Be careful to not let your communication hinder the IC’s workflow in any way.
I love prototyping new products and features. I have designated weekends to do my prototyping work. Sometimes I prototype without talking to any product manager or business exec. But mostly, I would pitch an idea to a business executive or a product manager. If they think it is remotely useful, I take the time to write up a quick prototype and do a quick demo. This scratches my coding itch, forces me to learn trending technologies/methodologies, and potentially could provide great value to the business. In past I had great success with my prototypes, some of them went on to become features used by millions of users. I once pitched an idea to Steve Ballmer on a basketball court and prototyped it. I encourage and enable all my directs to elevator pitch.
During a sprint, you can carve your schedule in a way where you can contribute to an engineer’s workload. By doing this, you can bring in more deliverable items into the sprint. Your contribution percentage would vary depending on the level of engineer. This approach also works well when helping out a junior engineer into a paced ramp-up. But don’t make this a habit. You should not be disrupting an engineer’s sprint routine and one’s autonomy.
There are other things one can do to either peacefully part ways with coding or incorporate coding in their routine, but personally I have found a great balance between leading and coding and I will continue to perfect it.