In his book What Got You Here Won’t Get You There, Marshall Goldsmith talks about a common, big mistake that he sees his coaching clients make. They hold onto a belief that sounds like, “I behave this way, and I achieve results. Therefore, I must be achieving results because I behave this way, and I should continue behaving this way.”

In reality, they might be succeeding in spite of their behavior, not because of it.

That’s a common pattern that shows up with engineers as they become tech leads as well. Many engineers who become tech leads move into the role because they achieved results as individual contributors, so of course there is a strong temptation to continue engaging in the same behaviors that got them there — thinking those behaviors will continue to take them up the career ladder.

We see this play out when we look at engineers at big companies like Google, Facebook, and Amazon. The vast majority hit a ceiling in their careers at the level of senior engineer — generally only two levels above the starting position of a college graduate — precisely because the same behaviors that got them to the level of senior engineer won’t take them to the next level.

I remember even being told straight out during my time at Google that a senior engineer was a terminal position — one could stay there indefinitely, and there was no expectation to go beyond that.

Being unaware of that ceiling can be frustrating.

In this post, we’ll take a look at the 5 most common mistakes that new tech leads make — ones that hold them back from further career growth — and how you can avoid them.

Mistake #1: Trying to do everything on their own.

For most people, the tech lead role is the first time that they’re responsible for a team’s output.

Early in our careers, we often focus on increasing our technical breadth and depth — and we’re rewarded for doing so. We learn that conquering our fear of jumping into unknown code is important training.

When I was writing my book, The Effective Engineer, I interviewed Bobby Johnson, a former engineering director at Facebook who grew the initial infrastructure team. He concluded after years of observation that his engineers' success was highly correlated with "having no fear in jumping into code they didn't know.“

Where new tech leads get tripped up is equating fearlessness and technical leadership with having to do things on your own.

Sometimes, we might feel a need to prove to ourselves or to others that we’re capable of doing it. Other times, we might feel afraid of looking dumb or bad from not knowing all the details. We might hold a belief that it’s not okay to say “I don’t know” or “I don’t understand” — even when, as Former VP of Engineering at Khan Academy Ben Kamens shares, it can be a demonstration of maturity and security.

The surface area of things to understand, coordinate, and guide quickly becomes larger than you have time for, and you'll exhaust yourself if you try to cover it all.

How do you be a tech lead for someone more experienced than you? How do you help, support, and advise someone in an area that you’re not familiar with? How do you expand the scope of what your team can do beyond what you can do on your own?

A big part of leadership is asking for help — help from the team on reviewing each other’s designs and code, help to get important or urgent tasks over the finish line, help in figuring out how to design the team structure and what’s important to work on.

Internalize that asking for help — and breaking free of the belief that you need to do everything on your own — is both a sign of courage and strength. It’s the path toward becoming an effective tech lead.

Mistake #2: Believing that “people problems” are solely a manager’s problems.

Oftentimes, we’ll hear that a tech lead is responsible for the technical outcome of a project.

And, early in our careers, we can often get away with focusing on just the technical aspects of our work — our technical designs and our code. It’s easy as we progress in careers to stick with what we know, to stay in the comfortable realm of code, and to write off what might seem like “people problems” as someone else’s problems.

But that’s like driving a car and following GPS navigation that tells you to keep going forward, even when you see that the road would take you into a ditch.

The reality is that investing in what many write off as “soft skills” gives you a significant amount of leverage over the results your team can deliver. That’s true even if your primary motivation is the technical output of a project.

One of the reasons that Honda has built some of the world’s most reliable cars is because of a philosophy of kaizen, or continuous improvement. Fear can often squash good ideas, and one of the most important things they do is to train people to forget titles and focus on the shared goals. Employees are empowered to suggest and take ownership for improvements — even when they’re not directly responsible for those areas.

Similarly, you’re going to be much more effective in your work if you don't shy away from addressing people-related issues — even when you're not directly responsible for them.

Giving and receiving feedback can improve how your teammates work together. Holding people accountable for what they commit to and for the team's values elevates the quality of output produced by the team. Holding regular one-on-ones with your teammates can help you understand people’s motivations, what’s going well or not well on team, and give you insight into how to continuously improve the team.

Mistake #3: Avoiding process and meta-work because it seems like it adds wasted overhead.

When I first worked at Quip, I felt the joy of only having one meeting a week for most weeks — a single company all-hands with the 14 people at the company. No need to waste time on meetings and more time to get things done!

Unfortunately, I held onto that aversion to meetings a little too long, even as the engineering team grew. Sometimes, we’d work on the wrong things. Or we’d try to resolve over asynchronous communication something that would have been much more efficient by gathering all the stakeholders in-person.

I had forgotten that what was important wasn’t avoiding any and all process — it was just to avoid wasting time on processes that weren’t serving the team’s needs.

Well-designed processes and norms streamline and simplify decision-making. They leave everyone feeling more effective, more excited, and more informed.

Well-designed retrospectives, for instance, can create the space to reflect on and celebrate how your team’s doing — so that success and performance increase for what’s ahead. Well-designed status sharing (which might be a standup or a round of Slack messages or something else) can leave team members feeling invested, more motivated, and more part of the team. Well-designed project kick-offs leave people clear on what success looks like and where to go. Well-designed feedback loops give you insight into how the team is doing.

Jean Hsu, in her blog post "Finding your team’s Goldilocks process,” shares best practices for collaboratively finding the right level of process for your team — where the overhead more than pays for itself in terms of team effectiveness.

Mistake #4: Not communicating effectively.

Effective communication means 1) saying what’s important in a way that lands with the recipient, and 2) listening for even what’s not being said.

When it comes to saying important things, we sometimes mistakenly equate saying words with communicating effectively. This often shows up in feedback conversations when we don’t check in on whether the recipient understood what we were actually saying.

Other times, we hold back on saying what needs to be said — that might be managing down, managing sideways, or managing up. No one likes to be the bearer of bad news. And so we might procrastinate on doing the hard thing of admitting to stakeholders when schedules and timelines slip — perhaps even optimistically rationalizing to ourselves that we can just make up for lost time.

As a tech lead, it’s also important to advocate for your team in company settings — sharing your team’s mission, your team’s contributions, and how it fits within the broader picture of the company.

In feedback conversations, ask “What are you taking away from this conversation?” to check in on how things landed. When communicating status, put yourself in the other person’s roles and ask, “Would I want to know this information sooner?” Create time to share the context of what your team is doing with adjacent teams or with the company. Take communication classes like our 1-day Building Alignment training.

When it comes to listening, different words can mean different things to different people. One person’s “this is not ideal” may be another person’s way of communicating “everything’s falling apart.” Notice whether a person’s body language lines up with what’s being said — if not, ask what’s going on. Approach conversations with an open mind and curiosity and ask “what does that mean to you?” when you hear something that could be ambiguous.

Mistake #5: Embarking on long, all-or-nothing projects when they’re unnecessary.

The first time I embarked on a rewrite project as a tech lead, a 4-month project slipped into a 9-month project and nearly threatened the survival of the startup I worked at. The second time, the rewrite project was ultimately abandoned after 9 months. It’s no wonder that Sam Schillace called trying to rewrite something from scratch the “cardinal sin of engineering.”

Whenever we take on new initiatives, there’s always risk involved. Those risks could be technical — can we solve this piece of problem? Or business-related — is this the right solution to the problem? Or people-related — will everyone be able to commit to the time and energy required to solve the problem? Or organizational — will we be able to stay coordinated and aligned? Or something else.

Being overly ambitious and not structuring projects to reduce risks opens the door to a high variance of failure. Instead, validate any assumptions required for a project to succeed as early as possible, take on risky parts of a project that are not well understood upfront, and define milestones and phases to structure the timing of your work.

Moreover, one of the highest-leverage approaches to big rewrite projects is to create incremental rollout plans — the reduced risk often more than compensates for any extra work required upfront.

For example, when we built the desktop app at Quip, we needed to migrate server-side rendered Python views into client-side rendered Javascript views. And we invested time to build a hybrid infrastructure that allowed us to incrementally convert Python views in our web app to Javascript views and start using the ported Javascript views in production. The infrastructure wouldn’t be needed after the migration was over, but the extra scaffolding let us validate and test upfront all the new code that we would be writing — something that would’ve been terrifying to postpone until the end of the project. It was a powerful example of using an incremental rollout plan to reduce risk.

Avoiding these five common mistakes can feel hard — and at times uncomfortable — because they involve new skills and new terrain. The good news is that discomfort is where growth happens, and stretching yourself in these new areas will grow you toward the impact you want to create.