CEO, Highland & Haskill Creek • Founder of Classy (acq. by GoFundMe) • Founder of nonprofit, Save Farmland

Every week I tackle management, operations & startup topics that are helping 250,000+ people. Sign up free: www.scotchisholm.com

I also run a leadership accelerator that helps founders develop into top CEOs. Apply here: https://joinhighland.com/apply/

My backstory: 

🚀 Founder of Classy, SaaS for nonprofits raising billions per year

🎗️ Acquired by GoFundMe in ‘22 to create largest giving platform in the world

🌲 Investor in dozens of startups out of family fund, Tall Timbers Holding Co, (Ripple, FanDuel, Hubble, Casetext, etc.)

🏔️ Founder of Highland, leadership accelerator & community for founders

🏡 Co-founder of Haskill Creek, modernized & healthier version of a Walgreens or CVS 

⚽️ Co-owner of Albion Soccer Club, top youth soccer club in country

🧑🏼‍🌾 Founder of Save Farmland, a nonprofit protecting local farmland & food 

⚙️ Industrial engineer & lean six sigma nerd, UMass Amherst grad 

❤️ Board experience: Nature Conservancy, Abundant Montana, Team Rubicon, Street Soccer USA, Montana Pediatric Cancer Foundation

It's been a wild ride. If you're interested in any of the above, please visit my website and reach out to me there. 

www.scotchisholm.com

Scot Chisholm

Getting pushed out of my own company taught me what a CEO actually does...

In 2017, I got called to my lead investor's office in La Jolla.

I waited 30 minutes in the conference room. Then the head of the firm walked in.

"The partners aren't happy with Classy's performance. We think it's time for some change." Two missed quarters. That's all it took.

I had built the company to tens of millions through brute force. But something had gone wrong. Growth slowed. I had become the limiting factor.

I hated them for it. But they weren't wrong.

I was more builder than scaler. More brick layer than architect. It took 24 months to buy them out and get us back on track. Some of the darkest times of my life, but also the deepest reflections.

That experience lit a fire under me to understand the CEO role better than anyone they could bring in to replace me. Not to become the next Jobs or Bezos. But to answer basic questions no one could give me:

What should I be doing all day? What should I focus on? What does a CEO actually do? So I obsessed over studying the best CEOs in the world. What separates the ones who scale from the ones who plateau?

I found that every great CEO masters 7 core responsibilities. I now call them the CEO-7.

I wrote a complete breakdown in yesterday's newsletter. 

If you wanna check it out, I'll drop it in the comments.

Operator & Investor • Founder of Classy (acq. by GoFundMe) • Building Highland, Just, Haskill Creek

How defining “great” changed our culture (and decision-making):

A new hire asked me a simple question after onboarding:

“What does great look like here?”

I didn’t have a clean answer.

Not because we lacked ambition, but because we’d never clearly defined it.

Mission, vision, and values weren’t enough.

What we were missing was our perspective on excellence.

That gap pushed us to document our company standards. The non-negotiables that guide decisions when things get messy, fast, or ambiguous. Inspired by how Patagonia articulated its philosophies, we created standards that outlived leadership changes and scaled with the company. 

Here's how I defined them 👇 

***
ps. If you want to read my in-depth article I wrote on this exact topic, I'll drop the link in the comments.

How to define what great looks like:

Here's how to create an unstoppable strategy in 3 simple steps:

First, what is a strategy? Most leaders get this wrong. Strategy is not vision. Strategy is not goals. It's the bridge between the two. Strategy is your unique approach to achieve vision. It shapes your annual goals and daily execution. Vision leads to strategy, which leads to goals.

To create an unstoppable strategy, you need three things:

- Unique approach
- Measurable impact
- Target market

I call this "strategic AIM." A stupidly simple, crystal clear description of strategy that anyone can understand.

1. Approach
What's our unique approach to accomplishing the company's 3 to 5 year vision? Why will people choose us? How are we 10x better than the competition? What are 3 to 5 core bets, multi year initiatives, that we will pursue? Your unique approach creates differentiation at all levels.

2. Impact
What does success look like when we achieve our 3 to 5 year vision? How do we measure it and track along the way? Customer impact, financial impact, shareholder impact. Get crystal clear on what success looks like from day 1.

3. Market
Most leaders target anyone that will buy from them. This is the wrong approach. Instead define exactly who your target market is. Think of it like an archery target. Primary is the inner ring, secondary is the 2nd ring, tertiary is the 3rd ring. Dominate the first before prioritizing the second.

Your strategic AIM informs how you set pricing, packaging, and messaging. It also makes annual goal setting a lot easier. What are the company's top three annual priorities that advance our strategic AIM? Pay special attention to your multi year core bets. These help shape annual goals.

Revisit your strategic AIM at least annually. As your vision evolves, your strategic AIM should evolve. They're joined at the hip. You should always have a company wide strategic AIM, but you could also have one for different products or markets as you get bigger.

If you're a founder or operator and you enjoy my content, you should check out Highland Academy: https://lnkd.in/eAVA5ekz

How to create an unstoppable strategy in 3 simple steps:

In 2017 I was called to my lead investor’s office in La Jolla. 

I had no idea what the meeting was about. 

They wanted me out as CEO after nearly ten years running the company. 

I had missed two quarters and lost their confidence. 

That was enough. 

But they weren’t wrong, I wasn’t yet a great CEO. 

While they tried to push me out, I studied the role like a maniac. 

Determined to be better than anyone that could replace me. 

Ultimately, it worked and the company 5x’d in valuation. 

Now I teach everything I learned through Highland Academy. 

If you’re a founder working to become a great CEO, this is for you.

I'll drop a link in the comments if you want to apply.

Or shoot me a dm.

Don't screw up your annual company kick-off!

Most CEOs don't realize how high-stakes their company kick-off really is. They waste the moment. Why? 

Because they don’t realize how high-stakes it is. They think B- work is ok. Check the box. Get back to the “real work”. I mean, you do have lots of shit going on. Carving out a half-day for a company kick off can feel like a waste of time.

I've been on both sides of this. As a founder, I learned the hard way that the leaders who put their heads down and "get back to work" in January are making one of the costliest mistakes of the year. The annual kick-off isn't a distraction from the real work. It IS the real work.

Andy Grove called this "managerial leverage" in High Output Management. The idea is simple: what you put in is nothing compared to what you get out. A few hours of intentional effort in January can shape the behavior of your entire company for months, if not years. Skip it and you put your team at an information disadvantage you'll be fighting all year long.

The truth is, your kick-off is the highest-leverage meeting of the entire year.
Get it right and your team has the clarity to do their best work all year long. Get it wrong, and you're playing catch-up on culture and alignment for months.

I've worked with hundreds of CEOs on this. The ones who treat their kick-off like the Super Bowl moment it is? They never say die. They show up prepared, energetic, and locked in, and their teams follow suit. The ones who phone it in? They spend the rest of the year wondering why nothing is sticking.

I wrote a guide to follow in a recent newsletter. It includes the one thing your team needs from their leader going into the new year: Purpose, Direction & Progress.

link in the comments to go in depth on this topic 👍

This is where companies quietly fall apart:

Most founders inherit the CEO title before they have any idea what it actually requires. 

You start the company, you get the title. 

No one sits you down and explains what the job is supposed to look like. 

You have to be intentional about learning the role. 

It’s not the same as being a founder. 

Two very different things.

***
Learn what the role of a CEO actually looks like in my recent article (link in comments)

How to speak like the top CEOs on the planet:

Most people communicate: 
- nervousness
- indecision
- selfishness

When they should be conveying: 
- conviction
- thoughtfulness
- partnership

Not all CEOs get it either, but the best certainly do. 

Here’s how 👇 

1/ Keep it clear & simple: Avoid jargon. Use plain English. Be yourself. Don’t over-share or talk in circles. Focus on nailing one main point but never exceed three. Don’t assume understanding. Ask the person if they get it.

2/ Speak with energy: Show enthusiasm & belief in what you say. Avoid fidgeting or whispering. Makes you look nervous. Stay solution-oriented. Don’t be a negative Nancy. You’ll demotivate everyone. Use storytelling to inspire & provide tangible examples.

3/ Talk like a partner: Say “we,” not “I”. Stay relatable to every level of the organization. Create a sense of shared ownership. Ask people: “What do you think?” Take people’s feedback seriously. Even if you make the final call.

4/ Communicate the ‘why’: Tie things back to mission & vision. Always explain reasoning behind major decisions. Help people understand company's progress. Create a sense of urgency when you fall behind. Say “because” more to force yourself to provide context to the team.

5/ Control your emotions: Never let feelings override the message. Stay composed under pressure. Don’t over-share and freak everyone out. But don’t sugarcoat things either. Be realistic & communicate a plan.

6/ Ask the right questions: Don’t pretend to have every answer. Find solutions through thoughtful questions. The best CEOs see themselves as detectives. Practice ‘5 whys’ asking why five times to find root causes.

7/ Guide, don’t dictate: Be a facilitator, not a dictator. Orchestrate debate & discussion. Pre-plan exercises that get people collaborating. Keep the room on track and constructive. Shape the discussion, don’t dominate it.


📌 ps if you want me to teach you how to do this at your company, check out Highland Academy: https://lnkd.in/eAVA5ekz

📌 📌 pps. if you enjoy my content, you'll love my free newsletter. Subscribe here: https://lnkd.in/e6ak5dbP

EOS and OKRs broke at scale. 

Here’s what replaced them.

I spent over a decade building Classy from a scrappy idea into a $100M+ company that processed billions in donations before we sold to GoFundMe.

As we scaled, one problem kept surfacing:
No operating system held up past ~$5M in revenue.

We tried OKRs. The product team loved them. But across the company they became too complex. Too many objectives, too many key results, quarterly resets, confusing grading. The system meant to create focus became a recurring distraction.

We looked at EOS. It was cleaner, but too prescriptive. And I didn’t agree with the idea that the founder should hand off operations to a “professional operator.” 

My belief is simple: The CEO must own the operating system.

There was also a deeper issue.

Classy was an impact company. Our mission wasn’t a slogan on a wall. It was the reason people showed up. We needed an operating system that connected purpose all the way down to daily execution, and not just tactical documentation.

So I built one.

It’s called the Northstar OS.

📌ps. If you want to dive into the Northstar OS framework, check out this article I wrote that breaks it down: https://lnkd.in/eDeRw6D2

pps. Sign up for my free newsletter here: https://lnkd.in/gXCsenmP

"Don't worry, you're gonna do great."

I was frozen in the green room at TEDx San Diego. My body felt like 1,000 pounds. I've only been a founder for a couple of years. Why am I giving a TED talk? People are going to laugh me out of this theatre.

An old man in the corner spoke up. That nudge got my legs working again.

I gave my talk. Came back dripping sweat.

"See, I told you you'd do great. You should be proud."

Then he walked on stage to give his own talk.

⁂

Years later, an advisor sent me a book that changed everything about how I manage people.

The One Minute Manager.

I googled the author. Ken Blanchard.

His face stared back at me.

The old man from my TED talk.

Here was one of the most successful business writers of all time, about to give one of his best talks ever, and he was focused on me.

That night I wrote Ken a thank you. He responded with equal grace.

⁂

The book became required reading for every manager at my company. Here are the 3 lessons that changed how I manage people forever:

1/ Great leadership is a side-by-side relationship. Not top-down. It's a partnership. When the organization wins, the people should win. Get this right and your people start managing themselves.

2/ Catch people doing something right. Positive recognition isn't soft, it's smart. People repeat what's recognized.

3/ Correct the behavior, not the person. Address mistakes quickly and specifically. End with reaffirmation. Every 1×1 becomes an opportunity to help people stay on track.

That night, Ken was demonstrating everything he'd later teach me through his book.

True leadership is the smallest acts of support, delivered at the right moment.

Full story + breakdown here:

Open article: 3 simple rules that changed how I manage people forever: by scotchisholm.com

3 simple rules that changed how I manage people forever:

Fractional CIO & Strategic Advisor | Fixing IT Bottlenecks, Building High-Trust Tech Foundations | Scaled Orgs from $0 to $3B+

Strategic IT Leadership for Growing Companies

Helping non-technical founders and small business leaders scale without getting slowed down by their own systems

The Problem
Most companies don’t fail because they dream too small.
They fail because their technology trips them up before they ever hit full speed.

Systems that don’t talk to each other

Vendors that overpromise and underdeliver

Teams that pull in different directions

Operational chaos hidden behind "we’ll fix it later"

Growth without fundamentals isn't a shortcut—it's a detour. Real business expansion is about building systems that scale with integrity, not just adding layers of complexity to a shaky core.

The Outcome
I help you build a stronger, smarter, simpler technology foundation — one that scales with your business, not against it.

✅ Faster operations
✅ Smarter use of tools and teams
✅ Fewer expensive mistakes
✅ A clear, flexible roadmap for growth
✅ More time spent leading — less time fighting fires

My Approach
I’m not here to sell you systems you don’t need or waste months writing strategy decks nobody reads.

I’m here to help you:

Fix what’s broken (before it costs you real money)

Align your people, process, and platforms (so they work together, not against each other)

Build momentum you can actually feel (and measure in real-world results)

I bring 30 years of hands-on experience building and scaling IT in organizations that grew from to over $3B — many times as the very first IT hire, often leading global distributed teams.

What you get is simple:
Real strategy. Real execution. Real growth.

No bloat. No buzzwords. No bureaucratic nonsense.

Services
Fractional CIO Leadership
Part-time executive leadership to align your tech and business strategy, manage vendors, and build internal capabilities without hiring a full-time CIO.

Project Rescue and Turnaround
When critical projects stall, I step in to realign teams, simplify the chaos, and deliver results.

Vendor and System Sourcing
Find the right systems and partners that fit your business — not someone else’s template.

Strategic IT Roadmapping
Clear, practical roadmaps that connect today’s actions to tomorrow’s growth.

Who I Work Best With
Founders and business leaders who:

Are serious about scaling

Know tech is crucial but don’t want to live inside it

Value momentum over perfection

Want a partner who talks business, not just tech

Ready to Clear the Bottlenecks and Build What's Next?
Let's start with a simple conversation.
No sales pitch. Just clarity on where you are — and what’s possible next.

Phillip R. Kennedy

The VP forwarded the CEO's angry email to the whole engineering team at 9:47 PM on a Thursday. 

Daniel's manager replied-all at 9:48: "I'll handle this. Everyone log off."

Twelve seconds. Two completely different leaders.

The CEO's email was four sentences. A client's integration broke during a routine deployment. The client called the CEO directly. The fourth sentence: "I need to understand who is responsible."

The VP read it and clicked Forward. Added the entire engineering distribution list. Twenty-three people. Two words at the top: "See below."

No context. No plan. Just a CEO's anger, amplified to two dozen engineers on a Thursday night, most of whom had nothing to do with the deployment.

Daniel was brushing his teeth when his phone buzzed. He'd been at the company four months. He'd worked on a small piece of the integration three weeks earlier. Close enough to wonder. Close enough to lose sleep.

His shoulders went up. He started mentally composing a defense for code he'd written at 2 PM on a random Tuesday.

Then his phone buzzed again. 9:48.

"I'll handle this. Everyone log off."

Seven words. No exclamation point. No performative urgency. Just: this is not your problem tonight. It's mine.

James fixed it by 11:30. Configuration issue. Not a code defect. Nobody on the team caused it.

The next morning, James emailed his team: "Issue resolved. Config problem. Nothing any of you shipped caused this. If last night's email stressed you out, that's worth a conversation. My door's open."

Daniel saved that message. Not because it was eloquent. Because it was the first time a manager acknowledged that an internal communication could cause harm, and took ownership of it.

The VP forwarded blame at the speed of a click. James absorbed it in twelve seconds.

Same crisis. Same night. Two completely different engineering cultures.

Your team already knows which one you are.

♻️ Repost if you've had a manager whose first instinct was to protect the team, not forward the pressure 

➕ Follow me (Phillip R. Kennedy) for more on engineering leadership that absorbs the hit instead of passing it down

Fractional CIO & Strategic Advisor | Helping Non-Technical Leaders Make Technical Decisions | Scaled Orgs from $0 to $3B+

I used to think I was bad at engineering.

Took me three years to realize I was just good at internalizing bad management.

My first engineering manager reviewed code like he was grading exams. Red comments everywhere. "Why did you do it this way?" But not curious why. Accusatory why. The kind that makes you defend instead of learn.

Every standup felt like a status trial. What did you ship? Why isn't it done? When will it be done?

I started questioning my own ideas before sharing them. Too risky. Easier to ask what he wanted and build that. Stopped proposing architectural improvements. Stopped pushing back on impossible timelines. Stopped believing I had anything worth saying.

Thought that was just how engineering worked.

Then he left. New manager. Different universe.

First one-on-one, I came with my list of status updates. Tasks completed. Tasks in progress. Velocity metrics. The whole performance.

She looked at me like I'd handed her a restaurant menu when she asked how I was doing.

"I don't need a status report," she said. "Jira exists. I need to know what's actually hard right now."

I didn't know how to answer. Nobody had asked.

She waited. Didn't fill the silence. Didn't check her phone. Just waited.

Eventually I told her about a problem I'd been stuck on for two weeks. 

She didn't give me the answer. Asked questions instead.

"What breaks first when this scales?"

"What are you actually solving for?"

"What would you try if you couldn't fail?"

Forty-five minutes later, I had three approaches I hadn't considered. Because she made space for me to think out loud without performing competence.

That was many years ago. I still use those questions with my own team.
Here's what I've learned since:

Your engineering manager doesn't just shape your output. They shape whether you believe you belong here.

The bad ones drain you so slowly you don't notice. Every code review feels like judgment. 

You start wondering if you're cut out for this. Never occurs to you that the environment is the problem.

The good ones do something different. They fight battles you never see. Block the scope creep before it reaches your sprint. Push back on the VP who wants it faster. Take the heat so you can take the time.

They notice signals before you break. The moment "just ship it" becomes your answer to everything.

They believe in your potential louder than your imposter syndrome believes in your inadequacy. Through the questions they ask. Through the problems they trust you with. 

Same engineer. Same skills. Same codebase.

One manager made me doubt my own ideas.

The next made me believe I could lead a team.

The code we write gets deprecated. Refactored. Eventually replaced.

How your manager made you feel while writing it?

That stays forever.

♻️ Repost and comment if you've had both kinds

➕ Follow me (Phillip R. Kennedy) for more on leadership that builds engineers, not just software

The best engineer on the team hadn't shipped a single feature she was proud of in fourteen months.

Elena used to prototype solutions on Saturday mornings because the problems were interesting. She'd sketch architecture diagrams on napkins at lunch. Her tech lead at her previous company once told her she thought about systems the way musicians think about melody. Patterns inside patterns.

Then she got a new engineering manager.

Code reviews became public dissections. Not "walk me through your thinking." More like "why would you do it this way?" with the emphasis on would. Every bug was a verdict. Every missed estimate was evidence. He once rejected a PR with seven comments, all variations of "this isn't how we do things here," without once explaining how they did things there.

So Elena adapted. She stopped proposing better architectures. Stopped questioning requirements that didn't make sense. She started building exactly what was specified, even when she knew it was wrong, because "wrong but approved" was safer than "right but challenged."

Fourteen months of that.

When she transferred teams, her new manager pulled up her first PR and said five words: "Walk me through your thinking here."
Elena froze. She'd been so conditioned to defend that she forgot what it felt like to be asked to explain.

So she explained. Tentatively. Waiting for the critique. It didn't come. Instead: "That's a clever approach to the caching layer. Have you considered extending it to handle the edge case on write-back?"

A real technical conversation. Not a performance review disguised as collaboration.

Three months later, Elena was leading the design review for their highest-priority feature. Six months after that, two junior engineers asked to be on her projects because, as one of them put it, "I actually learn things."

She didn't become a different engineer when she switched teams. She just stopped flinching.

That's what bad management does to good people. It doesn't reduce their talent. It teaches them to hide it. And the worst part is how invisible the damage looks from the outside. The code still ships. The standups still happen. The sprint velocity looks fine on a dashboard.

But the napkin sketches stop. The Saturday prototypes stop. The interesting questions stop.

And nobody notices until she's gone.

♻️ Repost if you've watched a great engineer go quiet under the wrong manager 

➕ Follow me (Phillip R. Kennedy) for more on building engineering cultures where talent stays visible

I've spent 30 years watching what great technical leaders actually do.

Almost none of it looks like leadership on paper.

18 things I've seen the best ones do:

1. Say "I don't know" out loud so the team learns it's safe to say it too.

2. Kill a meeting to protect four hours of uninterrupted build time.

3. Put a junior engineer on the project everyone said she wasn't ready for. Then quietly clear the path.

4. Sit in the architecture review and ask the quiet person in the back what they think. Then actually wait for the answer.

5. Walk into a budget meeting and make technical debt visible to executives who only see features shipped.

6. Recognize the engineer who prevented the outage. Not just the one who fixed it.

7. Take the call from the angry stakeholder so the team can keep building.

8. Fight for an infrastructure investment that won't show results for six months. Then fight again when someone tries to cut it in Q3.

9. Tell their best engineer "you should interview for that role" before she'd ever considered leaving the team.

10. Share their own worst production mistake in a retro. Watch the room exhale.

11. Push for a promotion before the engineer asks. Then build the case so well it's undeniable.

12. Translate a forty-five minute technical explanation into two sentences a CFO can act on. Without losing what matters.

13. Block the fourth "urgent" request in two weeks. "Urgent" is not a strategy.

14. Pair a twenty-year veteran with a six-month hire. Tell both of them they're going to learn something.

15. Turn "this is broken" into "what would good look like?" Same facts. Completely different energy.

16. Advocate for sustainable pace when everyone above them is performing urgency.

17. Create space for exploration that might not ship anything. Then defend it when someone asks for the ROI.

18. Remember that the job was never to be the smartest person in the room. It was to make the room smarter.

None of this shows up on a dashboard. Most of it never gets recognized in a performance review.

But the engineers remember. And they become leaders who do the same things.

That's how you scale more than systems.

♻️ Repost if you've had a leader who did one of these and it changed your trajectory 

➕ Follow me (Phillip R. Kennedy) for more on technical leadership that builds people, not just products

He texted me eighteen months after leaving the company. 7:32 AM on a Tuesday. "Congrats on the promotion. You earned it."

He had zero organizational reason to care.

James had been my CTO for three years. Left to start his own company. Most former bosses disappear when the org chart changes. Within a month, the relationship becomes a LinkedIn connection you scroll past.

James never did that.

When I got stuck on an architecture decision after he'd gone, I almost didn't reach out. He replied in twenty minutes: "Coffee Thursday?" Asked three questions that reframed the problem. No lecture. No "remember who helped you" energy.

When a product manager kept changing requirements mid-sprint, James said something I still use: "Your job isn't to stop the changes. It's to make the cost visible to the people requesting them."

When I left for a startup, most of leadership went quiet. That silence tells you which relationships were real. James responded in an hour: "Exactly the right move. Need references?"

The promotion text came a year later. His own company, across the country. My career had zero impact on his.

I've had many managers. Most competent and forgettable. James is the only one whose influence outlasted his badge access.

He never managed from the org chart. The authority was incidental to the relationship. When the authority left, the relationship didn't.

Most leaders aren't this way. Not because they're bad people. Because organizations reward transactional leadership. When someone leaves, the incentive to stay connected disappears.

Leaders who stay were always outside that system. They invested in the person, not the role.

The test that matters more than any review: would people who used to work for you still take your call? Not because you can help them. Because it was never about that.

♻️ Repost if you've had a leader whose influence outlasted their title

➕ Follow me (Phillip R. Kennedy) for more on leadership that survives the org chart

She said she was "doing fine" and "learning a lot." Two weeks later she put in her notice.

I'd asked all the right questions. How are you settling in? Anything blocking you?

Surface-level questions get surface-level answers. And surface-level answers hide problems until they become resignation letters.

That exit taught me first 1:1s aren't introductions. They're the moment you earn honest communication or guarantee you'll never get it.

Most leaders fill that meeting with org charts and project updates. Nobody gets uncomfortable. Nobody learns anything.

After thirty years, here's what actually surfaces truth:

"Walk me through the last time you dug into someone else's code." Tells you more about team culture in three minutes than any survey. Listen for colleagues who help vs. territory that's guarded.

"What's the most frustrating part of getting your work done here?" Not "any concerns?" That gets "everything's great." Ask what frustrates them, then sit in the silence. The pause tells you whether honesty feels safe.

"When you disagree with a technical decision, how does that play out?" If the answer is "I don't usually disagree," that's not harmony. That's someone who learned speaking up costs more than staying quiet.

"If a friend asked whether they should join this team, what would you honestly tell them?" People rarely lie when it's framed as advice to someone they care about.

"How do you know when you've done good work here?" If they can't answer, your org hasn't made it clear.

You don't need ten questions. You need three honest ones and the discipline to stop talking after you ask them.

The engineers who answer carefully are often your best performers trying not to get fired for saying what's broken. The ones who say "everything's great" in week one say it again in their exit interview.

♻️ Repost if you've learned more from one honest answer than a dozen safe ones

➕ Follow me (Phillip R. Kennedy) for more on leading teams with better questions

He'd been the fastest developer on the team for nine years. Last quarter, a mid-level with half his experience outshipped him three to one.

She wasn't a better coder. She'd quietly changed what her job was.

Rachel started using AI agents the way a good manager uses a team: delegate predictable work, provide context, review output, redirect when something drifts. Agents handled integrations, test coverage, docs. She focused on architecture and judgment calls between what agents produced and what the system needed.

Still an IC on the org chart. Her daily work looked like management.

David coded line by line. Nine years of it. Genuinely good. He'd see no IDE on her screen and assume she was slacking.

Then sprint reviews told a different story.

Rachel shipped three features in a cycle where David closed four tickets. Not because she was smarter. Because she'd changed the ratio between thinking and typing.

His response is one I hear constantly: "That's not real engineering."

I get it. If you built craft through your hands for a decade, watching someone achieve more by orchestrating feels like a violation. Not just a career concern. An identity one.

But stripped of hype, here's what's happening.

The IC role is shifting from production to orchestration. From writing every line to directing, reviewing, and integrating work AI produces. The skills this demands aren't new. They're management skills. Providing context. Reviewing with judgment. Knowing when to intervene. Maintaining quality when production outpaces review.

Every engineer is becoming a manager. Not of people. Of systems that produce at a pace no human can.

The IC track isn't dying. It's evolving. More judgment. More context. Less typing. More thinking.

For engineers willing to make that shift, it's the best version of the job they've had.

♻️ Repost if your role is quietly shifting from building to orchestrating

➕ Follow me (Phillip R. Kennedy) for more on the real AI shift in technical work

Her exit interview was two sentences.

"I'm not leaving for more money. I'm leaving for better sleep."

I didn't understand. She was one of our best. Shipped constantly. Dashboard had her as a top performer.

I asked what she meant.

Six months earlier, we'd approved a shortcut to hit a deadline. She flagged the risk. We shipped anyway. Executive pressure. Customer commitment. The usual.

That shortcut woke her up at 3 AM eleven times since.

Eleven times. Pager screaming. Heart racing. Logging in from bed to fix something she told us would break.

"Every time my phone buzzes at night, my body thinks production is down. Even when it's just a text from my mom."

I sat there realizing I had no idea.

Our velocity looked great. Our metrics looked healthy. None of that captured a nervous system that couldn't tell the difference between a text and an outage.

The technical debt wasn't in the codebase.

It was on her shoulders.

Every shortcut we approved. Every "we'll fix it later" that didn't get fixed. She carried the weight while we celebrated the velocity.

That gap between leadership dashboards and engineer nervous systems? That's where good people quietly disappear.

I called her after she left. New job. Smaller company.

"How is it?"

"I slept through the night last week. Whole night. Didn't check my phone once."

She said it like she was describing a vacation.

Your best engineers aren't leaving for better titles.

They're leaving for nervous systems that work again.

You won't see it on a dashboard.

You'll see it in the resignation letter.

By then it's too late.

♻️ Repost and comment if you've ever left a job to get your sleep back 

➕ Follow me (Phillip R. Kennedy) for more on leadership that remembers software is written by humans

She accepted an offer for 15% more. Her manager started a counteroffer. I told him to stop.

The money wasn't the problem. He just didn't know what the problem was.

Days before notice, her fix prevented a major outage. Week before, her refactoring cut response times in half. Her architecture decisions saved thousands in cloud costs monthly.

Her manager knew none of this. Not because he didn't care. Because he was a non-technical founder at a $12M company and nobody taught him what to look for.

He saw tickets closed. Features shipped. Through that lens, every engineer looked the same.

She didn't feel underpaid. She felt invisible.

This is the pattern I see most in growing companies. The founder is sharp. Competent in their domain. But they evaluate engineering like a restaurant kitchen: if food comes out, everything's fine.

The engineer preventing outages looks identical to one doing unremarkable work. Both close tickets. The difference is invisible unless you know what great engineering looks like.

That's not a character flaw. It's a knowledge gap. And it's expensive.

After she left, I told him: you don't need to understand code. You need three sentences.

"I heard your fix Tuesday prevented a customer issue. Tell me about it." Engineers know instantly if recognition is genuine. Specificity is the difference.

"What technical work happened this month I'd never see in a sprint review?" This teaches you what's invisible.

"What should I understand better about what engineering does?" Most leaders won't ask. Feels vulnerable. That's why it works.

The counteroffer would've cost $30K. She'd have stayed six months and left anyway. Her best work looked the same as average to the person signing her check.

Engineers don't leave for better offers. They leave when no one can tell the difference.

♻️ Repost if you've seen an engineer leave because leadership couldn't see it

➕ Follow me (Phillip R. Kennedy) for helping non-technical leaders keep great engineers

He told the CEO he was 60% sure. The CEO said, "That's 20% more than I had when I started this company. Go."

Daniel had been circling a platform decision for three weeks. Two viable paths. Trade-offs he could model, risks he couldn't. The data said "maybe" in fourteen different ways.

He kept requesting more analysis. Another benchmark. One more comparison. His director finally said, "You're not gathering information. You're avoiding a decision."

She was right.

Daniel could architect systems most people couldn't diagram on a whiteboard. The problem was never capability.

He'd confused certainty with competence.

He believed good leaders decide because they know the answer. So when he didn't know, he assumed he wasn't ready. More data. More time. The team stalled.

The CEO's response broke something open. Every founder who's built something real knows certainty almost never arrives on time.

Daniel made the call Thursday. "Here's what we're doing, here's why, and here's what I'm not sure about. We'll learn the rest by building."

Six months later, two of his assumptions were wrong. The team had adapted. What he'd agonized over mattered less than the momentum of actually moving.

This pattern lives everywhere. The leader who won't commit until every variable is known. The founder polishing the deck instead of making the call. The executive requesting another quarter of data before approving a hire they know they need.

It looks like diligence. Past a certain point, it's avoidance in a professional costume.

Courage doesn't follow confidence. It's the other way around.

Daniel told me a year later: "I used to think my job was to have the answer. Now I think it's to make the call and help the team navigate what we find on the other side."

That's not a technology insight. That's a leadership one.

♻️ Repost if you've made the right call on incomplete data and didn't know it until later 

➕ Follow me (Phillip R. Kennedy) for more on leading through uncertainty

We've all made the "perfect résumé" hire. Strong credentials. Nailed the technical interview. Three months in, you realize they can solve any problem except the ones that actually matter.

I've hired hundreds of people over thirty years. The pattern that predicts success has almost nothing to do with algorithms or credentials.

It's curiosity. How someone behaves when they hit a problem they don't know how to solve.

One of my best hires had two years of experience and a community college degree. Struggled in the technical round. But when conversation shifted to a real problem we were facing, he asked diagnostic questions that showed he'd operated systems under real pressure. Not textbook answers. Thinking from the weeds.

A year later, three teams called him first when something broke. Not the fastest coder. The one people trusted to think before acting.

What I've learned about what actually predicts success:

Give candidates a real problem, not a puzzle. Walk them through a challenge your team faces. Twenty minutes of real conversation beats an hour of whiteboard performance.

Watch what happens when they don't know. The best say "I haven't seen this, but here's how I'd start." People who bluff in interviews bluff on your team.

Listen to what they ask about. The system, the users, the team? Or just the stack, the title, the comp?

Look for ownership instinct. Ask about a project that went sideways. People worth hiring talk about what they learned. Not who was at fault.

Create unstructured time. Thirty open minutes surface what no template will.

You can teach your tech stack in months. You can't teach someone to care about the problem behind the ticket.

The résumé says where someone's been. The conversation tells you who they are. Most hiring processes only measure the first.

♻️ Repost if your best hire looked nothing like you expected on paper

➕ Follow me (Phillip R. Kennedy) for more on building teams that scale on trust

The infrastructure held.

The people broke instead. 

We'd doubled the team in six months. New features every sprint. Dashboards green across the board. Leadership loved the metrics.

Then an outage hit and I watched it all unravel.

Frontend blamed backend for the API timeout. Backend pointed at data inconsistencies. Data said the pipeline was fine, just "unusual load patterns." DevOps insisted monitoring showed everything healthy.

Four teams. Four different realities. Four hours of pointing fingers at each other while customers waited.

The same engineers who pair-programmed together last quarter couldn't agree on basic facts. People I'd hired specifically for collaboration turned into territorial strangers defending their corner of the codebase.

We'd added all the right scaffolding. Stand-ups. Retros. Cross-team syncs. Slack channels for everything. The visible architecture of communication.

None of it mattered.

Because somewhere in the growth, understanding had quietly died.

Frontend assumed backend cached everything. They didn't.

Backend assumed frontend handled edge cases. It couldn't.

Data built pipelines for clean inputs that never existed in production.

Everyone was building against assumptions about teams they used to sit next to. Used to eat lunch with. Used to actually know.

We'd scaled the org chart. Hired fast. Shipped fast. Celebrated the velocity.

Nobody noticed we'd stopped scaling the understanding.

The gaps don't announce themselves. They hide in the space between what teams think they know about each other and what's actually true. You don't see them in dashboards or stand-ups or sprint reviews.

You see them at 2 AM when four teams are on a call and nobody can agree on what's broken.

The outage lasted six hours.

The trust issues lasted months.

Every team became a little more defensive. A little more protective of their territory. A little quicker to document their side of the story before something went wrong.

We didn't fix it with more meetings. We fixed it by admitting what we'd lost.

Started with engineers shadowing other teams. Not training sessions. Just watching each other work. Understanding how decisions actually got made instead of how we assumed they got made.

Took almost a year to rebuild what we'd broken in six months of growth.

Scale fast enough and you'll outrun your own foundation.

The cracks don't show up in metrics.

They show up when everything's on fire and your team can't even agree on what's burning.

♻️ Repost and comment if you've watched a scaling team fracture under pressure

➕ Follow me (Phillip R. Kennedy) for more on building teams that scale together instead of apart

"You'll own the ERP migration."

I looked around the conference table. Waited for her to finish the sentence. Hand it to someone senior. Add a caveat.

She didn't.

Seven-figure budget. Every department watching. Implementation timeline the board had already announced to investors.

I'd been there eleven months. Three directors had more experience. Two had done migrations before. I'd done exactly none.

She picked me anyway.

I didn't sleep that night. Ran every failure scenario I could imagine. Wondered if she'd made a mistake. Wondered if I should tell her she'd made a mistake.

The migration took fourteen months. Came in under budget. Hit every milestone except one, which we recovered in a week.

But that's not the story.

The story is what happened after.

Every technical recommendation I made carried more weight. Not because the migration was flawless. It wasn't. We had problems. Made mistakes. Recovered from most of them ugly.

It carried weight because someone had vouched for me when vouching was expensive.

She spent political capital on an eleven-month employee for a board-visible project. If I'd failed, that was her failure too. She knew that. Did it anyway.

I asked her about it years later. Why me?

"The senior people would've done fine," she said. "You needed to find out what you were capable of. That only happens when someone lets you try."

I think about that conversation constantly now.

Because I see the opposite everywhere. Engineers who can do the work. Nobody letting them prove it. Senior enough to lead. Never quite trusted to lead. Waiting for permission that keeps not arriving.

They don't leave because the work is hard. They leave because the waiting is harder.

The junior engineer who's ready for production access but policy says six more months. The architect who could own the cloud migration but leadership wants someone "proven." The senior dev who sees exactly what's broken but nobody's asked her to fix it.

They're not missing skills. They're missing someone willing to spend the capital.

Trust isn't a reward for being ready. It's how people become ready.

The CIO who picked me for that migration? I've tried to repay that debt for twenty years. Not to her. To every engineer I've managed since.

Someone trusted me before I'd earned it.

That's the only reason I was around to earn it.

♻️ Repost if someone believed in you before you believed in yourself

➕ Follow me (Phillip R. Kennedy) for more on leadership that takes the expensive risk

They spent eight months building an AI recommendation engine. Beautiful machine learning. Garbage recommendations.

Their product catalog had 847 duplicate entries and descriptions from 2020.

The AI did exactly what it was designed to do. Found patterns and served them confidently. Customers got recommended discontinued products, duplicates of things in their cart, accessories for items no longer sold. Confident wrong answers at machine speed.

This company isn't unusual. They're the norm.

The pattern is becoming too common. The CEO hears AI is table stakes. The board wants a strategy. So leadership announces an initiative while their systems run on spreadsheets, manual uploads, and that one person who reconciles the data every Friday.

Customer records in seventeen tools. Support tickets referencing orders that don't exist in the main database. Three definitions of "active customer" depending on which dashboard you open.

Then they layer AI on top and wonder why it doesn't work.

AI doesn't fix broken systems. It scales them. Wrong answers with perfect grammar. Three versions of truth delivered faster than ever.

The most effective AI deployment I saw last year was boring. Nine months of cleanup before writing a single prompt. Data consolidated. Duplicates resolved. Systems connected. One source of truth.

No press release. When they turned on AI, it just worked. Not because the technology was special. Because it had something sane to work with.

Before you spend another dollar on AI: would a new employee be confused by your current systems? If yes, so will the AI. Just faster and more expensively.

The companies quietly winning aren't the ones with the biggest AI budgets. They're the ones who did the boring work first.

♻️ Repost if you've watched AI get layered on a foundation that couldn't support a spreadsheet

➕ Follow me (Phillip R. Kennedy) for technology decisions that actually work

taplio

The Battle

Scot Chisholm

Phillip R. Kennedy

Followers

Posts

Engagements

Likes

Performance ScoreScot Chisholm's LinkedIn Performance

Performance ScorePhillip R. Kennedy's LinkedIn Performance

Ready to grow your LinkedIn presence?

taplio

The Battle

Scot Chisholm

Phillip R. Kennedy

Followers

Posts

Engagements

Likes

Performance Score.css-goub6s{font-size:var(--chakra-fontSizes-md);font-weight:500;color:var(--chakra-colors-gray-600);display:block;margin-top:var(--chakra-space-1);}Scot Chisholm's LinkedIn Performance

Performance ScorePhillip R. Kennedy's LinkedIn Performance

Ready to grow your LinkedIn presence?

Performance ScoreScot Chisholm's LinkedIn Performance