Category: Business Value

The 5 ways to Fail as Engineering Managers in Startups

The 5 ways to Fail as Engineering Managers in Startups

This article is a compilation of multiple years of my experience being an Engineering Manager and subsequently running the Tech Org and managing multiple Engineering Managers. I have tried to summarise and condense them.

Having a good manager can make you feel supported, can boost your career growth (and sometimes personal), and help make your team and company a happy place. On the other hand, having a bad manager can make your work-life miserable and could hinder your growth and drain you.

Engineering Managers have a huge impact on their team’s, morale, outcomes, timelines and most importantly the professional growth and help them carve a career path. But, you may have seen, heard or felt that some or most Engineering Managers are anything but the above description, right? Do you want to know the root cause of the problem?

It is the practice of making a high-performing Individual Contributor/Engineer the Tech Lead and thence to an EM!

Trust me when I say this, I have seen it multiple times. I have seen many good Engineers burn out as soon as they have people management responsibilities. An Engineer may be okay to mentor some junior devs and help them get the right design etc. But, S/he needs to have a people-first mindset to become an Effective Engineering Manager (or any of the myriad titles with the job function).

The 5 ways to Fail as an Engineering Manager!

So, assume an Engineer is looking to move into Engineering Management, the following are the pitfalls S/he should be aware of as these are the most common ways EMs fail.

1, Too much Solutioning, not enough listening.

Interestingly, this can happen both when you’re not confident as a leader and when you are too confident. We tend to focus on solutions too much instead of supporting/empowering others or listening for more context. Sometimes people only need someone to vent to and are not looking for solutions immediately. Even when they are, we can act as coaches and guide them to the solutions, helping them grow in the process so that next time they will be able to solve on their own. Even when they need an immediate solution, we might fail to get the whole context by not authentically listening to them.

Such leaders usually jump to solutions right after hearing about an issue, and even when they ask for more details and input, they are not listening authentically. They might get impatient when the discussion drags on.

There are two critical Skills to practice to overcome this pitfall. Effective Listening and asking more Leading Questions.

2. The silver bullet or the Golden Rule Fallacy

We might not be very conscious about it, but we all have a natural, default style when it comes to management. This is sculpted by our general personality, our experiences, our bosses and how they treated us and things we’ve learned along the way. As managers, we unconsciously rely on this style, and without guidance, we tend to use that style with every direct report. Even when it becomes conscious, we justify this with ‘this is who I am’ and sometimes even with core values and our self-image

Don’t “Treat others as you wish to be treated”

The above statement could be borderline Blasphemy to many people in many aspects (including cultural or religious). How could it be untrue? If most major religions/cultures preach it?

The reason for this paradox is simple, we all assume we want to be treated fair. But, fairness to me may be unfair to you and the other way around.

For example, I tend to react very well to negative stimuli, i.e: critical remarks. I use them to better myself and continuously improvise (most times, at least) whereas some other person may feel it draining, for them, the Positive Reinforcement techniques may work well.

While having strong core values is vital to being a successful leader, using a single management style just simply won’t work with all your Team Members over the years. Doing this way WILL HARM some of the Team Members (and of course hinder your performance as an engineering manager, too). The Golden Rule managers often talk about the one true way to do things. They get overprotective/defensive about their style as they face more and more challenges. They often see the failure to be with the team members who don’t respond well to their style instead of adapting to theirs. This is especially important as more and more of you’re team members tend to be Millenials.

The most obvious display of the Golden-Rule/One-Trick Managers is hiring #minimes. They hire a team full of similar styled team members. You may have recognised certain trends over the years, a very hands-on manager will not only hire, but also treasure a very hands-on problem solver by empowering them. On the other hand, a Process-oriented manager will hire their lieutenants to be fully process-driven ones.

The problem with the first example is, you’ll have an army of Debuggers, Fixers and Solvers but very few(if any) to think & execute in a scalable & sustainable way.

The problem with the second example is, you’ll have an entire team quoting the “Rule-book” to each other in no time and meanwhile, the company may be bleeding.

There is only one approach here, As managers, it’s our core job to form a good working relationship with our team members. This will require us to adapt our style or adopt new styles.

3, Low self-confidence

Yes. I meant it. I have known multiple awesome engineers in my career who started having Low Self-Confidence after they became managers.

Honestly, I have gone through it myself at various points, before climbing up the rope. The reason is also quite obvious, when I was an IC/Sr.Dev I know what was the outcome and what was the timeline and quality of deliverables was something I prided in. So, nothing was ever out of control for me (except maybe twice).

And if something exceptional happened, I can “Report” it and either get the “Scope” or “Timeline” modified and my self-worth was left unchanged. Now, as the first-time manager, I realised that I am that “Exception Handler”. Sure, I can go to my Delivery Director or Group Program Manager etc, but I am supposed to be the first line of defence from exceptions affecting the Business! This is the no: 1 cause for low self-confidence.

But, it is by no means the only one. The second most cause according to me is delayed feedback and low observability of Business Value delivered. It’s usually really hard to see our work’s positive effect, feedback loops are just too long, and cause-and-effect relations aren’t always easy to see or quantify.

People with low self-confidence usually have a hard time saying “I don’t know”, which is essential as an engineering manager. We cling to the thought that we have to know answers to everything that comes up; otherwise, we’re just not good enough.

I’ve seen some insecure managers trying to do team members’ jobs. They do this not because they don’t trust their team, but they need something they’re proficient with to feel more secure and confident. Another way for such managers to feel that they are still worth something is to be too nitpicky, for example, in code reviews or simply when giving feedback.

Among many things, all this can lead to the engineers feeling that their engineering manager is competing against them in a way. This is THE worst feeling you can give to your team and a sure way to fail as a Manager.

Be the force multiplier to the team, not another grunt.

There are proven ways to come out of this zone. Discuss with your peers (other EMs/TLs) and your Manager, open up your insecurities & fears. You will realise that this is much more common and also learn from them.

4, People or Business Attitude (as opposed to People for Business)

There are two most common styles of management, Too much Business Focus and Too Much People Focus.

There are Managers and Leaders who are only into Business and view upon their team as only “Resources”. They are driven by Goals, deadlines, KPIs and Metrics. They seemingly don’t care about their team’s wellbeing.

There are Leaders who are only into the people part of their team. They create a virtual haven for their team. They shield and protect their teams from the other parts of the company and the world at large. They seemingly don’t care about business outcomes or performance that much.

Needless to say, these two styles are diametrically opposed.

Fortunately, I have seen and worked with organisations with both styles of Management and Managers. (And believe I did pick some elements from both). In the StartUp eco-system, Boot-Strapped and bootstrap influenced organisations tend to be slightly tilted toward the People First management philosophy. And generally, organisations that are VC funded and with an aggressive growth appetite will be tilted toward the Business First management philosophy.

But universally, all leaders I have worked with accept/agree that the key to success is balancing the two approaches.

Too much focus on the business in a leader will sometimes result in that leader prioritizing short-term wins over long-term ones. Such managers will talk a lot about holding people accountable. They are generally okay in abandoning the team members who don’t fall in-line in terms of Team Commitments and Performance, instead of coaching or aligning. The cost here could be enormous. People will get burnt out quick and will leave, The company culture suffers.

Too much focus on people without the consideration that your team is responsible for the company successful can be even worse. Such leaders will position themselves as the “Gatekeepers of hell” with their team. They will defend their team no matter what and will view every discussion/motion as “the Battle of Thermopylae”!

In the end, is is not as much as balancing these views. Its actually building synergies between these two seemingly conflicting ideals. You as a leader and manager will have to find ways for your teams to grow and be successful in tandem with the business goals.

5 – Not Delegating Enough.

The most common mistakes for leaders and managers are usually focused around delegation; either a manager is delegating too much or not enough. This is especially common for an Engineering Manager. Most Engineering Managers think of themselves as a “Specalist” Engineer than a Manager, especially applicable to an EM at the early part of his career. Any manager who fails to delegate will become overloaded and fail to move the business forward. A manager who over delegates with no explanation as to why could lose the respect of their team. The key rules to live by as a manager when it comes to delegating are:

  • Only ask someone to do something you would be happy to do yourself if you had the time
  • Only delegate a task to someone who is happy to take on the task
  • Only delegate to someone is capable of completing it to a level you would be happy with yourself or can get there with quick review comments

The trick is to know when to Cascade, Delegate & Escalate!

Concluding Remark

Obviously, this list is not-exhaustive and there are other significant issues causing to failures of Engineering Managers. But, this is a Ranked list from my personal experience.

I was extremely fortunate to work with some of the best leaders and managers and each one of them has shaped my skill, style and everything in between. While mentioning my “managers”, “My Teams” over the last 8-10 years have played an equally important role in this transformation.

Also, If you’re looking forward to learn how can you be a manager/leader your team will not run away, check out this short course by Laurie Ruttimann – https://www.linkedin.com/learning/be-the-manager-people-won-t-leave/be-someone-people-trust-no-matter-what

Business Value delivery by Engineering Teams in StartUps – Part 1

Business Value delivery by Engineering Teams in StartUps – Part 1

In this multi-part post, I will try to articulate my view on the importance of business value and its delivery by engineering teams. While most of this is written from the view of a StartUp, some elements of an established organisation are also used.

Part 1: Defining Business Value & Role of Leadership in it.

Business value is a concept that can mean multiple things to multiple people and the tricky part is all of them could potentially be valid. A product manager may value a long list of features that his/her customers have demanded for months. Another Product Manager working with internal teams to improve efficiency (revenue) will value the enhancements the accounting or support team was after. While the support manager may value a more stable product to keep the customers, s/he deals with happy. 

Business value & impacts are a difficult thing to define and deliver, while it is even more difficult to measure.A collaborative effort is required to define and deliver business value, with consideration needed to ensure all voices are heard.

While most of what I will be covering in this article is typically the purview of product management, I have learned that engineering leaders have a critical role to play in this space. (Will write more on that in the next part.)

Engineering leaders bring product development experience and technical expertise to the table to provide a crucial element to the delivery of business value which I will try and explain in this article.

What is Business Value?

I would define “Business value” as any improvements to systems, processes or people that augment the products or the ability to deliver products or services to the customers, thereby increasing the revenue or experience or both. No two companies will have the same definition of business value. Forget two different companies, a company in its 5th year will have a very different perception of value to its first year. This is due to their products and customers being different and requiring different elements to add value. One company may find value in the ability to build out its new product offering quickly. While another may find value in responding to customer support requests in a timely manner. 

Due to the rapid changes around us, the things that businesses value changes often. Companies often face new challenges that require a quick response.

Be agile, be nimble” is the key phrase.

These challenges can come in the form of new product features released by competitors, or a specific feature request by a key customer, or changes in the market that render the current product/feature obsolete. Business needs or desires, therefore change just as quickly as any of these external changes.

You have probably worked for a company that comes to the engineering team with new requirements, seemingly daily?

It is not because they cannot make up their mind; It is in response to the changing business needs. This changing goalpost is one of the main reasons that Agile development practices have taken precedence from more traditional waterfall methodologies for software development. 

Velocity is everything, a report by McKinsey on how Developer Velocity fuels Business Performance will give more insights on this. A snapshot from the report is below.

Why is business value important? 

Reacting to change and delivering business value with haste is a crucial area of importance for modern businesses. All companies exist for a purpose. The majority of companies exist to return a profit for their owners (individuals or shareholders), while some companies exist to provide a social service. The critical thing to note is that they all exist to fulfil a specific purpose which guides their definition of business value. 

No matter the company large or small, if they stop innovating, and their products or services stop being relevant to society at large and market in particular, that company will whiter and eventually die.

Kodak is a prime example of this occurring in recent history. In today’s world, IT, whether it be hardware or software, is the largest driver of business value. It is therefore critical that the software engineering teams keep delivering the things that the business need to fuel their innovation.

We, as engineers, are not employed to just build that shiney app in the latest technologies, but to deliver our contribution in support of the business purpose (If not drive it!)

The importance of Engineering Leadership in Delivering Business Value

An engineering leader is, of course, a People Leader, and s/he is also responsible for the Execution, both technology and delivery of the engineering team. However there is a third dimension which often goes unrecognised, is that great engineering executives must also be great Business Leaders; they help drive alignment with other leadership/executives and shape the strategy and direction of the business itself.

It is this underutilised/forgotten element which I will try to detail here.

A People Leader & an Execution Champion:

Engineering leadership is often naively thought of as being simply a great Architect or Engineer or a Manager. But most of you already know it’s more than that. Team leadership will involve some combination of team building, culture, leadership development, and performance management.

For detailed coverage on Engineering Leadership – Please checkout my Previous Post

Most of this responsibilities will be bang in the middle of the comfort-zone of a rising Engineering Leader.  But one of the hardest things for most engineering leaders as we scale is, to continue having an accurate forecast of when products and features will be delivered – what the business always asks for.

That is partially because this bleeds into the third, and the least recognised dimension of engineering leadership.

The Missing Sauce: A Business Strategist

Engineering leadership isn’t just about delivering products faster, or making engineers more productive. It’s about guiding the team in the same direction as the business, about continuously improving, and it’s about being the voice of engineering as a part of the decision-making process of the executive team. Of course, these are all dependent on our ability to understand the work our engineering teams are doing and how it aligns to business goals.

The third dimension – Business Alignment – is often overlooked or made difficult by other executives, but is absolutely necessary for the management of a successful engineering org. This is the strategic practice of engineering management, and all operational decisions depend on it. Business alignment means ensuring your organization is focused on the right projects that align with the business’s goals. 

The Product org can detail/design and Engineering org can build as many features as they can agree on, but what/how does it matter, if they do not align with the business objectives or goals? Business alignment involves the right allocation of resources that supports business objectives, and helping to drive those business decisions of which projects are strategically important. (at itilite, this is always the First Principle)

How do we deliver business value?

So how do we actually deliver business value? Business value isn’t created by a soloist delivering a virtuoso performance, but a collaboration of the business, product, engineering and customer success teams working together to realise a shared vision. 

Below are the five ways this can take place; together, these provide a roadmap for delivering business value;

  • Define systems development strategy
  • Help business define requirements 
  • Visualise the work and prioritise
  • Schedule and communicate delivery
  • Deliver value often and get feedback

I will try to articulate through each of these one at a time and dig into a little more detail in Part 2 of this article.

Bitnami