Kennēsys

• Fractional CIO/Technology Consulting
	• Strategic Planning
	• Technology Roadmaps
	• Systems Sourcing
	• AI / BI / ML practical applications
	
Recent projects:

	• Helped wholesale distributor add 2 points of margin through strategic vendor analysis 
	• Rightsized 2 year long failed CRM project through strategic roadmap creation
	• Accelerated development team formation and delivery for SaaS system provider
	• CIO and strategic advisory services for startups and decades old family businesses

Founder

Classic Brands, LLC

Classic Brands is a designer, manufacturer, and wholesale distributor of mattresses, bedding accessories, and furniture.  Headquartered in Columbia, Maryland.

Member of the Executive Leadership Team, reporting to the CEO

• First internal IT employee recruited by the CEO to transform aging internal systems and setup organization for growth.
• Successfully managed a ransomware incident within the first 2 months in the role.
• Learned the business, existing systems, developed an IT strategy, roadmap, and plan for execution within the first 60 days.
• Led the evaluation, selection, and implementation of the following systems:
     - Supply Chain planning solution – Adexa S&OP and S&OE
     - Transportation management solution - Minisoft with planned transition to Blue Yonder
     - EDI solution. Including migrating existing trading partners along with adding 12 new partners during migration process – True Commerce
     - ERP solution. AP, AR, accounting, supply chain, order processing, procurement, manufacturing – Microsoft D365 F&O
     - Treasury management solution to aid in AP/AR processing, bank reconciliation, and collections – SK Global Software
• Led the tech and security areas for a new 425k sq/ft warehouse including Wifi design, security, building access, AV and conferencing setups.
• Led project to implement Azure technologies and integrate with existing AWS environment. Completed full migration to Azure.
• Led advanced analytics, BI project utilizing Azure Advanced Analytics, Databricks, and PowerBI
• Built internal IT team to focus on plan/build/run setup. Implemented iterative, DevOps way of working to perform multiple production releases to all systems weekly when needed.
• Managed the custom development of a warehouse management system with real time integration into Microsoft D365 Finance and Operations ERP system utilizing AWS and Azure technologies including Service Bus and D365 Business Events.  WMS technology sold to National 3PL organization.

Vice President of Information & Technology

Pandora Jewelry

Global Head of Application Development, member of Enterprise Architecture board, and Global IT Management Team. 

Tasked with leading PANDORA's global transition to an Agile organization.

Responsible for all B2B and B2C application development and delivery. 

Led key initiative establishing PANDORA Agile, iterative way of working for all internal and external development teams.  Managed a global team of 16 internal resources with 40-60 contractors.

Head of Agile Development, Global IT

Capabilities lead for all IT application workstreams.  Managed a global team of 45 with 9 direct reports.

Work pillars included applications development, supply chain, master data management, integrations, and enterprise architecture.

Director, Information Technology, Global IT

Recruited by the CEO as the first internal IT employee in the Americas to establish a high-performing technical organization capable of managing hyper-scaled growth.

Responsible for all aspects of IT in the Americas. Led all technical initiatives to support the growth from $80MM to $1B while keeping IT spending under 0.4% of regional revenue with a 98+ internal satisfaction rating.

Built an internal team of 26 with another 20-40 contractors.

Key projects included:
	• ERP migration
	• Custom built cloud-based B2B retailer portal
	• B2B CRM/xRM sourcing, implementation, and custom development
	• B2C single consumer view solution
	• Sell-through data collection, and analytics program 
	• Co-op advertising processing solution
	• BI analytics and data warehousing
	• Cyber security management and incident recovery
	• Warehouse management- WMS system sourcing and implementation
	• POS sourcing and implementation
	• Agile iterative way of working

Head of Information Technology, Americas

HubKey, LLC

Co-Founded HubKey, LLC in 2006 with a software development team. HubKey is a provider of outsourced Business to Business e-commerce solutions. Primarily focused on outsourced EDI document translation and ERP system integrations.

Chief Technologist & Co-Founder | 2007 – 2010
• Developed and wrote the five-year business plan
• Successfully located and acquired investors needed to initially fund the company
• Setup internal processes and equipment, including all accounting systems, expense tracking, servers, and software
• Responsible for the primary technology direction of the company and managing product development
• Responsible for securing clients and managing sales and marketing activities

Co-Founder / Chief Technologist

Gross, Mendelsohn & Associates, P.A.

GMA is a full-service CPA and consulting firm founded in Baltimore in 1960. Named one of the top 200 CPA firms in the US for the past seven years. Technology consulting practice is led by CPAs and focused on business and software systems, along with networking solutions and infrastructure.

Systems Consultant | 2008 – 2009
Major Responsibilities and Contributions:
• Led CRM practice, including internal implementation of the Dynamics CRM solution at GMA
• Responsible for application development, database development, and business systems consulting for regional client base
• Responsible for infrastructure, unified communication, and network consulting

Systems Consultant

GrandNetworks, LLC

Founded GrandNetworks, LLC in 2003 with two business partners, to provide experienced technology direction and support to businesses in and around Jackson Hole. Handled all the technology needs for 12 business clients in the area. responsible for all day to day duties
including procuring clients. Performed all accounting duties. Managed phone support and resource scheduling.

Chief Technologist & Co-Founder | 2003 – 2007
• Researched, recommended, and implemented paperless medical practice office utilizing tablet pc, electronic medical records, and voice recognition software
• Performed client/server migration to HIPAA-compliant software package for 20- node office
• Completed multiple Microsoft Small Business Server setups
• Developed contact management system for hedge fund company utilizing Microsoft technologies
• Developed expense tracking software application for Pocket PC using Visual Studio.Net
• Researched and planned development of an e-commerce software application to integrate with most major small- to medium- sized business management software packages utilizing XML, InfoPath forms, BizTalk Server and AJAX

Prestige Brands, Inc.

Prestige Brands, Inc. is a 350M+ public company with operations based in Jackson, Wyoming, and sales and marketing offices in Irvington, New York. Prestige is a marketer and distributor of over-the-counter drugs, household cleaning supplies, and health and beauty aids. Responsible for developing, communicating, and executing the corporate technology strategy. Primary focus is to keep costs and operation staff to a minimum through strategic application of technology, while designing, developing, and maintaining nimble systems capable of easily integrating with brand or company acquisitions.

Information Technology Manager | 1999 – 2006
• Guided the technology direction to compensate for exponential growth from a $60M company to $350M in 6 years, while adding only 4 additional operations staff
• Develop and manage IT budget
• Successfully headed numerous company acquisitions, including one that more than doubled total revenue
• Successfully headed multiple 3rd party warehouse conversions
• Handled internal corporate restructuring projects
• Implemented automated order and invoice processing system
• Automated day end and month end closing processes
• Planned and executed ERP software migration from DOS to Windows-based system
• Headed technology team to secure Sarbanes-Oxley compliance
• Headed team to develop and implement custom marketing and sales forecasting application
• Developed contract management tracking solution
• Developed custom advertising planning and tracking solution
• Developed sales and distribution reporting solution
• Responsible for incorporating all data history from each acquisition
• Implemented service management and support desk solution and processes
• Planned and executed software migration from Pervasive to MS SQL server along with ERP upgrade

IT Manager

Life-Link International

EDI Manager / Systems Administrator

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.

A VP of Engineering told me a few months ago: "I'm thinking about quitting leadership and going back to being a senior engineer."

Fifteen years of experience. Ready to walk away.

Not because he was failing. Because he couldn't see himself succeeding anymore.

Here's what he said:

"Every day is fixing what's broken. Mediating conflicts. Explaining delays to executives. Watching my team struggle. I don't remember the last time I felt good about what I'm building."

I asked him: "What went right this week?"

Long pause. "I... don't know. Nothing major. The usual fires."

"Okay, what small thing worked?"

Another pause. "Jennifer caught a security flaw in code review before it hit production. Saved us from what could've been a nightmare."

"Did you tell her?"

"No. It's her job."

That's the trap.

Tech leadership without gratitude isn't just exhausting. It's invisible progress wrapped in constant crisis.

You're solving complex problems. Managing people solving complex problems. Every win gets buried under the next fire.

Here's what changed for him:

I gave him one practice: Every Friday, document three moments that almost went unnoticed but mattered.

Week 1:
Junior dev caught logic flaw that would've broken invoicing
Team shipped hotfix in 20 minutes (used to take 2 hours)

Week 2:
Engineers pushed back on impossible timeline. He backed them. Project got realistic scope.
2 AM production incident—three timezones collaborated, fixed it fast, nobody panicked
Customer emailed: "Your API change saved us hours of manual work daily"

Week 3:
He texted me: "I'm not quitting. I was measuring the wrong things."

The shift:

He stopped counting problems solved. Started counting capabilities built.

Gratitude isn't forced positivity. It's recognizing what's working before burnout blinds you to it.

Three practices that kept him from walking away:

- Catch micro-wins in real time. Screenshot that Slack thread where your team solved something impossible. Save the customer email. Take a photo of the whiteboard after a breakthrough.

You'll need proof that progress is happening during weeks when everything feels broken.

- Tell people when you feel it, not when you schedule it. Don't wait for quarterly reviews. 

Someone saves the deployment? Tell them now. 

Peer covers your meeting during an outage? Acknowledge it immediately.

Gratitude expires. Don't let it spoil in your head.

- Turn complaints into capability gaps worth solving.

Tech leadership without this becomes a grind that burns out good leaders and fragments good teams.

With it? You stay clear-headed enough to see what's working while fixing what isn't.

That VP? Still leading. Team growing. Hasn't mentioned quitting again.

Not because the fires stopped. Because he can finally see the progress between them.

♻️ Share this post if it reminded you of something worth appreciating

➕ Follow me (Phillip R. Kennedy) for more on succeeding in tech leadership without losing yourself in the process.

Phillip R. Kennedy

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

I watched a VP of Engineering clean out his office last month.

Twenty-three years. Three platform migrations. Built a 40-person team from nothing.

Gone in a "restructuring."

Packing up awards and family photos, he kept saying: "I don't know who I am without this place."

Here's what hit me.

Nobody took his knowledge.
Nobody erased his network.
Nobody deleted the systems he built that still run today.

But he couldn't see any of that. Because his identity was the badge. The title. The corner office.

This is the trap.

We introduce ourselves by where we work, not what we've learned.

"I'm the CTO at..." instead of "I solve scaling problems."
"I run engineering for..." instead of "I build teams that ship."

Your job is temporary. Your growth isn't.

Three weeks later, I got a text from him.

"Just closed a consulting deal. $45K for three months. They found me because someone I mentored five years ago recommended me."

Not because of his title. Because of the problems he'd solved and the people he'd helped.

That's the shift:

Stop building a career around a company. Start building capabilities around problems you can solve anywhere.

1) Document your wins with numbers - "Improved performance" means nothing. "Reduced API response time from 2.3s to 400ms, preventing 15% user churn" tells a story.

2) Build relationships outside your walls - The best opportunities come from people who've seen you in action, not algorithms matching keywords.

3) Teach what you know - Every talk you give, every junior dev you mentor, every blog post you write builds your reputation beyond any single company.

4) Focus on patterns, not just fixes - Anyone can patch a bug. Leaders spot the root cause and prevent it from happening to three other teams.

5) Learn the language of business - The CTOs who survive disruption can translate "our Redis cluster is maxed out" into "we're losing $50K monthly in abandoned transactions."

Your current role will end someday. That's not pessimistic, it's just true.

The question is: when it does, will you know who you are without it?

What skills have you developed that would make you valuable at any company?

♻️ Repost and comment if you liked this

➕ Follow me (Phillip R. Kennedy) for more insights on building tech leadership that outlasts any org chart.

Security Verification | LinkedIn

JSESSIONID

Introducing the Gravity Aging Hypothesis | Deepinder Goyal | 575 comments

li_at

Talks about #tech, #scaling, #leadership, #teamculture, and #waysofworking

Vaughan Moore

I watched the best CTO I knew lose three senior engineers in six months.

Not because he was bad at technology. Because he was too good at it.

Here's what happened:

Production outage. Database corruption. Critical customer data at risk.

His senior engineer was on it. Diagnosing the issue. Ten minutes from a solution.

The CTO couldn't help himself. Jumped in. Took over. Fixed it in five minutes.

Everyone celebrated the quick save.

Except the senior engineer. Who quit two weeks later.

Exit interview: "I can't grow when you solve every hard problem before I get the chance."

That's when I learned:

Being the smartest person in the room is a liability when you're supposed to be leading it.

The difference between expertise and leadership:

Expertise says: "I can fix this faster."
Leadership says: "How do I help you fix this?"

Expertise hoards the hard problems.
Leadership distributes them strategically.

Expertise creates hero moments.
Leadership builds capable teams.

The shift:

Stop proving you're still technical. Start proving you can make others technical.

That CTO? Still brilliant. Still codes circles around everyone.

Now leads a team of two. Because the best people left to work for someone who'd let them grow.

Your technical expertise got you the job. But it becomes your ceiling if you can't let go.

What's one technical problem you solved that you should've let someone else own?

♻️ Repost and comment if you liked this

➕ Follow me (Phillip R. Kennedy) for more on leading tech teams without becoming their bottleneck.

Three junior engineers asked me the same question recently: "Should I be worried AI is going to take my job?"

The panic in their voices wasn't about technology.

It was about the hype machine.

Here's what I told them, and what every tech leader needs to hear:

AI is genuinely powerful. It's also dangerously overhyped.

The gap between promise and reality is crushing teams.

The reality gap:

Your marketing team wants AI to "personalize all customer communications."

Reality: You spent three months building a system that still requires human review for every email because it keeps getting the tone wrong.

Your CEO read that AI will boost developer productivity by 40%.

Reality: Your team is debugging hallucinated code suggestions and spending more time reviewing AI output than writing from scratch.

Your board expects AI ROI in Q2.

Reality: You're still cleaning data from 2019 that the models need to actually work.

How to cut through the noise:

Start with pain, not technology.

Which manual process is crushing your team's time? Where are humans doing repetitive work that machines could handle?

Not: "Let's add AI to our product."
But: "Our support team spends 15 hours weekly answering the same 20 questions. Could AI actually handle that?"

Run quiet experiments first.

Spend two weeks testing if AI can improve your code review process. Measure it. Document what works and what doesn't.

Then, only then, announce it to the board.

Measure business impact, not AI adoption.

"We use GPT-5" means nothing.

"AI reduced our documentation time by 30% while improving quality" means everything.

Budget for reality.

AI projects take 3x longer than initial estimates because integration is always harder than the demo.

The nuanced truth:

AI excels at specific, bounded tasks. Code completion. Document generation. Data analysis. It genuinely helps here.

But it fails at strategy, complex reasoning, and anything requiring deep business context that only your team understands.

Your job isn't to dismiss AI or chase every breakthrough.

It's to evaluate tools based on real business problems and team capacity.

The best tech leaders I know are quietly using AI where it works and ignoring the hype everywhere else.

Six months from now:

Half the "AI-first" companies will be quietly removing features that never worked.

The leaders who succeeded will be the ones who asked: "Does this actually solve a problem worth solving?"

Not: "Are we doing enough AI?"

What AI pressure are you getting from leadership right now?

♻️ Repost and comment if this hit close to home

➕Follow me (Phillip R. Kennedy) for more on leading through tech hype without losing your team's trust.

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.

"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.

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.

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:

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.

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?"

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 this to inspire braver leadership
➕ Follow (Phillip R. Kennedy) for more insights on building high-impact teams

A CEO once asked me: "How do you stay so confident when you don't know the answer?"

I'd just told him "I have no idea if this migration will work."

He looked confused. "Then why are you recommending it?"

Here's what I learned about confidence:

It's not knowing the answer. It's knowing you can find it.

Think of leadership confidence like jazz improvisation. The best players don't memorize every note. They trust their ability to respond to whatever the other musicians play.

Bad leaders treat uncertainty like a secret to hide.

They memorize buzzwords. Study frameworks. Pretend they understand every technical detail their team mentions.

Then freeze when something breaks that isn't in the playbook.

Great leaders treat uncertainty like terrain to navigate.

They don't pretend to know the route. They just trust they can read the map.

The shift:

Stop trying to be the expert on everything. Start being the person who knows how to make progress with incomplete information.

What that actually looks like:

You say "I don't know, but here's how we find out" instead of nodding along pretending you understand.

You ship decisions with 60% of the data instead of overthinking for two weeks when it's too late.

You ask "Does this solve the customer problem?" before "Is this technically elegant?"

You tell your team "I was wrong about the approach" instead of quietly pivoting and hoping nobody notices.

The uncomfortable truth:

Your team already knows you don't have all the answers.

Pretending you do doesn't build confidence. It shatters trust.

Real confidence is this:

Production crashes at 2 AM. Your team is looking at you.

And your lack of panic is not because you know all the answers.

You're calm because you trust yourself to figure out what matters, assemble the right people, and make the call that moves everyone forward.

That's the confidence that builds careers. And teams that follow you into problems nobody's solved before.

What's one time you gained respect by admitting you didn't know something?

♻️ Repost and comment if you liked this

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

I quit. 

Two different managers.

Same conversation. Two different reactions.

One ruined the relationship forever. One made it stronger.

Manager A (let's call them Steve):

"I've accepted another role."

Five seconds of silence.

"After everything we invested in you?"

He stopped including me in meetings. Stopped responding to messages. My last day, two-line email: "Thanks. Good luck."

That was 8 years ago. Haven't heard from him since.

Manager B (let's call them Patty):

"I've accepted another role."

"Tell me about it."

She asked good questions. Then: "This sounds right for you. How can I help?"

She made introductions. Wrote my LinkedIn recommendation without asking. Made my transition smooth.

Last day, lunch: "Stay in touch."

Years later:

Steve? I cross the street at conferences.

Patty? First call when I need advice. Three referrals sent her way. When she needed help, I cleared my calendar.

Here's the thing:

How you handle someone leaving tells them everything about whether you saw them as a human or a resource.

Steve treated departure as betrayal.

Patty treated it as transition.

The math:

Steve protected his ego for two weeks. Lost a relationship that could've compounded for decades.

Patty invested two weeks in a graceful exit. Gained an advocate, referrals, and ongoing collaboration.

Same person. Same situation. Different choice.

The cost of treating departure like betrayal:

You burn a relationship that could've compounded for decades over ego protection that lasts two weeks.

Steve lost:

- Any chance I'd refer candidates to him
- Any future collaboration opportunities
- My willingness to be a reference for him
- Access to my network

Patty gained:

- Three senior engineer referrals
- Ongoing advisory relationship
- Someone who promotes her leadership publicly
- Access to my clients when it makes sense

What I learned:

People leave. Average tenure is 2-3 years. That's not betrayal. That's reality.

The question isn't whether they'll leave.

It's whether they'll want to stay connected when they do.

Your reputation as a leader isn't built on who you hire.

It's built on who still calls you after they leave.

Steve chose ego. Patty chose compound interest.

I know which one I want to be.

Which manager have you experienced?

♻️ Repost and comment if this reminded you of a leader who supported your growth

➕ Follow me (Phillip R. Kennedy) for more on building relationships that outlast any role.

I had a great engineer quit with two weeks' notice.

Exit interview: "I've been struggling for three months. You never asked."

I thought I was managing well. Checking sprint progress. Reviewing code. Clearing blockers.

What I missed: He'd been submitting PRs at 2 AM for six weeks. Stopped asking questions in standups. His code reviews went from thoughtful to "LGTM."

I saw all of it. Just didn't see what it meant.

Here's what I got wrong:

I tracked the work. Not the person doing it.

His velocity looked fine. Features shipped. Dashboard green.

So, I assumed he was fine too.

He wasn't.

A senior dev had trashed his code in a public review. Called it "junior mistakes." He'd been working nights trying to prove he belonged.

Three months of that. I never noticed.

The cost:

- Lost a strong engineer who would've become a tech lead.
- Lost credibility with the team who watched him burn out.
- Lost the right to say "we care about people" without sounding like bs.

What changed how I lead:

Stopped asking "How's the sprint?" Started asking "How are you actually doing?"

Different question. Different answer.

The signals I now watch for:

Work happening at weird hours. Not deadlines. Just... happening.

Contributors going quiet.

"I'm fine" delivered too fast.

Code quality consistent while everything else deteriorates.

The shift:

Your job isn't maximizing output. It's noticing when someone's drowning before their metrics drop.

Because by the time dashboards show problems, you've already lost them.

What actually works:

Notice patterns before asking. "You've been committing at 2 AM for two weeks. What's going on?"

Reserve 1:1s for conversation. Status updates belong in Slack.

Block unrealistic timelines before they hit your team.

Say this: "Your value isn't measured in story points or a tally of your lines of code."

The truth most leaders miss:

Empathy isn't soft. It's pattern recognition applied to humans.

You notice when deployments degrade. Notice when people do too.

Six months later, I saw him at a conference.

He's thriving. Tech lead now. Building something he cares about.

He was gracious. Said it wasn't personal.

But here's what he didn't say: I failed him. Not as a manager. As a human who should've noticed.

That changed how I lead. Forever.

What signal are you missing right now?

♻️ Repost and comment if this hits home

➕ Follow me (Phillip R. Kennedy) for more on building teams that perform without breaking people

A CEO asked me: "How do we keep our remaining teams loyal after the layoffs?"

I stared at him.

"You just cut 10% of their friends to hit quarterly numbers. And now you want loyalty?"

Here's the math:

Trust is earned in drops. Lost in buckets.

You can't unring that bell. But you can be the reason people stay anyway.

What happened next:

I walked into our team meeting the next day.

No corporate speak. No "this was necessary for the business."

And said: "I know you're scared. I know you're angry. I know you're updating your LinkedIn. I get it."

Then: "Here's what I can control. And what I can't."

What we couldn't control:

- The company's decision
- The budget cuts
- The uncertainty

What we could control:

- Defending the team from the next round of cuts
- Being honest about business reality without creating panic
- Seeing them as humans, not headcount

Six months later:

The team? Fully intact. Other departments lost more of their people to voluntary attrition.

Same company. Same uncertainty. Different leader.

Here's what most leaders miss:

Acknowledge the grind, not just the wins. Call out the 2 AM production fix. The boring migration nobody celebrated. Make people feel seen for their struggle, not just their output.

Shut down the rumor mill fast. When someone asks "Are we next?" don't deflect. Be honest and explain the reality of the situation and business needs. Crush the panic before it spreads.

Tell the truth. "Revenue dropped 20%, budgets are tight" beats "everything's fine" when people can read the company Slack. Adults handle truth. They can't handle being lied to.

Actually manage workload. Push back on impossible timelines. Stop projects that would burn people out. Your flexible schedule doesn't mean your team has unlimited capacity.

Fund their growth even when it meant losing them. Conference approvals. Certifications. LinkedIn introductions. People stay longer with leaders who invest in their future, even if that future isn't here.

Remember they're humans. Kids with soccer games. Parents in hospitals. Life outside of their email. The leader who says "family first" and means it builds loyalty that survives stock drops.

The shift:

Your company might not deserve their loyalty.

But you can be the reason they stay anyway.

In a world where people are line items on spreadsheets, being the leader who sees them as humans isn't just good management.

It's how you win.

What's one way you kept your team together when everything was falling apart?

♻️ Repost and comment if this hit home

➕ Follow me (Phillip R. Kennedy) for more on leading through the chaos without losing your people.

Being easy to work with costs nothing.

But it's the difference between being seen as a technical resource and trusted as a strategic partner.

I watched a technically brilliant CTO get passed over for a board seat. Not because he couldn't architect systems. Because nobody wanted to sit in meetings with him.

Here's what actually separates leaders people want to work with:

They explain complexity without condescension.

"The API integration is complex because we're bridging legacy data formats" not "This is way above your pay grade."

They give options, not ultimatums.

"We can ship fast with technical debt or take two weeks to build it sustainable. Here's the tradeoff" beats "This will take six months, no discussion."

They admit when they're wrong.

"I underestimated the database migration complexity" instead of quietly moving goalposts every week.

They translate business needs into technical solutions, not force technical solutions onto business problems.

They show up prepared to listen, not just defend their team's capacity.

Think of it like system design:

You can build the most elegant architecture in the world. But if it's not accessible and maintainable, nobody wants to use it.

Same with leadership.

The upside of being easy to work with:

You get invited to strategic conversations before decisions lock in. The CEO asks for your input on acquisitions. Your budget requests get approved faster. The board sees you as business-critical, not just technically necessary.

The cost of being difficult:

You get excluded from planning sessions. Your team gets blamed for delays. You're seen as a bottleneck, not an enabler. Your technical expertise becomes irrelevant because people avoid working with you.

The brutal truth:

Your code doesn't attend board meetings. You do.

Your architecture doesn't negotiate with vendors. You do.

Your systems don't build relationships. You do.

People don't just hire technical skills. They choose leaders they want to partner with for the next three years of growth, challenges, and impossible deadlines.

Being easy to work with isn't about being a pushover. It's about being someone others can build with.

What's one thing that makes a tech leader easier to work with?

♻️ Repost and comment if you liked this

➕ Follow me (Phillip R. Kennedy) for more on leading without becoming the obstacle.

All hands meeting. CEO mid-presentation. Forty slides deep.

"Our customer retention is at 94%."

From the back of the room, barely audible: "Actually... it's 83%."

Everyone turned. It was Matthew. Three weeks into their internship.

You could hear the room stop breathing.

The CEO paused. Looked at him. "Show me."

He pulled up his laptop. Walked through the data. They'd been using last quarter's numbers.

CEO said five words that changed everything:

"You're right. Thank you, Matthew."

Then to the room: "This is exactly what we need more of."

Matthew's now a full-time analyst.

Not because he was the smartest person in the room.

Because he had the guts to be honest when it mattered.

Here's what that moment taught me:

Skills get you hired. Courage keeps you valuable.

Your team already knows what's broken. They may just be afraid to say it out loud.

Build a culture where the intern can correct the CEO. That's how you stay competitive.

What's the bravest thing someone on your team has done recently?

♻️ Repost and comment if you found this valuable
➕ Follow me (Phillip R. Kennedy) for more stories about building teams.

A former colleague texted me last week: "Remember when I turned down that role three years ago because I didn't feel ready?"

I did remember. VP position. Startup scaling fast. 20% pay bump. She said no because her current company felt "safe."

"Just accepted a similar role. Same level. Same pay. Except now I'm three years older with the same skills I had then."

That's the real cost of comfort.

Not what you lose by taking the risk. What you lose by not taking it.

Here's what staying comfortable actually costs you:

- The confidence you could've built by figuring things out.
- The skills you would've developed by being slightly in over your head.
- The network you would've grown by working with people ahead of you.
- The salary growth that compounds when you make moves at the right time.

Three years later, she got the same opportunity. But the gap between who she was and who she could've been was now visible. Measurable. Painful.

The shift:

Growth doesn't wait for you to feel ready. It rewards people who move before they're comfortable.

Think about it: Every skill you have now came from doing something you weren't qualified for yet.

- Your first leadership role? You weren't ready.
- Your first big project? You figured it out.
- Your current position? You grew into it.

But here's what happens when you stay too long:

You stop growing and start defending. Defending your current skills. Your current role. Your current comfort zone.

The people who passed you? They didn't wait to feel ready. They just moved.

What the best professionals know:

Growth beats comfort. Every time.

Not because growth is easy. Because comfort has an expiration date in a world that's changing this fast.

- Your skills aren't getting better by staying still. They're getting obsolete.

- Your confidence isn't building by playing safe. It's eroding.

- Your career isn't strengthening by staying loyal to one place. It's calcifying.

The brutal truth:

The role you're "not ready for" today becomes the role you're "overqualified for" tomorrow, if someone else takes it and grows into it while you wait.

Three years from now, you'll either look back and think "I'm glad I stayed" or "I wish I'd left sooner."

Very few people regret taking the growth opportunity. Most regret waiting for permission that never comes.

Here's the question that matters:

Are you staying because you're still growing? Or because leaving feels uncomfortable?

One builds your future. The other protects your ego.

What opportunity are you waiting to feel "ready" for?

♻️ Repost and comment if this hit close to home

➕ Follow me (Phillip R. Kennedy) for more on choosing growth over comfort.

I spent three weeks preparing a technical deep-dive for the board.

Seventy-three slides. Performance benchmarks. Architecture diagrams. ROI models.

Rehearsed it twelve times.

Got through slide four before the CEO stopped me.

"Phillip, I don't care about the tech stack. I care about our customers. Are they happy or not?"

I froze. I'd spent three weeks preparing for the wrong conversation.

Here's the scariest thing about tech leadership:

Your biggest failures won't come from bad code. They'll come from being brilliant at the wrong thing.

I see this all too often. Engineers who can debug distributed systems in their sleep but can't explain why it matters to the person signing the checks.

The skills that actually got me promoted had little to do with technology:

→ Learning to speak three languages fluently: Engineer. Executive. Customer.

Same problem. Different translations:

- To engineers: "Our API response time averages 2.3 seconds with p99 at 4.1 seconds"
- To executives: "Customers are abandoning carts because checkout feels broken"
- To customers: "We're making checkout faster so you spend less time waiting"

→ Building trust with finance people who think all engineers are expensive wizards

→ Making decisions with 60% of the information and being okay with it

→ Saying no to the CEO's pet project without getting fired

→ Leading through a massive platform failure without losing the team

Want to know what's truly frightening?

Most tech leaders spend more time optimizing their IDE than their communication skills.

Then wonder why they're stuck explaining technical debt to people who fell asleep at "microservices."

Your technical certifications expire. Frameworks change. Platforms evolve.

But the ability to translate technical complexity into clarity for non-technical humans will compound forever.

The CTOs and VPs I know didn't get there by being the best coders. They got there by being the best translators.

Your most important project isn't the platform migration.

It's becoming someone who can talk to all levels of the organization and make the tech problems simple enough that the right people can weigh in on the right decisions for the right reasons.

Because brilliant solutions die in translation every single day.

And the person who can explain "microservices" to your CFO in a way that makes them say "oh, now I get it"? That person is irreplaceable.

Happy Halloween. The real horror story is being technically right and professionally ignored. 🎃

What's one technical concept you learned to explain in plain English that changed how people saw you?

♻️ Repost and comment if you liked this
➕ Follow me (Phillip R. Kennedy) for more on becoming the translator your organization desperately needs.

I quit because of a Tuesday morning meeting.

Not the job. The manager.

Here's what happened:

Our product launch failed. Crashed fifteen minutes after going live. 50,000 users hit an error page. Support tickets flooding in.

My team worked 72 hours straight to fix it. We got it back up. Identified the root cause. Built safeguards so it couldn't happen again.

Tuesday morning, leadership meeting. My manager presenting.

"We experienced a significant technical failure due to inadequate testing by the development team."

He didn't mention the impossible timeline he'd promised the board. Or the corners he told us to cut. Or the warnings we'd given him two weeks prior.

He threw us under the bus in front of the entire executive team.

I handed in my notice that afternoon.

Six months later, I joined a different company. Same role. Similar pressure.

We launched a major feature. Also crashed. Also chaos.

But my new CTO sent one message to the leadership team:

"We had a rough launch. My team is working on it. I take full responsibility for not building in enough buffer time. Updates to follow."

Then privately to us: "What do you need from me right now?"

Same crisis. Opposite leadership.

One manager used his team as a shield. The other used himself as one.

Here's what that taught me:

Your boss doesn't just manage your work. 
They manage your dignity.

Great leaders absorb pressure from above and radiate clarity below.
Toxic leaders do the reverse, absorb credit, radiate blame.

The difference shows up in three moments:

→ When things break: Do they ask "what happened?" or "whose fault?"
→ When leadership asks questions: Do they say "we" or "they"?
→ When success happens: Do they share the spotlight or stand in it?

I've worked with dozens of tech teams. The difference between thriving and surviving isn't the technology.

It's whether their leader protects them or uses them.

The team with the bad manager? Three people quit within six months.
The team with the good one? Same people, three years later, still shipping.

Your technical skills matter. But your boss determines whether you get to use them or burn out trying.

What's one thing a leader did (or didn't do) that made you want to stay or leave?

♻️ Repost and comment if you found this valuable

➕ Follow me Phillip R. Kennedy for more insights on building tech teams people don't want to escape.

Two leaders. Same deadline. Same pressure.

Leader A: Eight weeks of planning meetings. Still no progress.

Leader B: Shipped week one. Messy, imperfect, working.

Six months later:

Leader A: Gone.

Leader B: Running a 20-person team.

Here's the difference:

High performers don't wait for perfect clarity. They build while figuring it out.

What separates them:

They start before they're ready.

They decide with 60% of the information.

They ship messy over waiting for perfect.

They turn complaints into business cases: "This takes 45 minutes" becomes "we're losing $$$ daily."

They own gaps: "I need to learn this" not "my team can't do this."

The brutal truth:

Analysis paralysis looks like diligence. It's actually fear wearing a professional mask.

Your career doesn't reward perfect preparation.

It rewards decisive action.

Leader A waited for permission. Leader B asked for forgiveness.

One strategy builds careers. The other ends them.

What did you start before you felt ready?

Follow me (Phillip R. Kennedy) for more on leading without waiting.

I watched a senior architect panic when our CTO said "We're moving off React."

This guy had spent five years mastering React. Spoke at conferences about it. Built his entire reputation on it.

"My skills are obsolete now," he told me.

Here's what I told him:

"React isn't your skill. Problem-solving is your skill. React was just the tool."

Three months into the new stack, he was leading the migration. Not because he learned the framework fastest. Because he understood system design, team dynamics, and what actually mattered to the business.

That's technical capital.

Not the framework you know. The judgment you've built.

What compounds:

→ Making decisions with 60% of the information (frameworks change, ambiguity doesn't)
→ Translating "our database is slow" into "we're losing $40K monthly in abandoned carts"
→ Staying calm when production is on fire and everyone's looking at you
→ Knowing which problems to solve now vs which to defer
→ Leading teams through change without losing them

What expires:

- The specific syntax. 
- The hot framework. 
- The buzzword on your resume.

Here's the shift:

Junior engineers stress about learning the next framework.

Senior leaders invest in judgment that transcends the framework.

Your technical skills get you hired. Your technical judgment keeps you indispensable.

The React architect? Now mentoring teams on system thinking. The framework changed. His value didn't.

What's one technical judgment call you made that had nothing to do with code?

♻️ Repost and comment if you found this valuable
➕ Follow me (Phillip R. Kennedy) for more insights on building tech leadership that outlasts the hype cycle.

Your $400K platform upgrade has been “85% complete” for nine months.

Everyone’s exhausted. The vendor’s confused. Your team stopped showing up to status meetings.

Sound familiar?

I’ve seen this 30+ times.

You don’t have a technology problem, you have an alignment problem.

Projects start strong, then lose direction because:

→ Business goals shifted, but requirements didn’t
→ Three departments have three definitions of “done”
→ Nobody remembers why this matters anymore

The fix isn’t pushing harder.

It’s pausing smarter.

Bring every stakeholder back and ask three questions:

1️⃣ What business outcome are we actually solving for?
2️⃣ What can we cut that doesn’t serve that outcome?
3️⃣ Who owns success when this ships?

I watched a client rescue an 18-month ERP disaster in 90 days, not by adding resources, but by removing everything that didn’t serve the core goal.

Your stalled project isn’t broken.
It’s just pointed in the wrong direction.

Run this 3-question audit before you spend another dollar.

The hardest part about realignment?

Getting stakeholders to admit the original goal has changed.

Once you name it, everything else gets easier.

What's been your biggest 'aha' moment when salvaging a stalled project?

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

My friend Eric turned down a conference speaking slot.

Not because he was busy. Because he "wasn't expert enough."

Here's what happened:

Conference organizer emails him: "We want you to speak about scaling customer success teams. You went from 5 to 50 people in 18 months. That's what our audience needs."

Eric's brain: "There are people with way more experience than me. I'll look like a fraud."

The organizer: "We're not looking for the person with the most experience. We're looking for someone who just did this and can share what actually worked."

He turned it down anyway.

Six months later, he's watching someone else give a similar talk. Using the strategies Eric had figured out. Getting applause for the same insights Eric learned having done the work.

That's when he realized: Imposter syndrome doesn't protect you from failure. It protects you from success.

Here's what I've learned about getting past the fear of judgment:

It's not actually about other people judging you.
It's about you judging yourself. And projecting it onto everyone else.

→ The "2-Year Rule": If you're two years ahead of someone on a topic, you're expert enough to help them. Stop comparing yourself to people 20 years ahead. That's not your audience anyway.

→ The "Scared = Ready" Signal: The opportunities that terrify you are usually the ones you're most prepared for. Comfortable means you're not growing. You're repeating.

→ The "Bad First Draft" Permission: Your first attempt at anything won't be your best. But it will be better than the perfect version you never start. Done beats perfect. Every single time.

Eric eventually spoke at a different conference.

Stumbled twice. Forgot a slide transition. Sweated through his shirt.

Solid round of applause. Three people told him it changed how they approach team scaling.

The breakthrough wasn't confidence. It was doing it scared.

Your imposter syndrome is lying about two things:

- You're not ready. (You probably are.)
- People are judging you harshly. (They're mostly rooting for you.)

What opportunity are you talking yourself out of because you don't feel "expert enough"?

♻️ Repost and comment if you liked this

➕ Follow me (Phillip R. Kennedy) for more insights on breaking through the barriers that hold tech leaders back.

Six kids. One baseball. Pure chaos.

I'm watching my son's 6-and-under game when a grounder rolls into the infield.

All six kids abandon their positions and sprint toward the ball like it's the only thing that matters.

They pile on. Someone emerges triumphant, holding the ball high.

Problem? Nobody's covering any base. The runner could walk home, grab a snack, and still be safe.

The kids don't care. They're laughing.

Later, my son strikes out on five swings. His reaction? Beams and jogs to the dugout. Happy to hang out with his friends.

The score? Nobody's tracking it. Outs don't matter. The outcome is irrelevant.

Here's what hit me:

These kids naturally understand something most executives have completely forgotten.

They're optimizing for the right thing.

- Not the outcome. The experience.
- Not the metrics. The moment.
- Not performance. Presence.

Now contrast that with how most companies operate:

Everyone chasing the same metric. Piling on the quarterly goal. Obsessing over the scoreboard while ignoring whether anyone's actually covering the bases that matter.

The pattern:

We optimize for metrics that are easy to measure. We forget to optimize for things that actually matter, like whether people are engaged, learning, or finding meaning in the work.

The shift:

Those six-year-olds aren't ignoring the game. They're just playing a different one.

They're optimizing for: Am I having fun? Am I with people I like? Am I fully in this moment?

What if your team did the same?

Not ignoring outcomes. But asking: Are we optimizing for metrics or for meaning?

Three things the kids taught me about leadership:

1. Presence compounds. 

My kid who struck out? He's building connection with his teammates. 

Your team hitting their sprint velocity? That's output. It doesn't compound into loyalty or innovation unless people care about what they're building.

2. When everyone chases the same goal, nobody's covering the important work.

Six kids on one ball. Zero kids covering bases.

Ask: What critical work isn't getting done because everyone's chasing the visible goal?

3. Joy in the process is a competitive advantage.

Teams that enjoy the work outperform teams grinding through it, not because they're slacking, but because they're present, creative, and resilient when things get hard.

The question:

What are you optimizing for?

Metrics everyone can see? Or meaning that actually sustains people?

Both matter. But if you only measure one, you're abandoning the bases that win the game.

Those six-year-olds? They'll learn to keep score eventually.

But I hope they never forget: The joy is in showing up fully, not in what the scoreboard says.

What's one metric your team obsesses over that might be making you miss what actually matters?

♻️ Repost and comment if you liked this

➕ Follow me for more on leading teams that perform AND want to be there.

taplio

Phillip R. Kennedy's Linkedin Analytics

Phillip R. Kennedy

Performance ScorePhillip R. Kennedy's LinkedIn Performance

Phillip R. Kennedy's Best Posts (last 30 days)

Ready to grow your LinkedIn presence?

taplio

.css-6ytdur{background-image:linear-gradient(284deg, rgba(39, 43, 72, 1) 0%, rgba(33, 47, 183, 1) 100%);color:transparent;-webkit-background-clip:text;background-clip:text;}Phillip R. Kennedy's Linkedin Analytics

Phillip R. Kennedy

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);}Phillip R. Kennedy's LinkedIn Performance

Phillip R. Kennedy's Best Posts .css-1emoo84{font-size:var(--chakra-fontSizes-md);font-weight:400;color:var(--chakra-colors-gray-600);}(last 30 days)

Ready to grow your LinkedIn presence?

Phillip R. Kennedy's Linkedin Analytics

Performance ScorePhillip R. Kennedy's LinkedIn Performance

Phillip R. Kennedy's Best Posts (last 30 days)