How to be an Effective Engineering Manager by Investing in the Right Tools

K - Jul 5 '21 - - Dev Community

After working with a diverse set of software engineering teams, we at Moesif have gained a unique perspective on what traits enable engineers to take on leadership positions and become outstanding managers vs others who have a harder time rising through the ranks. Gaining an advanced title and responsibility is not an easy task.

After all, there are far more software engineers than executives at a company regardless of size. So how do you stand out to land that awesome VP or C-suite role? To understand what makes a great leader, it’s best to understand from the perspective of the person driving the promotion.

The Mindset of Leadership

Engineering naturally applies logical reasoning to a set of problems or challenges. Whether it’s to build and scale a new data platform, or how to gain a leadership title. Engineers love to “grade” a system on metrics such as performance or defect rate. This can even manifest into orchestrated mass testing activities such as the familiar Hackathon.

Yet, the CEO or CTO probably doesn’t care how fast you can code an Uber clone or hook up some API. Even the usual textbook items of soft skills matter less. While it’s handy to have great communication and speaking skills, there are many executives who dread going up on a stage to present some eye candy.

So what is it? Becoming a great engineering leader is not really about soft skills or a grade, rather it’s about a mindset of finding ways to put capital to work and create business ROI. Every company (unless you’re nonprofit) is in the business to make money. This means the work that you create has to create positive ROI for this business. If you create negative ROI for the business such as not delivering your work, then that is a quick path to being let go.

Yet, businesses hire and invest into junior engineers all time through training, career mentorship, and other activities. This is because even though the short term ROI of that hire may be negative, the long term ROI is expected to exceed any initial investment cost. Good engineers already understand this concept very well and will strive to create more value which can appear as “proving oneself”.

Let’s say your manager tasks you with building an internal API analytics tool so you can understand customer usage. A naive way would be to claim you can build this in a day and spend all weekend coding an ad hoc solution that works but will be costly to scale and maintain. Sure, you coded it quickly, but does that accomplish the business goal in this most efficient way? This way of thinking can turn oneself into more of a “code monkey” vs. an engineering leader.

In fact when taken to the extreme, friendly competition and “leveling up” can turn unfriendly and create office politics.

Leverage Capital Efficiently

Outstanding leaders repeatable demonstrate their ability to leverage capital efficiently to get work done.

Capital

Capital in this context can be human capital, technical capital, financial capital, or other resources available. A business by definition is the allocation and use of capital to create more capital usually in the form of increasing cash reserves, headcount, or patent portfolio.

Leverage

Leverage enables business leaders to utilize all available capital at the business to create the largest outcome that’s beyond what one could do without any resources. A single person can’t build a search engine overnight, but great leaders can lead a 100 person engineering org to accomplish a lot.

As example, an engineering leader may leverage human capital (i.e. engineers) to create technical capital (a sellable product or service). Then, business leaders may leverage that product to create financial capital (i.e. revenue). At each stage, more value is created. In this case, the financial capital (revenue) must be higher than the initial investment (engineering salary). The larger it is, the better the outcome for your boss.

Managers who can prove that they repeatedly create positive returns on investment are allocated more capital to leverage which can be seen as growing your responsibility and ability to magnify your business outcomes.

Efficiency

A good leader not only leverages capital to create positive business incomes, they do so efficiently to have the largest investment multipliers. Efficiency is poorly understood by inexperienced managers and can cause situations where employees end up doing “busy work” that doesn’t maximize business outcomes.

The cost of consuming business capital such as engineering time is larger than the intrinsic value. There is an opportunity cost which a manager needs to consider which means you should use capital efficiently.

If you’re able to generate positive returns but they are single digit (i.e. the returns are small relative to the capital spent), then your use of capital is inefficient and could have been spent in alternative ways.

Why Experienced Managers Purchase Software

Engineering and business leaders commonly invest in enterprise software like API analytics and monitoring to make the best decisions that maximize returns. This is because such tools can make your employees more efficient which enables you to have greater leverage.

Yet one’s approach to procuring software and tools varies greatly based his or her leadership experience which causes debates on build vs buy. Deciding whether to commit engineering resources to build an internal solution or commit financial resources to purchase a turnkey a solution from a third party vendor can be daunting.

Inexperienced managers commonly resists purchasing software and would campaign to build an internal solution whereas experienced leaders usually lean towards purchasing from external vendors.

There are usually three motivations why inexperienced managers want to build:

  1. The inexperienced manager believes building something will raise his/her “profile” at the company.
  2. The inexperienced manager has never navigated procurement and financial controllers so don’t know where to start.
  3. The inexperienced manager has a belief that purchasing is corporate waste.

Yet, experienced managers almost always prefer purchasing from a third party sense they have a better understanding of the true cost and risk to build internally vs the leverage that can be gained by choosing to go with a third party. When you purchase enterprise software, you’re also leveraging the vendor’s investment into years of research and development to build a far superior product.

A typical SaaS vendor may have 100’s of millions of dollars in annual revenue and years of expertise which they can leverage to further develop their product. It would be a poor business decision to commit 100’s of millions of dollars in human capital to build an equivalent level of functionality and performance that a third party vendor has. This means an internal build is almost always inferior to the third party solution or is buggy.

Understanding Short Term and Long Term Business Cost

Let’s say you did make a decision to build, then you can impact the business negatively both in the short term and the long term which can cause your boss to question your decision making.

In the short term, developing in house can cost a business a lot of money due to engineering salary in addition to multiple opportunity cost including:

  • You can’t utilize the tool until it’s completed while your competitors gain market share.
  • Your engineers are busy building and maintaining this tool instead of revenue-generating features.
  • Increased company risk that the tool doesn’t work or is buggy.

In the long term, the maintenance costs and technical debt increases as employees move to other projects or leave the company. According to SAP, 78% of homegrown enterprise apps are abandoned after first use. Feature requests and bug fixes remain unresolved after the initial delivery due to lack of engineering resources.

Leveraging a Vendor’s Leverage

By purchasing software, you’re also able to leverage the vendor’s available leverage and resources. Most vendors have thousands of customers which they leverage to learn from and create more innovative solutions that beat competition.

You are then able to leverage these innovations while the cost is split across many different companies. No single customer has to bear the entire R&D cost. Even costs like cloud compute are split among many customers enabling their platform to be more elastic and handle peaks in demand better. Whereas your internal build will always have infrastructure running even when no employees are accessing it.

Not Invented Here Syndrome (NIHS)

There is a name for this tenancy which is called _Not Invented Here Syndrome (NIHS). Companies with large not-invented here cultures have stifled growth and lack innovation due an unwillingness to adopt new ideas or products from diverse perspectives.

Experienced managers that have seen the consequences of building are usually the most vocal on purchasing something that’s already tested. Leave your emotion and ego at the door and make decisions based on data and overall business sense is the surest way to gain that next promotion.

Make Your Boss Look Like a Star

A different way to think about maximizing output is by placing yourself in your boss’s shoes. He or she also wants to leverage the outcomes you and your team generates to execute on his or her own agenda. This could mean fighting for more revenue to sponsor their project or gain a promotion.

The more your work can impact business goals, the better your boss will look in the eyes of the CEO or board. This is where the saying make your boss look like a star has true meaning. After all, the CEO or department head is also evaluated on business goals such as revenue and customer success.


Do you want to know how customers use your APIs? Try Moesif API Analytics!


This article was originally written for the Moesif blog by Derric Gilling, CEO and founder of Moesif API Analytics.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .