Navigating the evolution from Engineering Manager to Engineering Executive is challenging; the need to broaden organizational influence and interface with more senior business executives usually does not come naturally to the rising engineering manager and it is a high stakes game!

Many of the transition challenges are well understood and documented but hard to implement in the real world as new skills, approaches and confidence are required. In addition, many dimensions we will address here are not often discussed, making it even harder for engineering leaders to be successful as they don’t even know or think about these critical softer skills and fail at developing them. Therefore, they may not even be aware how the lack of these skills and strategies are inhibiting their success and future career progress.

Herein we examine influence skills within engineering and influence skills with stakeholder and partner teams across Product and non-engineering corporate functions. In a subsequent part 2 post, we will cover the evolution from management to expanded focus on leadership activities with the progression to executive leadership levels.

WITHIN ENGINEERING

First line Engineering managers are focused in a small/specific area of the product or platform in their early role(s) as Engineering manager or Senior Engineering manager of approximately 1-3 agile teams. As such, they are not usually working regularly across the broader engineering organization and without prompting and mentoring, they often don’t naturally start to do this.

Why should they expand their efforts across Engineering as they move into the Executive ranks (e.g. Director, VP and above)? Stating the obvious, as a leader in any part of a company is promoted into higher level positions, they are expected to contribute and influence more broadly. Failure to make this transition in impact and broader influence will result in the leader not progressing any further or worse yet, being demoted back to first line manager or individual contributor. Although there is nothing wrong with deciding senior management is not for you – and many people do – it's a disappointing outcome when the leader DOES want to progress on the leadership track.

Following are practical strategies help successfully work more broadly across the Product Engineering organizations as well as potential pitfalls on the journey:

  • Set up regular 1 on 1 meetings with peers in other parts of Engineering. These meetings should be both within the same chain of command (i.e. peers that report to the same next level leader), as well as with peers that report to different senior leaders.

    • Building relationships outside of the leaders’ team helps reduce affective conflict as it develops a personal connection and also helps to bridge the gap of understanding. Think “walk a mile in someone else’s shoes” philosophy. Both of these outcomes also help with better partnership in times of joint challenges like a late project or a production incident
  • Coming to leadership meetings with actual solutions rather than problems. This is obviously one of the first tenants of demonstrating leadership, for managers and non-managers alike. However, there is still a tendency to come to your next level leaders with problems WITHOUT offering practical solution ideas. You will differentiate yourself if you always bring ideas for solutions to problems and a hands-on willingness to lead their implementation.
  • Taking on hard cross-engineering (or beyond) hard problems to solve and really driving them. Common examples include projects like automated testing frameworks, DevOps pipeline approaches/tools/frameworks etc. Being the volunteer to drive these types of initiatives has multiple benefits:

    • The actual improvement in efficiency, quality, etc. based on the initiative being implemented
    • Building empathy/relationships across the org
    • Showing leadership beyond your own silo
    • Expanded visibility within and sometimes beyond engineering (ie. you are seen as a team player and someone who will work for the benefit of the broader organization....).
    • Demonstrating an expanded skillset beyond your own teams’ focus

PARTNERING WITH PRODUCT

As a first line engineering manager, hopefully you are already participating in customer discovery through experimentation and actual interactions with customers (e.g. interviews, prototype feedback etc.). If you practice Agile development, hopefully you are also meeting daily with product managers or owners within the teams you manage.

If you are already working closely with Product in the discovery and feedback processes, - you are on the right path! Unfortunately, it is still common, especially in businesses that were not originally born out of a Product Technology evolution, to suffer the following problems which are more common in the junior Engineering management ranks:

  • Being an order taker – order taker behavior has many negative implications.
    • Engineering can/should understand the customers’ needs deeply. This understanding coupled with an understanding of what is possible/optimal given the architecture and exiting code can offer so much more value in the product design collaboration, resulting in better customer solutions BOTH in terms of user experience and the underlying architectural implementation.
    • Related to being a true partner with Product, it’s critical that Engineering takes part in customer collaboration as part of the product/customer discovery process. This means being part of customer outreach calls, customer advisory groups, helping to design effective experiments as new ideas are tested with customers and more. These processes should include both engineering management and individual contributor engineers. Having Engineering fully immersed in these customer interactions makes the partnership in idea generation and solution design a natural extension of working with customers and experimentation.

  • Not being a good fiduciary of the ongoing health of the product. This outcome is usually a direct result of being an order taker. More junior engineering managers often think their job is to keep Product happy by blindly doing anything that Product requests and conversely by NOT spending time on anything Product does not want to ‘pay for.’
    • Especially for Product Managers who are not engineers, it is common for them to NOT want Engineering to spend an adequate amount of time on keeping the product ‘healthy.’ This can include activities such as: paying down technical debt, fixing production defects, addressing items that come out of incident postmortems, to name a few. This neglect obviously negatively affects customer quality over time and can lead to increased:
      • Production incidents
      • Increased time to market as the code quality decays (e.g. becomes more complex as there isn’t adequate refactoring happening, bugs increase etc.).

      And Product/Business/Customers can and SHOULD point the finger at Engineering as incidents rise, if Engineering has not been doing the maintenance necessary to keep the product healthy.

  • A final and perhaps the most important pillar to working optimally with Product at all levels of management is implementing and evangelizing FULLY shared goals between Engineering and Product. Unfortunately, many companies do NOT have fully shared goals across Product and Engineering which leads to perverse dynamics and outcomes. The most common negative result of not having shared goals for platform health (example goals include change failure rate and production incident related objectives) is that Product does not support Engineering spending any or adequate time on critical activities to keep the product healthy on an ongoing basis as previously outlined, e.g. paying down technical debt, fixing production bugs, addressing emerging security threats etc. When Product and Engineering DO share both application health goals as well as traditional Product goals such as customer adoption and product profit and loss goals, everyone is more supportive of all activities needed for success.

WORKING WITH THE CROSS-FUNCTIONAL EXECUTIVE TEAM

As a junior manager progresses to senior and executive level leadership, they are expected to contribute more broadly in cross functional executive forums. This can be one of the most challenging transitions to make successfully. Failing to make this transition obviously results in either stagnating at the level the leader has reached, or worse yet, once again....being demoted to a more junior leader role.

Some of the common inhibitors to being successful working across the business and contributing meaningfully in executive level forums include:

  • Not adequately understanding important corporate functions at a reasonable level of competency
    • The most critical gaps in knowledge are commonly: Finance, Corporate/Business strategy and Marketing but can also include Legal, HR, etc. The areas that are most important to have a good working knowledge depend on the area of technology leadership but ALL senior engineering leaders must understand finance and corporate strategy at a minimum to contribute as an executive. Understanding these areas is easier if the Tech leader has an MBA or Executive MBA but these gaps can also be filled by doing a reasonable level of self-study and seeking out mentors to work with inside or outside the company (to coach the learning process, answer questions along the learning journey, etc.)

    Once the tech leader has a good working knowledge in these areas generally and specific to the company’s business, they can obviously contribute in executive level discussions that cross business, product and technology.

  • The next common challenge is the new tech executive lacking the confidence to actually speak up in more business focused executive discussions. Common reasons for this include:
    • Not actually having the background in Finance and Strategy to fully understand the topics being discussed (see above)
    • Not feeling like they are experts in the area and therefore anything they have to offer is ‘not useful or good enough’
    • An extension of the above bullet is just plain lacking the confidence to speak up in executive discussions on almost ANY topic. This is especially common when an engineering leader is new in these forums and knows the stakes are higher and/or lacks the relationships with the executive team to feel comfortable enough to offer critical input.
    • A last dimension of this challenge area is consciously or unconsciously being conflict avoidant and therefore not wanting to offer alternate or opposing input. This can of course relate to lack of knowledge (real or perceived) and lack of foundational confidence. However, having cognitive debate, especially in diverse cross-functional forums is the foundation to ongoing innovation in all companies and is essential to not falling into the group think trap

    Realizing that confidence and capabilities in higher level discussion will come more naturally with time, there are still useful strategies to address these challenges and accelerate the ability to contribute:

    • Be “overprepared” - read, re-read, use AI to summarize key points of what will be discussed in advance of a meeting
    • Set incremental goals and hold yourself to them. For example, set a goal to offer one insight and ask one thought provoking question in a strategy discussion.
    • Come up 2-3 questions and 2-3 comments beforehand, so you feel truly ready to contribute
    • Speak EARLY in the discussion. Obviously, other leaders may come with similar feedback, questions, etc. - so if you offer your input earlier in the discussion, it is less likely to be already covered.

    And now for a last word of advice regarding working with the full cross-functional senior leadership team.

    DO NOT SPEAK IN TECH TONGUES!!!

    Technical leaders, especially newer to senior roles are most comfortable in their tech-wheelhouse and may find it hard to:

    • Explain technology concepts in understandable terms for non-techies
    • And/or connect technical topics and opinions to business outcomes.
    • Or worse yet – they CHOOSE to speak in tech terms not readily understood by non-tech executives in order to be perceived as competent or ‘impressive.’ I have actually heard a Business executive once say to me “90% of the time I have no idea what Joe/Jane-schmo is talking about, but I sure am glad they are in charge of Architecture.” This is NOT a good strategy and does not result in good meaningful technology/business discussions because the business doesn’t understand the implications of whatever the heck the tech person is saying.

    Success at the Executive level requires more than just technical excellence and vision. Thinking about these softer skills and being deliberate about how to build them goes a long way to continuing to progress as a leader. We coach and advise leaders to help them build these often times new muscles all the time in the wild. Call us and we can help!