Reflections on Product Engineering Management

 Reflections on Product Engineering Management

 

 

I am often asked by current or aspiring engineering managers (EM): "What do you look for in an engineering leader?" or "What can I do to become a better engineering leader?" I will never profess to being the model engineering leader. Like many, I have my fair share of growth opportunities. However, I have benefited from a career steeped in rich experiences in both engineering and product management. Those experiences have shaped my perspective on a few of the key ingredients that I believe are required to be a great product engineering leader at any level.  

Regardless of how or for what purpose you arrived at this article, I hope you find it helpful (and where it is not or it opens more questions, you are more than welcome to connect with me). Furthermore, if you agree with or aspire to be a practitioner of the beliefs described here, then feel free to private message me directly or take a look at career opportunities at Medallia. We are always looking for great talent!

Product Leadership  

The notion of product leadership as a key pillar of engineering management is often a befuddling subject. At first glance, the idea conflicts with the premise of product management's mandate. However, the intent is not to nullify or overturn product management. The purpose is instead meant to ensure that an EM meaningfully contributes to the product triad (Product Management, Engineering, and Design). 

If an EM lacks perspective on the goals or future direction of the product she builds, then she is no longer an effective member of the triad, but is instead the operator of a monotonous software factory. It should be the goal of the EM to understand, and even influence, product strategy and design. As a result, you become a productive contributor to the product triad--well beyond the confines of technical decisions and delivery. In addition, it puts you in a position to influence which in itself is motivating to your team. Influence on product direction is the fuel that inspires a team to drive forward and innovate. 

EMs are as much about "how" things get shipped as they are "why" things get built. That is not to say market analysis, product definition, go-to-market strategy, etc. are within the scope of an EM, but an EM should feel impassioned to dig deep to understand these areas as well as challenge a given direction where the supporting data and/or conclusions drawn are ambiguous or worse unsubstantiated. You share responsibility for the product as much as anyone else in the triad. Therefore, it's your job and right to lean into that responsibility and take ownership.

Technical Acumen  

Many engineers and current managers see management as an escape from being technical. This is a false premise. The progression to management may distance you from coding overtime, but a great EM will always remain an engineer at her core. It is completely understandable that as you assume increasing responsibilities your ability to commit code and/or engage in daily technical discussions will inevitably decrease. The time you once had to code will be replaced with budgeting exercises, customer visits, product reviews, strategy sessions, one-on-ones, etc. However, that does not mean you shouldn't maintain or continue your technical education.

 

Depending on where you are in your career and the mix of work you do during the day, this may even require supplementing your working hours with nightly reading or coding to stay up-to-date. Regardless of the method or routine, technical acumen is the foundation to sound decision making as an EM. And, if you are not consistently investing in your  understanding of the primary discipline your organization practices, then you run the risk of losing your ability to help your team navigate each technical decision they face. Remember, you may be a leader first, but you will always be an engineer. 

Adept Project Management  

Why "adept project management" versus "project management skills"? Project management is a craft. Putting it into practice is far more complicated than simply adopting a framework (e.g waterfall, SCRUM, Kanban, Hybrid-SCRUM, etc.). There are many dimensions (and those that follow are prompted by recency, more than anything) to balancing a project plan, which require skill and, subsequently, adept knowledge of the factors that may impact the quality of your execution scheme.

A good EM seeks to understand how to best balance  the "cost of doing business" (i.e. escalations, bugs, infrastructure investments, etc.) with feature development in terms of what percentage of her resources are committed to one concern vs the other. Furthermore, she should feel empowered to maintain her position with regard to resource allocations--pushing back on product management and the broader business where necessary to keep a healthy mixture of product stabilization and enhancement.

Quality is a somewhat obvious, but often underserved area of consideration. A great EM will allocate time and resources to tackle the pyramid of tests to cover her product and ensure its quality. Far too many EMs cut corners, marginalizing investment in quality, in an attempt to reduce time to market. The problem is that this shortcut usually catches up with you and results in a poor customer experience due to subpar quality. This can damage the reputation of the team and create a negative perception of the product in the market. There is little argument that high quality products correlate to greater revenues and happier engineers. Don't skimp!

Delivery is another concern that is often an afterthought. This area comes in many shapes and sizes, spanning from the simple decision of how you ship a feature (e.g. branch management vs. feature flags/toggles) to the more tedious task of lining up resources across functions to support a product launch. Delivery is one of your core responsibilities as an EM and it requires a strong sense of ownership that may even push the boundaries of what you believe to be the scope of your responsibilities. Regardless of perceived role, if the product is not in the hands of the customer you are responsible and should be actively working to unblock anything in the way of shipping. There are few things more important to the successful completion of a project than good old fashioned accountability. 

An Appreciation & Understanding of People  

 If this topic makes you twitch, squirm, or otherwise, then look elsewhere. Management is not likely to be the job for you. The desire to appreciate and a willingness to understand the people on your team and others within your department or broader organization is a personal trait that is vital to your success in this role. The truth of the matter is the day you become a leader is the last day you are allowed to be concerned with yourself. It takes a significant amount of time and energy to bring people to a common understanding and motivate them to drive forward daily, but it's not without reward. If you relish in the victory of others, then your capacity to push onward will be continuous replenished by the accomplishment of your team. 

 

However, if valuing others’ successes is not in your DNA, then you will be perpetually fatigued as a manager, leaving you without the capacity to give back to your team.If you want to get into management, not for power and prestige, but to help others overcome obstacles, then you're on the right track my friend. Keep it up and keep pushing for greatness. And, feel free to reach out to me if you'd like to talk or explore your opportunities.

The Author: Ric Smith 

 

                              

 

About: 

- Tech executive with over 18 years of experience in enterprise software development (engineering and product management) at both privately and publicly held companies.  

- Adept at building and scaling large, high-performing distributed engineering teams that successfully deliver products to both enterprise and mid-market customers