Tech leadership mistakes that ruin productivity (and how to fix them)

Are you getting in the way of your teams? Here are some ways to create the space for them to ship quickly.

When teams have trouble shipping, it’s rarely because the team isn’t skilled enough. The likelihood that multiple people snuck through the rigorous hiring process and are slowing down production is low.

If you ask leadership what the problem is, you might hear some variation of, ‘We can’t get anyone to take ownership! No one wants to be accountable! We have to manage everything ourselves!’

If you ask individual contributors, you might hear a different story: ‘I have no idea what I’m supposed to be working on! Leadership keeps moving the goalposts!’

Both statements are probably true.

From the perspective of a leader, when teams aren’t delivering, it’s easy to lay the blame on managers or individual contributors. Are they just not good enough? Did you hire the wrong people?

That’s almost certainly not the case. If you find yourself thinking along these lines, remember: if an entire class is failing, it’s probably worth looking into the teacher to see where the problem is.

Far more likely – and far more frustrating to everyone involved – leadership is making critical mistakes that are actively blocking teams from moving quickly.

Rather than focusing on blame, however, let’s look at the contributing factors that slow teams down, and see what can be done to fix shipping velocity.

Four engineering leadership mistakes that impact productivity

1. Plans change too frequently

A team can only be as effective as their plan. And many leaders in tech today refuse to leave plans intact. Too many of us have misinterpreted ideas about adaptivity and agility to mean, ‘I need to be able to change everything at any moment if new information becomes available’.

There’s a firehose of new company, competitive, and industry information coming into leadership at all times. Leaders want to respond to this information and adjust plans as soon as it arrives – after all, that’s what leaders are supposed to do, right?

However, the team lacks context to understand why the changes were made. All they experience is steady thrashing of the plan. The only constant is change – they have no predictability or stability in the plan, so teams are hesitant to take ownership of it.

2. Development cycles are too long

When a plan will take more than a quarter before even a prototype can be delivered, it’s a bad smell. Dana Lawson uses the phrase ‘ship to learn’ when talking about the need to ship smaller deliverables more quickly.

Unless we get our work into the hands of real users, we’re just guessing. As experts on our product space, our instincts are likely pretty good, but the value of a hypothesis is inversely proportional to the amount of time it takes to validate. The only way we know if the work we’re doing is good is to ship it and measure results.

Leaders know this. We hear leadership talk about iteration constantly. However, when the time comes to actually scope down and choose short-term deliverables, we lack the discipline, and too often, decide to tackle the whole scope all at once, dooming ourselves to six or more months of work with zero feedback along the way.

3. Leaders stay too involved in tactics for autonomy to exist

Imagine yourself as a member of the team. Leadership gives you a project and tells you to own it. You sit down to start doing the work, and you feel eyes burning into the side of your head – the person who just assigned you the project is staring at you intently. ‘Go ahead,’ they say, gesturing toward your computer. ‘Be productive.’

Having someone hovering over your work in progress is an anxiety nightmare. You’re under so much scrutiny that your first draft feels like it needs to be polished. You start second guessing your choices, looking to the leader watching over you for signs of approval or disapproval. Very little gets done.

Despite knowing it’s not an ideal way to work, leaders tend to forget (or ignore) this fact and hover over the team.

What’s worse: in addition to the stress caused by hovering around the team while they try to work, staying too close to the project introduces the temptation to make small adjustments, which leads to the plan changing mid-flight yet again.

4. There’s no source of truth for the plan

Most projects start off with a plan doc of some sort. Unfortunately, many teams don’t have good habits around maintaining plan docs. Information quickly goes stale in the doc, decisions get made in Slack, email, or during conversations that never make their way back into the plan, and the end result is that the only real source of truth is inside leadership’s head.

If the only way to be sure you’re doing the right thing is to ask someone in leadership, how can you expect anyone to confidently take ownership over the plan?

Four ways engineering leaders can drive productivity

Now we’ve covered the common leadership mistakes, let’s dive into what leaders can do to create space for teams to ship quickly.

Teams are made up of people, so when advice claims to solve complex business problems in four easy steps, it’s wise to look at it with a healthy amount of skepticism.

That being said, there are a few things that tend to be true on most productive teams I’ve interacted with. Give these a try with your team and see if it’s true for yours as well.

1. Plan in the Goldilocks zone

Adjusting the plan too frequently makes it impossible for the team to take ownership. Relentless churn undermines confidence – people don’t want to do work that will be thrown away, or worse, get told they did the wrong thing because they followed a plan that changed out from under them.

However, a plan that stays stagnant for too long puts the company at risk of missing opportunities or wasting time pursuing outcomes that won’t pay off. Leaders need to act on new information to guide the company toward success.

A company’s plans need to change in the Goldilocks zone: not too fast; not too slow; just right for both short-term progress and long-term success.

2. Create long-term plans with short-term milestones

When planning, lay out an ambitious vision of the future. This is where innovation happens!

To make that ambitious, long-term vision happen, you need to create a map from today to that glorious future. This requires defining clear milestones that define short-term projects that build on themselves toward the full vision.

The plan must be in a plan doc, and all notes and decisions need to be added (or at least referenced) from there. If you’re looking for a template, try this Notion plan template I use with my team.

The long-term plan is almost certainly going to be adjusted over time, so it doesn’t need to be scoped out perfectly. The short-term plans should not be adjusted, however, so the first couple milestones should be very tightly scoped.

The most important part of this is giving the team clarity and context. Why this project? Why is it important now? How does this accomplish company goals?

3. Establish clear expectations and ownership of milestones

Doing work effectively requires a crystal clear set of expectations and unambiguous ownership. When a plan has a solid scope, a clear definition of done, and a single owner, the team can work with confidence.

This means each project needs to clearly state:

• What will be done
• Who owns the work
• When it will be done
• How follow-up will be handled

The sweet spot for a milestone is one to three weeks of work. This is long enough to do something meaningful, but not so long that there are bad consequences if the work ends up missing the mark.

As a leader, your role is to weigh in on the plan:

• Ask clarifying questions
• Correct any glaring problems

However, it’s important not to nitpick. Only step in if there’s a problem, not if there’s just something you would do differently.

4. Commit to trusting the team and only weighing in at milestone check-ins

As a leader, you may have been nodding along to the last three solutions, thinking, ‘Yes, this is exactly what my team needs to do better.’

Get ready. This is the part where you have to do something hard.

You have to approve the plan, step back, and let the team work.

Let me clarify. You have to let the team work without showing up to help them or check in. You have to let them actually have ownership, and that means waiting until the formal review to weigh in. Until that point, unless you’re specifically tagged in, you need to avoid dropping into the project. Nothing is more disruptive than senior leadership dropping into someone’s DMs or showing up in tactical meetings.

Trust the team to be good at their jobs and execute the plan. When the milestone is complete, you’ll have a chance to give feedback, review progress on goals, and potentially course correct the overall plan if new information has come to light.

This is why it’s important to shoot for shorter time frames (one to three weeks). This is long enough for the team to confidently execute against the milestone without sudden shifts in the plan, and short enough to mitigate the risks. Each milestone provides data that either further validates the project or proves that part of it isn’t working. Learning that you’re wrong after less than a month of work is great – it means the company is fast to ship and fast to learn. Learning that you’re wrong after 6–12 months of hard work, on the other hand, is extremely costly, demotivating, and competitively disastrous.

Reflections

Leaders need to set the example. If you want your teams to ship quickly, you need to create an environment that allows them to do so. Agree on a process, then commit to actually following it – a process that executives don’t have to follow is not a functional process.

Here’s a recap of how to create space for your teams to ship quickly:

• Clearly define goal, metrics, scope, and milestones for every project
• Space milestones apart by one to three weeks
• Do not change the plan between milestones
• Do not make adjustments or add input between milestones
• Hold a stakeholder review at each milestone
• Revise the plan only during stakeholder reviews based on data and feedback
• Capture all revisions, feedback, and changes in the plan doc with a decision log

By following this workflow, you’ll lay the groundwork to let the team truly take ownership, which is how you build a highly productive team.