Code, Leadership & the Remote Dev Life

Tag: Engineering Leadership

  • What I Wish I Knew Before Becoming a Dev Manager

    What I Wish I Knew Before Becoming a Dev Manager

    When I first stepped into a dev manager role, I thought I had a pretty good handle on what was coming. I’d been around long enough, led a few projects, mentored juniors, dealt with deadlines. Seemed like a natural next step.

    Spoiler: I was wrong.

    Becoming a dev manager isn’t a promotion—it’s a whole new job. And while I eventually found my footing, there’s a bunch of stuff I really wish someone had told me upfront.

    Here’s what I’ve learned the hard way:

    1. You’re Not Just Managing Code Anymore

    This sounds obvious, but I didn’t fully get it until I was deep in.

    As a developer, success was about shipping features and solving hard problems. As a manager, success became helping others ship features and solve hard problems—without writing the code myself.

    Letting go of “doing the work” was way harder than I expected. But if you’re still trying to be the best coder and manage people, you’ll fail at both.

    2. The Work Is Now Invisible

    You fix a toxic process. You help two devs resolve a conflict. You convince leadership not to scope creep the sprint.

    Nobody sees it.

    There’s no commit history for emotional labor, no ticket for “protected the team from chaos.” But that work? It’s everything.

    Managing is mostly invisible—but it’s what makes visible success possible.

    3. You Will Miss Coding (and That’s Okay)

    At first, I felt like I’d lost something. That satisfying “flow state” of getting deep into a problem? Gone. Replaced by meetings, 1:1s, and planning sessions.

    Full disclosure: I still code but not as much as I used to. And yeah, I missed it.

    Eventually I realized: my flow state just looks different now. It’s when I help a dev level up. Or smooth out a cross-team dependency. Or watch a new process click.

    It’s a different kind of win—and it still matters.

    4. People Are Not Pull Requests

    Devs don’t come with diffs and tests. Their behavior can be inconsistent, unpredictable, emotional—even irrational.

    But that’s the job now: figuring out what motivates, supports, and challenges each person in a way that keeps them growing.

    No linter will help you with that.

    5. You’re in the Middle (and It Gets Messy)

    You’re not just leading your team. You’re translating between leadership and the ground floor. You’re advocating for your people and representing the company.

    It’s a balancing act. And yeah, sometimes it sucks. You won’t always agree with the direction. You’ll have to deliver bad news. You’ll feel stuck.

    But how you carry yourself through that ambiguity? That’s what defines you as a manager.

    6. Your Team’s Success is the New Scoreboard

    The first time one of my team members got promoted—and I had zero lines of code to do with it—I finally got it.

    Management isn’t about you leveling up anymore. It’s about building a system where others can.

    And when you get that right, it’s incredibly fulfilling.

    Final Thoughts

    If you’re stepping into dev management, get ready to feel unqualified, out of your depth, and occasionally nostalgic for the simplicity of code.

    But also—get ready to grow in ways you didn’t expect.

    You’ll learn to communicate better. Handle uncertainty. Build trust. Navigate chaos. And, eventually, build a team that thrives with or without you.

    That’s the real job.

    And it’s worth it.

  • Helping Your Team See the Bigger Picture

    Helping Your Team See the Bigger Picture

    I’ve worked with plenty of talented devs who could debug gnarly logic, optimize slow queries, and write clever abstractions—but struggled to see why their work mattered beyond the next ticket.

    Early in my leadership journey, I assumed it was enough to just assign tasks and let people do their thing. After all, I trusted the team. But over time, I realized something was missing. People were shipping code, but they weren’t invested. They didn’t feel like owners. They were solving technical puzzles, not business problems.

    And that’s when it hit me: we were shipping features without context.

    Why Context Matters

    When people understand the why behind their work—how it connects to customers, revenue, or product direction—they make better decisions. They also care more. They ask smarter questions. They challenge assumptions. They propose better solutions.

    Without that context, even the best engineers become task robots.

    What Helped Me Turn the Corner

    It wasn’t a grand strategy. Just a shift in how I communicate:

    • Start with the goal. Every task or project starts with a short narrative: what we’re doing, who it helps, and why it matters now. This isn’t just for PMs—it’s for everyone.
    • Connect to user impact. Even a backend caching change can be tied to how fast a user sees search results. Engineers light up when they realize they’re shaping experience, not just writing code.
    • Regularly share progress at the business level. Not just burndown/burnup charts. Share “what this release unlocked” for the team or customer. Celebrate not just commits, but outcomes.

    Seeing the Shift

    Once you start being more intentional with sharing context, you’ll see something surprising: junior devs will begin asking product-level questions. QA will start offering UX feedback. Engineers will volunteer to talk directly with users (or maybe not, but hey… who knows). It’s not because you asked them to—it’s because they care.

    Giving people the bigger picture doesn’t dilute focus. It deepens it.

    Devs Want Purpose, Not Just Process

    We underestimate how hungry smart people are for purpose. When all they see are feature requests and sprint boards, they can lose sight of why they got into tech in the first place: to build things that matter.

    Helping your team see the bigger picture is a leadership multiplier. You won’t just ship features—you’ll grow people. And in my book, that’s the better metric.

  • Keeping Morale High During Crunch Time

    Keeping Morale High During Crunch Time

    Crunch time. Two words that make most developers groan and most managers sweat.

    No matter how well you plan, estimate, or try to keep the team agile and lean, there’s always that moment when a deadline barrels toward you like a freight train, and suddenly it’s all hands on deck. It’s stressful. It’s exhausting. But most of all—it’s dangerous for morale.

    I’ve been through enough crunches in my career to know that how we manage those moments can make or break a team—not just in terms of productivity, but in terms of long-term trust and culture. So today I want to talk about what’s worked for me when the pressure’s on, and how I try to keep morale from falling apart during those intense sprints.

    Acknowledge the Reality Without Sugarcoating

    When the pressure starts building, the worst thing you can do is pretend everything is fine.

    I don’t like management-speak like “we’re almost there” or “let’s push through just a bit more” when I know the team is looking at 12-hour days for the next two weeks. It feels dishonest, and worse, it makes people feel like their suffering isn’t seen.

    Instead, I try to be real. I’ll say things like:

    “I know this next stretch is going to be brutal. We didn’t plan for this scope creep, but we’re in it now, and I appreciate each one of you stepping up.”

    That kind of transparency sets the tone. It says, “Yes, this is hard. And yes, I see it. I’m here with you.”

    And sometimes, that’s all people need—to be seen and understood.

    Communicate More, Not Less

    During crunch time, communication needs to increase, but not in a micro-managey way.

    I set a rhythm. Quick daily check-ins (async if possible), a short wrap-up every couple of days, and clear updates on priorities. I avoid random pings like “how’s it going?” and instead ask, “Do you need anything to unblock X?” or “Is there something we can cut or shift?”

    The idea is to reduce ambiguity and avoid the “black box” feeling—where team members don’t know what others are doing or what’s expected next.

    When everyone knows what they’re responsible for and what’s on the horizon, they feel more in control, and that’s a big morale boost when the days are long.

    Protect the Team’s Focus

    Meetings during crunch time? No thanks.

    Unless it’s absolutely critical, I cancel or reschedule. The goal is to give everyone long stretches of uninterrupted time to just do the work. If I can act as a buffer—shielding the team from stakeholders, random scope changes, or impromptu calls—I’ll do it gladly.

    Even better, I’ll communicate that I’m doing it:

    “Hey, the client wanted to check in again this week, but I told them we’re heads down and will give them a proper update Friday. Just keep building—we’ve got your back.”

    That kind of message is gold. It tells the team that their time is valued and their focus is protected.

    Celebrate the Small Wins

    One of the fastest ways to kill morale is to make the mountain feel insurmountable.

    I like to break the work down into visible chunks and celebrate the progress. Finished the frontend login refactor? High five. Got the backend cache working smoothly? Take a screenshot and share it in Slack with a 🎉 emoji.

    You’d be surprised how energizing it is to feel like you’re actually making progress—especially when it feels like you’re sprinting on a treadmill.

    Perhaps even throw in micro-incentives:

    • Friday shout-outs in the team channel
    • “Bug squashers of the week” leaderboard (totally optional, no pressure)
    • Or even a simple, great job this week sent as a private message

    It’s not about turning it into a competition—it’s about injecting a little fun into the grind.

    Recognize Human Limits

    Here’s something I learned the hard way: people can’t sprint forever.

    Even if your team is made of high performers, even if everyone is “motivated,” and even if no one complains—burnout doesn’t knock. It creeps.

    So I try to monitor for signs. If someone’s commits are getting erratic, or they’ve stopped responding like they used to, I’ll check in. Not as a manager, but as a fellow human:

    “Hey, I noticed you’ve been pushing late into the night a few days in a row. Everything okay? Want to take half a day off this week to reset?”

    More often than not, the answer is yes. And they come back better the next day.

    Crunch time isn’t just a technical challenge—it’s a mental one. If we pretend our teams are machines, we’re going to break them.

    Don’t Forget to Laugh

    This sounds minor, but it isn’t.

    Laughter might be the only thing keeping some teams sane during a hard push. I’ve seen devs running on zero sleep still light up when someone drops a dumb meme in the group chat or makes a terrible pun in the commit messages.

    You don’t need to force it, but leave space for fun. Be okay with goofiness. Share silly gifs. Celebrate inside jokes. In those moments, the stress fades—just for a second—but it makes a difference.

    After the Crunch: Recovery Matters

    Here’s where a lot of managers drop the ball: after the deadline, they just move on.

    Big mistake.

    After a sprint like that, people need time to decompress. Give them a real breather. Cancel non-essential meetings for a week. Let folks start a little later. Say, “Nothing urgent this week—take care of yourself.”

    And thank them—publicly and privately. Acknowledge not just the results, but the effort. Say their names. Share the wins. Let people feel it.

    That recovery phase isn’t just good for morale—it’s the bridge between “We survived” and “We’d do this again with you if we had to.”

    Final Thoughts

    Crunch time isn’t ideal. No one should plan for it. But it happens. Projects run late. Clients ask for too much. Features need rework. Life throws curveballs.

    When it does, our job as leaders isn’t just to hit the deadline. It’s to get there without breaking our team’s spirit.

    That means leading with empathy, protecting focus, injecting fun, and celebrating every little win along the way. And when it’s all over, letting people breathe.

    Morale isn’t magic. It’s a choice—built through small actions, every day, especially when it’s hardest.

    Here’s to surviving the crunch—and coming out stronger.