Make Time for Technical Contributions - Some Thoughts on Engineering Management

I get it, it can be tough as an engineering manager to make time for technical contributions. There are a variety of reasons for my assertion that it is an important part of management. While I certainly understand that the role is frequently defined (and rated/rewarded) based on the management contributions, I believe that your management will be more effective if you spend a portion of your time on development. Let me explain why.

Direct contributions provide a connection with the experience of the developers in your team or organization. It provides a sense of the pain points, what works well, and how the integrated system works. It helps when allocating resources, especially for projects that generally don’t grab attention like better infrastructure or debug tools. It serves as a bonding experience with your team as well, they will appreciate it if you are trying to understand their difficulties and challenges. Think of it as a version of ‘leaders eat last’ for engineers.

Hands-on development provides an understanding of the architecture at a tactile, experiential level. Seeing things (at least some of them) first-hand helps find what’s hard and what’s easy. Are you fighting the architecture at every turn? Are there aspects that are fragile, difficult to test, or hard to see where they fit in? These experiences can help inform risk levels, expected amount of development time, and illustrate the need for key initiatives such as consolidating technical debt. 

Experience with the system enables an ability to dive into details when confronted with new challenges. ‘Why is this feature so hard?’ - Poke around and experiment a little. “What’s going on with problem xxx?” - Investigate and give the question proper context. This unique skill allows you to understand key aspects of the highly important, critical issues. It’s not micro-management or trying to solve problems directly, it’s about educating yourself about the system or problems so that you can ask better questions and answer the concerns of higher management.

Allocating time for techincal contributions helps with your sanity and overall job satisfaction. A day of continual meetings can be exceptionally draining. Switching up tasks and varying your workload can reinvigorate and improve overall productivity. I know many managers that spend time outside of work on side projects, coding, or other related activities. I got into engineering because I actually enjoy it. This puts development in the same category as a good night’s sleep and exercise - you are much more effective if you make time to keep things in balance.

So how do you do it? It may be easier than you think - at least after the learning curve. Even the initial ramp up is informative about the challenges new team members will face. In my earlier post, I recommended creating 1.5-3 hours blocks for ‘Maker Time’. Look at your calendar at the beginning of the week and block some large enough time spans. Allocate some of these blockes to development tasks. Find tasks that are outside of the critical path but make your job easier or improve life for your team. Resist the temptation to sign up for additional work to increase the capacity, the team leadership and management responsibilities still have to be the top priority. 

Does this philosophy break down at some point? Probably. It’s not nearly as early as most people expect. I’ve used it effectively with organizations as large as 30-35. Even for large organizations, senior leaders can spend time working with the system and exploring its failures by attempting to debug some of them. This can provide valuable insights into your team, the overall quality of the implementation and your development process.

In my career I’ve held a variety of roles, from leading software organizations to coding and design as an individual contributor. While that is true of many managers, I have swapped between them more often than most. There are a variety of reasons for the transitions but at the core they are driven by staying grounded in the technology and keeping my hands ‘dirty’.

Good insights and your arguments align very well with my engineering management experience. Ultimately I am happiest when I am doing a little bit of technical work in the midst of all that management churn.

Makes sense. I’d rather have a manager who understands what I’m working on and dealing with at technical level. Over the years I have found that the ones who “got their hands dirty” have been the most effective and most liked by their directs.

I need to re-read this, John. I totally resonate with your points, and was discussing related topics with a colleague today. Your points are spot-on, but can be really difficult to implement well. Performance review time raises some especially thorny problems, not just for the managers, but also for their myriad stakeholders who compete for their time. When perf dramatically increases the workload for about one-quarter to one-third of the year (across two cycles), that's a lot of time to have the program's bandwidth limited by manager availability. Love reading your thoughts!

To view or add a comment, sign in

More articles by John Pratt

  • The Future Work and Robotics Organizations

    Introduction The last year has been an unprecedented experiment in distributed teams and remote work. The initial…

    6 Comments
  • Meetings and how to use them

    Meetings can be very powerful. They can help the team make decisions with input for a number of perspectives.

    2 Comments

Others also viewed

Explore content categories