Why Projects Fail (and Why It’s Usually Not the Tech)

If you’ve worked on enough networking projects, you’ve probably lived some version of this story:

A project kicks off with a big goal. Big budget. Big expectations. A timeline appears out of thin air. Weekly status calls begin. Green… green… green… and then suddenly… yellow. And once it’s yellow, you can feel it: the tension, the pressure, the fear of being “the reason” things slip.

Engineers don’t hate projects because we hate structure.

We hate projects when the structure turns into theater.

In this episode (Part 2 of our “Learn the Business” series), we sat down with Eyvonne Sharp and Michael Bushong to talk about the real reasons projects derail, and what to do when you’re the one holding the keyboard while the organization holds the stopwatch.

Here’s the punchline:

Most projects don’t fail because the technology is too hard. They fail because the people system breaks.

1) The project isn’t failing, the alignment is

Eyvonne shared something that should make every technical lead pause:

80–90% of project failures aren’t technical.

When things blow up, it’s usually not because someone forgot how BGP works. It’s because we never got the human fundamentals right:

• Do we have executive alignment?
• Do we have the right executive sponsor (someone who can actually help when we get stuck)?
• Do we have a shared definition of success: what we’re partnering to achieve?
• Do we know the scope, the requirements, and where the work stops?
• Do we know what “unstuck” looks like when the project hits reality?

One of our favorite moments from Eyvonne’s #AutoCon4 talk was her story about a peer creating a single slide with one question at the top:

“What are we partnering to achieve?”

Just a paragraph. A guiding statement. Something to point at when the project starts drifting.

That one move does more for scope control than a hundred Jira tickets.

Because most of the time, we don’t drift from the plan. We drift from the shared understanding of why we’re doing the plan at all.

2) Why timelines feel fake (and why that’s still a problem)

Andy Lapteff 🛠️💬 admitted something a lot of engineers may feel but don’t always say out loud:

Some project timelines feel like “make pretend calendars.”

We guess. We commit. And then we get punished when reality shows up.

Mike framed this in a way that clicked instantly:

Information asymmetry.

If you don’t know why a date matters, you’ll experience it as arbitrary.

But “arbitrary” doesn’t always mean “pointless.”

Sometimes the date is connected to:

• fiscal boundaries and reporting cycles
• downstream dependencies and staffing plans
• capex/opex timing and budgeting
• customer commitments, contracts, or product milestones

Here’s the problem:

When leadership doesn’t explain the why, the team fills the gap with cynicism. And cynicism kills ownership.

So if you’re leading projects, this is a straightforward upgrade:

Don’t start with “Here’s the date.” Start with “Here’s why the date matters.”

That one habit reduces resistance, improves buy-in, and makes constraints visible before they become a crisis.

3) Escalation isn’t “going over someone’s head”

Andy confessed something else:

When I hear “escalation,” I think: “You’re going over my head, to my boss.”

Mike and Eyvonne reframed escalation as something totally different:

Escalation isn’t “me vs you.”

Healthy escalation is: “me and you vs the problem.”

You don’t escalate opinions. You escalate aligned facts + clear options.

Mike’s approach is simple and brutal (in the best way):

1. Write down the facts, bullet by bullet
2. Confirm what’s true and what’s assumption/opinion
3. Clarify what each team is optimizing for
4. Surface constraints
5. Narrow to 2–3 viable options
6. Escalate only when the team shares the factual picture but needs a tie-breaker decision

This is how escalation stops being a courtroom and becomes a decision mechanism.

A great example: resource contention.

Two projects need the same constrained expert (poor Zach). Without escalation, Zach solves it the worst possible way: by working 80 hours to make everyone stop yelling.

Escalation exists so leaders can see where constraints truly are, and make a tradeoff decision the team can’t make alone.

4) How to deliver bad news to leaders

This might be the most practical section of the entire conversation.

Andy asked: If I have to tell you we’re behind, how do I do it without making everything worse?

Mike’s answer was perfect:

Use the smallest number of words possible.

Because what engineers often do in high-stakes moments is dump an avalanche of context as a defense mechanism:

• to prove credibility
• to soften the blow
• to preempt blame
• to punish ourselves before someone else does

Leaders don’t need the novel first. They need the headline.

A strong update sounds like:

• We’re tracking three weeks behind.
• Here’s the short reason why.
• Here’s what we’re doing next.
• Here’s what we need from you (if anything).

Eyvonne added the part that changes how the message lands:

Stay calm. Avoid blame. Stick to facts. Bring an ask.

Mike added:

Panic never made a situation better.

If you need to lose it, lose it later. In the moment, your job is clarity.

5) The leadership move that instantly drains the tension

Mike shared a story about a mentor named Spencer that hit home.

When something went wrong, even if Spencer didn’t cause it, he’d put his hands up and say:

“That’s my fault.”

Not as a confession. As a reset.

Because blame is gasoline. And when blame disappears, the room can go back to solving the problem.

That story reminds us that a lot of “communication problems” aren’t communication problems.

They’re nervous-system problems.

If people are in fight-or-flight, they don’t communicate well. They perform. They defend. They hide. They freeze.

Remove blame, and you remove the threat. Remove the threat, and you get your team’s brain back.

6) Cheesecake, security incidents, and the power of informal networks

Eyvonne closed with a great story.

Major security incident. CISO on the call. Everything on fire.

The fastest fix didn’t come from hierarchy. It came from relationships.

Eyvonne texted a few trusted people who weren’t on call, the ones she knew could solve it fast. They joined, jumped in, and the incident was resolved in 30 minutes.

Why did they show up?

Because she invested in people before she needed them.

Her secret weapon: Cheesecake Day.

For every birthday on her team, she brought in homemade cheesecake (with raspberry topping and chocolate drizzle). Not as a manipulation tactic, but as a real human signal:

“I see you. I care.”

Those moments build informal networks that move faster than org charts ever will.

And in the moments that matter most, outages, incidents, urgent projects, that network becomes a force multiplier.

---

The takeaway

If you want to “learn the business,” this is part of it:

The business isn’t only about numbers, markets, and strategy. It’s also how humans coordinate under pressure.

If you can:

• create alignment early
• communicate clearly when reality changes
• escalate without drama
• deliver bad news with calm + brevity + a plan
• remove blame so the room can solve
• invest in relationships before you need favors

…you become the kind of engineer who doesn’t just execute.

You become the kind of engineer who makes projects succeed.

And that is business value.