Phillip R. Kennedy

But only if you've built an environment where they're not afraid to say it.

What idea did someone on your team challenge that you're grateful they did?

♻️ Share to inspire braver leadership
➕ Follow me (Phillip R. Kennedy @prokennedy.bsky.social ) for more insights on building high-impact teams

Then wonder why their projects fail, innovation stalls, and the obvious solution was sitting in someone's head the whole time.

The best solutions come from the person brave enough to say:

"What if we're overcomplicating this?"

A three-month employee who wasn't afraid to challenge a seven-figure pitch.

Most leaders build teams that agree with them.

They mistake nodding for alignment. Silence for success. Consensus for correctness.

We didn't hire the consultant.

Instead, we spent six weeks rewriting those two workflows. Cost: $120K.

Customer complaints dropped 71%. Support costs down 58%.

Same impact the consultant promised. 90% cheaper. 8x faster.

Here's what saved us $1M:

My engineer pulled up our support tickets on his laptop.

"These two workflows account for 87% of customer complaints and 60% of our support costs. If we fix these, what's left that actually needs transforming?"

He was right.

"Why are we rebuilding the entire platform when 80% of our problems are in two legacy workflows?"

The room went silent.

The consultant started explaining why comprehensive transformation is necessary. Why you can't just fix pieces. Why thinking small keeps you stuck.

A consultant pitched us a $1.2M "digital transformation."

Beautiful deck. Bold promises. Timeline: 18 months.

My newest engineer, three months on the job, raised his hand in the pitch meeting. 🧵

What world-class IT looks like in the gen AI era From developing meaningful business relationships to establishing cultures of continuous learning, CIOs must recast IT’s missions and objectives to help fuel transformational AI success.

From developing meaningful business relationships to establishing cultures of continuous learning, CIOs must recast IT’s missions and objectives to help fuel transformational AI success. www.cio.com/article/4064...

Who on your team is operating below their capability because they can't see what you see?

♻️ Repost and comment if you found this valuable
➕ Follow me (Phillip R. Kennedy @prokennedy.bsky.social ) for more like this.

So he performed at barely competent, despite having world-class capability.

Your job isn't just managing work. It's revealing the gap between who they are and who they think they are.

Because that gap is where potential goes to die.

Your team's performance ceiling isn't set by their skills.

It's set by the story they're telling themselves about their skills.

My architect was world-class. But his internal narrative said he was barely competent.

He proposed redesigning our entire data pipeline. Something he would've never touched before because "someone better should handle it."

His proposal was brilliant. We built it. It's still running today.

Here's what nobody tells you about leadership:

"Three engineers just asked for your code review specifically. They trust your judgment."

Small observations. Specific evidence. Things that were true but invisible to him.

Three months later:

Not because I gave him a pep talk. Because I started pointing out what he couldn't see.

"That database optimization you just did? That's senior architect-level thinking."

"The way you explained that technical decision to the CEO? I couldn't have done it better."

Every project felt like proof he was about to be exposed as a fraud. So he'd hesitate. Second-guess. Rewrite code that was already good.

Not because the code was bad. Because he couldn't see that it was good.

The shift took six weeks.

"Every system has bugs. You fixed them in production without a single customer noticing. That's mastery, not failure."

I watched his face. He'd been carrying this story for months. Maybe years.

Here's what I realized:

He wasn't lazy. He was terrified.

"You shipped our authentication system in six weeks. That was supposed to take four months. You didn't miss a deadline, you crushed an impossible one."

"Yeah, but it had bugs."

And he genuinely believed he was failing.

I pulled him into a room:

"You think you're getting fired?"

Long pause. "I mean... I miss deadlines. My code always needs fixes. Everyone else seems better at this."

"I don't know why they keep giving me these projects. I always mess them up. I'm probably getting fired soon."

Wait. What?

This guy had shipped our entire authentication system. Built the API that powered 60% of our revenue. Mentored four engineers who now led their own teams.

I thought my architect was lazy.

Three months. Every project. Same pattern: Brilliant ideas in planning. Mediocre execution. Deadlines missed.

"Just not driven enough," I thought to myself.

Then I overheard him talking to another engineer. 🧵

How do you make sure the quietest voice in the room gets heard during a crisis?

♻️ Repost if you've seen blame culture crush good solutions

➕ Follow me (Phillip R. Kennedy @prokennedy.bsky.social ) for more stories from the engineering trenches

The best technical leaders create the conditions where the right answer can come from anyone.

They don't just manage incidents. They build the trust that makes breakthrough thinking possible.

The blame-first approach had taught him to doubt himself. Made him afraid to suggest the "obvious" thing that senior people might have missed.

That junior dev saved us hours of debugging in the wrong direction. But only because he finally found the courage to speak.

But here's what bothered me: He almost didn't share that insight.

Told me after: 'I figured if it was that obvious, someone smarter would've already seen it.'"

What happened next changed everything.

Mark, one of our junior devs, had been silent the whole meeting. Finally spoke up: "What if this isn't our code?"

He was right. Third-party CDN issue. Fixed in twenty minutes once we stopped looking at our own code.

Tech leaders during a crisis:

• Roll up sleeves and debug with the team
• Ask "What's the fastest path to resolution?"
• Shield engineers from executive pressure
• Focus on customer impact over politics
• Bring calm energy that enables thinking

• Demand explanations before solutions
• Turn post-mortems into blame sessions
• Escalate panic up the chain
• Measure who's working longest hours
• Create fear that crushes creativity

That's when I learned the difference between tech bosses and tech leaders.

Tech bosses during a crisis:

Customer complaints flooding support. Board asking for updates every hour.

His response? Emergency all-hands. Finger pointing. "Who deployed last?"

I watched our best engineers shut down. Stopped sharing ideas. Started covering their tracks instead of fixing the problem.

Black Friday. API throwing 500 errors. Revenue dropping $8K per minute.

The CTO panicked. 🧵