Jumping on an engineering leadership role at a new company is overwhelming.
You want to do your best, learn quickly and make good decisions. You know that the expectations are high.
But even if you try to do your best, you will make mistakes.
So, what are the crucial things you need to pay attention to? What can you learn from other engineering leaders’ mistakes and successes? How can you make this transition as successful as possible?
In this post, you will get answers to these questions.
Steven has made this transition multiple times, and he is openly sharing everything with you so you can avoid the common mistakes and make your first 100 days as a new engineering leader as smooth as possible.
This post covers:
I've been in organizations with a track record of a frequent leadership overturn. They usually have an established engineering team.
What I'm currently dealing with is different. There has been no technology department in this organization. My task is to bring it in with my technological background.
There are 2 main challenges at this stage:
The first challenge is that you have to catch up.
Others understand the business and tech stack better than you. You need to get to the point where you know just as much or more. In any tech organization, you need to be able to provide answers anytime. In that first 100 days, you barely know anything, and you are trying to figure out why certain decisions were made.
The second challenge is getting to know the staff at hand, especially if there is an established team.
At my last job, there was an established engineering culture and a team of 40 people. I had to quickly figure out if they were good for the organization.
You're constantly balancing the business and technological understanding of what's going on. You need to understand your people and evaluate their talents and personalities.
You're in evaluation mode and need to get through it all as quickly as possible.
As a leader, especially if you're an executive, it’s expected to make your mark and to create a plan quickly. In my current organization, it’s fast and furious. I have to make a lot of decisions, and that started the first week I was there. There’s no technology, so they need help defining the vision and the goals, and we need to make choices.
At my previous jobs, there was no rush to make decisions. I don’t like making decisions without understanding the full context, because it could backfire.
From a technology point of view, I want to access all the source code. I want to see the documentation to understand the tech stack and the talent building it. I need to see how they write comments and commit code, and I have to see what the architecture is like.
I also look at non-technology aspects, like budget, product features, the product roadmap and current business contracts.
To learn about the roster, I like to do one-on-one meetings, including many skip level meetings. I don’t keep doing them with everyone in engineering, but in the first 100 days, you need to get to know the people. It’s a great way to evaluate how talented they are, to understand their motivations and what makes them tick.
Culture can be a problem in organizations. Once I was brought in to fix the engineering culture of a company. You have to dive deep and find what’s broken. The problem could be the people or the system.
You also need to figure out what your peer set is like. At the executive level, you need to understand what type of leadership the organization has. It may be a hands-on type of leadership that requires you to dig deep, or it may be hands-off, requiring you to push everything down the ladder. These are different styles, and you need to understand the expectations.
Ideally, you find out all this during the interview process, but you don't always get that luxury.
So, what do I do in the first 100 days of being at an organization? For me, it’s not about perception; it’s about making sure I have an impact and putting together a plan that moves the organization forward.
You need to consider all this when you’re in a new engineering leadership position.
It depends on the company, but there are two things I tend to do:
You have to make sure you figure out your architecture. But you shouldn't rush it. First, you need to understand the business problems.
Wherever I go, I build trust and culture around me. This is interesting in WhyHotel, because it isn't a tech company. Most people here come from real estate and hospitality. It’s a challenge because we’re from different worlds.
I try to breed trust by digging around decisions without tearing people apart. I don’t go and question, “Why did you make this decision?” Instead, I say, “I'm sure there were reasons why we made these decisions. Let's talk about them.”
You need to prove yourself a team player. I believe as an executive, you have to lead by example. This is how you build the culture.
You have to show them that you're open and transparent about communication. You need to be empathetic and you use your emotional intelligence before you expect it from others. I demonstrate my core values of being accountable and transparent to show my reports the way.
Doing this is very softy-feely. It may sound weird from a technologist, but if you can set this tone and build trust across the organization, a lot of things become easier long-term. If I want to make a big decision, people will say, “I trust Steve; he's honest and works hard.”
At WhyHotel, we also have meaty technical conversations. We have to work out what our code stack and even our IT infrastructure is going to look like. We have to make sure to evangelize that across the organization, so they don't feel like we’re jamming stuff down their throats. We're all in it together.
This is my third week at WhyHotel, and I'm focusing on showing people that I’m willing to get my hands dirty, and I want to figure out what the problems are across the organization, so I can help.
I don’t put blame on anyone for making past decisions. It’s not helpful, and that might have been a great choice back then. Having an empathetic personality and a humble approach is key when you join an organization. If you come off like a know-it-all, even if you make the right choice, people will be put off, and it can hurt you in the long-term.
I tend to like to look at my past and understand my missteps. I’m sure I will have many failures at WhyHotel, but I can’t see them yet.
What I have learned is not to jump into rash decisions. Let’s be honest, they’re easy to do. Even if it’s not explicit, people sometimes expect this from a new hire.
In my youth, I often said, “Damn it, let's just go and figure it out!” You need to keep doing that, because learning as you go is key. Planning it is hard, and things usually don’t go as planned anyway.
But don't push it too far. Thinking you can solve big problems in weeks is just arrogant.
It may even be the wrong problem to solve. When you listen to the loudest person or the first one you talk to, you only get their perspective. You need to find the root of the problems, since you are often brought in to solve them.
Finding the source is hard. I've gone down paths where I'm building and building, and after taking a step back, I realize it’s not the problem at all. By then, I may have wasted 6 months.
Establishing goals and the accountability structure from the top is important. I do that when I come in and set the tone at the executive level. If you’re not clear on what you’re trying to solve at an organizational level, then you’re just running around randomly.
I've felt this in many organizations, because there wasn’t alignment at the top. People said one thing, and then everybody walked out and did another thing. Try to avoid that. It affects everyone in the company, because they're working hard, but it’s going in the wrong direction, and they don't even know it.
That's a leadership failure. I’ve made this mistake in the past, and I try to not make it anymore. At the executive level, sometimes you don't understand the core problems. Other times, there’s no alignment at the leadership level on the approach to take or even what to aim for.
The first thing is to watch out for past decisions. There are sacred cows in every organization. You shouldn’t come in and say, “Project X is stupid.” This is not an empathetic way to approach a problem, and people are going to be put off by you. Even if that sacred cow needs a fix, there are ways to approach that.
Use your common sense and emotional intelligence. Emotional intelligence is often lacking in technology organizations. Even if the decision seems fundamentally wrong, you don't have the context of what happened in the past, so you shouldn’t judge. It’s arrogant to think that you have all the answers.
Bring humility to the job and respect people, even if they have made poor choices. I've seen engineering leaders come in and make a big fuss saying, “I don't like this code,” or, “This decision was stupid.” They may even be right, but you shouldn’t put it that way.
Even if the engineering talent is bad in an organization, people still take pride in their work. Treat people with respect, even if you're going to remove them from the organization. Others take that to heart and will respect your work more if you’re empathetic to problems. Even if you end up removing them, there's a mutual respect, and you can part on good terms.
That's my main focus.
I think about it on different levels. I'm a senior vice president of technology right now, so I need some guardrails. I don't have any qualms about discussing this with my leader. What I mean by guardrails is just knowing what areas need more attention.
At this point, I have enough experience to figure out the rest once I have the guardrails. This doesn't work for everybody; some people need clear goals. It’s dangerous to assume if you apply guardrails everywhere, it will align everyone.
You have to be crystal clear on your strategic goals for each year, quarter and month. Leaders often forget this, and then no one knows what the goals are. People working in the front lines often don't understand the impact of their work. This is a failure in leadership.
For middle management, you should set clear priorities for what should be accomplished in a quarter. For senior engineers and especially junior engineers, you can't give too much latitude. I do believe in freedom, and I want to bring in developers who don’t need babysitting.
My job is to teach, mentor and guide, not to be the taskmaster and tell everyone exactly what to do. On my seniority level, I only need guardrails, and I can figure out the priorities. In my first three weeks here, I just need to be sure to focus on the right area of the business.
When I hire somebody, on the first day, I’ll clearly say what area is a problem, and they should dive deep. I'm not telling them how to dive deep; I just point to an area of focus.
That comes from my leader giving me the guardrails on the general areas to focus on. So, I have somebody on my team focus on a smaller area, because I can't get deep on it myself.”
This is my goal-setting process.
Setting priorities is all about leadership communicating to the rest of the company what's important. This is often overlooked. You can’t have everybody interpreting things differently.
At the leadership level, you need to say what’s important, and whatever isn’t on the list is a distraction from them. The main goal that we want to create is uninterrupted focus on people solving problems, especially in technology.
It's an art; it needs immense focus. If people are distracted all the time, being pulled here and there, things don't get delivered. Then you can’t have expectations, and you can’t hold each other accountable.
I have a team of 3 people. I want to set clear expectations on what needs to be delivered, priorities, and expectations. I expect them to make good decisions, and I'm going to hold them accountable to deliver.
If they don't deliver, we should talk about the reasons. Technology is all about delivering value to the customer. If we're not doing that, what the hell are we doing? I set clear expectations about this.
I make sure all the other executives do the same across the company. If the other organizational units don’t do this, it can create churn. It's simple, but it often goes wrong.
However you do it, create focus aligned to your enterprise value.
The one thing we haven’t touched on yet is building relationships. This is what organizations are all about. You work with human resources, sales and marketing. Showing humility in engineering is important; no one should ever be the token engineering asshole.
Showing honest interest in the business or your peers’ discipline is key to this. You should know what their work looks like and how that affects you. The interest needs to be genuine; if you don’t care, don’t fake it.
I'm interested in how different business units run, because you have to put the pieces together. You need to have the product and the engineering strategy coalescing.
Have everyone show the value they add to the organization. This instills confidence throughout the company that you're going to do a great job. The heart and soul of this is to build confidence as quickly as possible about your work.
They're making a bet on you in the hiring process. I fancy myself a good hire, but I've missed too, and you're going to miss 20% of the time at best. So, you have to show them that you're the one to bet on.
It comes down to confidence and trust. If they have confidence in you, everyone will be like, “Steve’s going to crush it. I know him.”
I've been in the product technology world for about 20 years. I did R&D early in my career, jumped into product, then back into technology, and led teams of 200 people and teams of 2 people. I've been in the startup world the whole time, focusing on technology and data.
Currently I’m Senior Vice President of Technology at WhyHotel.
👉 If you are serious about becoming a great engineering leader, you should take a deep dive into the State of Engineering Management 2022 report.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.