Ways to Boost Morale During Long Tech Projects

Morale doesn’t collapse. It erodes. You don’t wake up to mutiny. You wake up to silence. No chatter in standup. No questions in training. No banter in Slack. Just reps going through the motions...quiet, compliant, and clocking out mentally by 2pm. This is what mid-quarter rot looks like. The deals aren’t dead. The team isn’t checked out. But something’s.....off. The engine is still running, but it’s out of torque. And lots of managers respond the only way they’ve been taught: - “Trust the process.” - “Pick up the phone.” - “Back to basics.” The problem there is that morale is much more of a momentum problem than a motivation problem. If you want to reset the team mid-quarter, stop yelling louder, and maybe just try to change the frequency a bit. Some ideas: 1. Take the emotional temperature. Before you fix the system, check the weather. Ask: - “What’s starting to feel pointless?” - “Where are we wasting time?” - “What do you wish we’d change...even if it’s minor?” You’re not looking for therapy, but you are trying to find friction. Morale doesn’t tank when things get hard, but it DOES tank when effort stops translating into progress. 2. Zoom in on the sparks. Forget the scoreboard. Find the bright spots. - One reply. - One call that turned into a thread. - One CMO who said, “Not now...but this is interesting.” Then break it down like game tape: - What channel? - What message? - What timing? Show the team there’s still signal in the system if they know where to look. 3. Change the scoreboard. “Meetings booked” works when reps are winning. When they’re not, it becomes a weekly reminder that they suck. So change the metric. - Conversations started. - Positive replies. - New contacts added to flows. Give them a scoreboard they can control. Not as a crutch, mind you. As a catalyst. 4. Inject constraint-based creativity. Monotony is the silent killer of sales teams. If every day looks the same, morale flatlines. So throw in constraints: - “Book a meeting using only LinkedIn voice notes” - “Re-pitch the same prospect in 10 words or less” - “Send a follow-up without a CTA” Why? You’re reminding reps that creativity matters. 5. Get in the trench. No one follows a manager who’s only seen the battle from a dashboard. So jump in. - Co-write an email. - Jump on a cold call. - Build a flow live on screen. When reps see you sweating with them, they start believing again. You don’t fix a mid-quarter slump with Slack gifs and a Starbucks card. You fix it by restoring a sense of cause and effect. Effort -> Feedback -> Progress. It's really, really not the grind that burns people out. They burn out when the grind feels meaningless. Inject meaning. Show movement. And make it fun again...even if just for a day. That’s how you turn a ghost-town sales floor back into a team.

If you’re not hitting pause, you’re failing your team. Momentum doesn’t come from endless forward motion. It comes from taking a breath, looking around, and saying, “Damn, we did that. Even when a project doesn't go so well...pause, celebrate, recalibrate... Here’s the play: 1. Call Out The Wins Be specific to one person at a time. Make eye contact. They need to know you saw them. “Your creativity turned this around when we hit the wall.” “You carried the emotional load no one saw but everyone felt.” “You kept us moving when things got messy.” 2. Mentor This is your shot to coach. To build. To lead. “The strength I see in you is…” “You’ve grown in ways that make this team better. Here’s how…” “One encouragement I have for you is…” 3. Make It a Moment Stop rushing. Hold space. Let the team soak in what they’ve done. “What’s one lesson you’ll carry forward?” “How has this project changed you?” 4. Set the vision for what’s next. But only after you’ve taken the time to recognize what got you here. Celebration isn’t fluff. It’s fuel. If you skip it, you’re leaving your team running on empty. Pull up a chair. Because a team that feels seen will run through walls for you.

Steal my Christmas Comms Strategy 🎄 (For Tech Teams who don’t want their programme to disappear into the mulled wine) Most tech programmes coast into December assuming “everyone’s too busy to care”. I'll be honest - That’s usually only half true. People are busy... but they’re also craving clarity, predictability and simplicity before the break. The gap between those two truths is exactly where smart comms can win. Here’s the strategy I use (and you’re welcome to steal): 1. Don’t go quiet in December. Teams often shut down their narrative in December, which creates anxiety and rumours. Instead, tighten your message: one priority, one status line, one action. Shorter comms land better when attention spans shrink. 2. Make usefulness your north star. Festive fluff is tempting but pointless. People actually don't love it, unless it includes a half day off, a pint or gift voucher. People want to know: a) What’s happening now b) What’s paused c) What’s coming up in January 3. Create a “Holiday Survival Pack” for your programme. This is where most programmes secretly fall over. Document the essentials in one place: ⤹ Key contacts (and who’s actually around) ⤹ Change freezes / release windows (add them as invites) ⤹ What to do if something breaks ⤹ The 5 FAQs you know you’ll get at 4:55pm HINT: Call it a “Survival Pack” and people actually read it. 4. Tell people explicitly what NOT to do. We like to fill voids with assumptions. Eliminate them. Examples being: “No environment changes will be made between X + Y.” or “Do not send requests to inbox X during the break... it won’t be monitored.” 5. Use the calm of early January deliberately. Most teams squander the first two weeks back. Use the lower meeting load to re-anchor people: ✦ Share a crisp “You’re back! So, here’s where we are” update. ✦ Re-state priorities ✦ Re-surface decisions made pre-break (because people forget 40% of them) This is where you regain momentum that others lose. 6. Pre-schedule content so your programme feels stable even when you’re offline. You don’t need to spam, but you do need continuity. A few well-timed nudges across the break create the sense of a programme that’s in control, not asleep. All good? If you want a comms strategy that actually works over Christmas, stop thinking in terms of “festive campaigns” and start thinking in terms of reducing the mental load. And don't be putting snowflakes on the PowerPoint template. 🤮 Feel free to steal, adapt, remix, or pretend you thought of all this yourself. 🎁 You're welcome.

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.

In a duration of 1 year, the productivity of my team (of mostly new engineers) had shot up more than 2x as measured by code throughput at various percentiles (median, 95th percentile) - meaning that 'every engineer wrote more than twice the code that year than the previous one', so this was more than a statistical aberration. Guess what? This did not have anything to do with engineers slacking off the previous year. There were systemic roadblocks that we had to address to let these individuals deliver to their potential. We hired some of the strongest people of their experience levels in the country and if things weren't optimal, something is surely wrong? A few things we did: a) fix project-to-person mapping: Identify spurious projects that individuals were mapped to, without consideration to their skill set or level of experience with ambiguous projects. Move individuals to the right projects. This involved painful cuts and shutting down of projects as well. b) fix project-to-TL mapping: Map every individual and project to a local technical lead who can give low level day-to-day technical direction. New engineers need solid technical support and low level guidance/oversight. c) minimize spread and churn for TLs and managers: Some senior people were spread way too thin across too many tech stacks without being able to gain enough expertise on any. d) fix organization design based on tech stacks: Multiple overlapping managers owning overlapping tech stack components each adding less value for the team. We did a large scale overhaul of team structures. e) better calibrated and direct growth/performance feedback: We dived into each project, mapped every individual's trajectory and gave them specific pertinent growth feedback. f) avoid project churn: Many of the new engineers were constantly shuffled from one project to the next, often across disparate stacks. Each stack had its own steep learning curve. Just when someone started getting productive in a stack, their project changed. Ensuring longer term mapping to certain projects allowed people to acquire enough momentum. These changes turned around a lot of what happened. Unsurprisingly, we found the majority of the engineers to be hungrier and aspiring for impact naturally. Most of them got promoted in the next year and we had a happier more energized team with substantially improved morale as well. Throughout this time, I had access to sensitive code contribution data, but I was acutely aware of the nuances it takes to interpret it with care. Unfortunately, it is only too easy to quickly jump to perceptions about individuals in question looking at code stats. I have seen strong teams shy away from such data, since more often than not, they get misinterpreted. When your org's productivity is low, fix your org. Not the people in your lowest rung. In my experience, I have witnessed great success by positively inspiring the right hires to be their best. Treat the disease. Not the symptom.

❌ Pizza won't motivate your developers. ❌ Beers won't motivate your developers. ❌ Unlimited snacks won't motivate your developers. ❌ Ping-pong tables won't motivate your developers. ❌ Fancy office spaces won't motivate your developers. Yet companies spend thousands on these things every year. And then wonder why their best engineers quietly quit. A great developer doesn't stay at a company because of free snacks. They stay because the work feels worth doing. So what actually motivates developers? 🎯 𝗔𝘂𝘁𝗼𝗻𝗼𝗺𝘆 → Let them make real decisions. → Stop micromanaging them. → Developers do their best work when they own what they build. 📈 𝗚𝗿𝗼𝘄𝘁𝗵 → Give them time to learn new things. → Let them use new tech in their projects. → Sponsor courses, books, conferences. → People stay where they feel like they're getting better. 💡 𝗣𝘂𝗿𝗽𝗼𝘀𝗲 → Show them why their work matters. → Connect their code to the real people it helps. → Nobody wants to spend years building something that feels pointless. When developers understand the impact of their work, they care more about the quality of it. 🤝 𝗧𝗿𝘂𝘀𝘁 → Stop tracking every hour. → Stop demanding daily status updates. → When you trust people, they want to do a great job. Trust is the foundation of a high-performing team. 🛠️ 𝗠𝗼𝗱𝗲𝗿𝗻 𝗧𝗼𝗼𝗹𝘀 → Give them fast machines and up-to-date software. → AI tools like GitHub Copilot or Claude remove friction. → Slow tools don't just waste time — they frustrate people every single day. 📌 Instead: → Remove micromanagement → Remove everything that slows them down → Focus on developer experience The goal is to build an environment that doesn't actively demotivate them. If your developers have no autonomy, no growth, and no trust, a pizza party won't make them stay. But when the foundation is solid? Perks amplify motivation that's already there. A team that feels trusted, challenged, and purposeful will genuinely enjoy the team dinner. Fix the environment first. Motivation will follow. Then the perks will actually mean something. What's the one thing that demotivated you the most at work? —— ♻️ Repost to help others build better developer teams ➕ Follow me ( Anton Martyniuk ) to improve your .NET and Architecture Skills

9 things I learned about motivating engineering teams & keeping morale high By making consistent mistakes over the last decade as a Principal Engineer Manager. 0. Protect focus time like production data. 1. Ask for input early; silence kills ownership. 2. Your mood sets the weather; show calm, earn calm. 3. Celebrate small wins; they stack into big momentum. 4. Feedback loses value if you delay it longer than a sprint. 5. Public praise, private course-correction, every single time. 6. Clarity beats charisma, explain why before you explain how. 7. Constraints inspire creativity; micromanagement smothers it. 8. Burnout isn’t a badge; enforce PTO the way you enforce code reviews. Still learning. Still iterating. But these ten keep my teams shipping, smiling, and sticking around.

If your team feels stuck... start here: Don’t reach for a new tool. Don’t add another meeting. Start with the emotional tone in the room. Because positivity isn’t soft - it’s strategic. In high-pressure environments, emotional tone shapes: → How fast decisions are made → How well people collaborate → Whether feedback leads to growth or resistance Behavioral research shows: - Positive teams solve problems 20–30% faster - Joy and humor increase memory retention - Emotional safety leads to higher risk-taking (the good kind) Here’s a reframe that works: “What are we proud of - and how do we protect it?” That’s not just a morale boost. That’s a diagnostic tool for what’s working, so you can scale it. Remember: Culture isn’t a vibe. It’s the feeling your systems create - every single day. Build systems that reinforce energy, trust, and progress. Because momentum starts with mood.

Are you having any fun? Most startups and ambitious projects fail for one reason: the people running them give up. Why? They’re miserable. If you’re counting on some future success to justify years of pain, you risk feeling empty when that “big moment” finally arrives—and risk quitting if it doesn’t. But what if the journey itself was fun? Imagine creating an environment so engaging that you want to keep going through late nights, tight deadlines, and pivots—because you’re enjoying it. That’s not naive; it’s smart. A team (and founder) that loves the process is far less likely to throw in the towel. Famously: - Apple’s Macintosh Team hung a pirate flag in their office. - Pixar is known for Nerf wars and scooters in the halls. - Atlassian runs “ShipIt Days,” letting teams build anything they want for 24 hours. When I co-founded Graphite, we added hidden memes to the product, broke up grueling coding sessions with StarCraft 2 matches, and even pranked each other with a “rogue weasel” bug in the website. Silly? Maybe. But it kept us energized, creative, and motivated to push even harder. Ideas for having more fun while working: - Work remotely from a new location for a week (tacos in Mexico?) - Host a small, healthy ritual—like a weekly spa or gym session—to talk shop without the office pressure. - Embrace playful hackathons or mini side-project days. - Pull the occasional (harmless) prank to keep morale high. Hard work doesn’t have to be joyless. Fun is the long-term fuel that prevents burnout and keeps you (and your team) in the game. If you love the journey, you’ll stick around until you reach success—or pivot until you find it. https://lnkd.in/eAuKu_XD

As a Project or Program Manager, we are often the unofficial CMO — Chief Motivation Officer — for our teams. When it comes to motivation, one thing that truly boosts morale is  CELEBRATING WINS We often rush from one milestone to the next, chasing the bigger delivery. Sometimes, we are so busy that we forget the Wins. And here’s the truth: wins—big or small—deserve to be celebrated. And wins aren’t just about achieving a milestone or closing a project. They can take many forms:  -> Quantitative Wins – measurable outcomes (budget saved, timeline shortened, revenue impact, % efficiency improved)  -> Qualitative Wins – less tangible but equally powerful (stakeholder trust, client feedback, enhanced reputation)  -> Collaborative Wins – fostering cross-team alignment, breaking silos, creating synergy  -> Strategic Wins – aligning projects with organizational vision & long-term goals  -> Process & Innovation Wins – streamlining workflows, introducing automation, raising PM maturity  -> People & Growth Wins – mentoring, upskilling, and growing leadership within the team  -> Customer/End-User Wins – delivering solutions that delight, improve usability, and solve real pain points Celebrating these moments is not just about recognition. It’s about:  - Keeping team motivated  - Reinforcing great communication  - Building resilience during challenges  - Creating a culture of gratitude and belonging  As PMs, let’s not just deliver projects—let’s also celebrate the journey. Because it’s in those celebrations that teams feel valued, connected, and inspired to do even better.  Every win matters.  Every win motivates us!!!