Code, Leadership & the Remote Dev Life

Category: Management

  • Scaling PHP Projects: Management Tactics That Actually Work for Remote Teams

    Scaling PHP Projects: Management Tactics That Actually Work for Remote Teams

    Scaling a PHP project while leading a remote team can feel like juggling fire—with one hand tied behind your back.

    The good news? It’s not magic. It’s management. And if you do it right, it actually scales.

    Here’s what’s worked for me.

    1. Codebase ≠ Product ≠ Project

    This sounds obvious, but it’s a trap I’ve fallen into more than once.

    Just because the code is growing doesn’t mean the product is scaling. And just because your project is active doesn’t mean it’s healthy.

    Scaling requires clarity across all three:

    • Codebase: modular, testable, readable
    • Product: valuable, usable, maintainable
    • Project: scoped, predictable, prioritized

    If even one of those lags behind, the whole thing eventually buckles.

    2. Document Decisions, Not Just Code

    Remote teams lose context faster.

    Every workaround, workaround-for-the-workaround, and architectural debate? Log it somewhere. It doesn’t have to be fancy—a decisions.md, a Google doc, even an email to the team.

    What matters is that new devs (and future you) know why things were built the way they were.

    3. Choose Process That Scales With Autonomy

    Remote PHP teams thrive when they’re empowered. But empowerment without direction is chaos.

    My tactic? Light process, heavy alignment:

    • Clear roadmaps (3–6 months out)
    • Weekly async updates
    • Monthly syncs for big-picture recalibration

    We do enough to keep momentum, not enough to drown in Jira tickets.

    4. Let the Team Shape the Tech

    This one took me a while to get comfortable with.

    When we started scaling, I wanted to keep the architecture tightly controlled. But as the team grew, that control started to strangle progress.

    Now I give teams ownership of their domains—with a few guardrails:

    • Code conventions enforced via CI
    • Shared utilities and logging
    • Designated leads for review & mentoring

    This keeps the architecture coherent without making me the bottleneck.

    5. Use Metrics—But Human Ones Too

    Yes, we track deploys, error rates, PR velocity, and test coverage.

    But we also track:

    • Time-to-onboard for new devs
    • How often people feel blocked
    • Developer satisfaction (we literally ask)

    Scaling is as much about team health as technical output.

    6. Prioritize Tech Debt Like You Prioritize Features

    Scaling reveals what’s fragile. You can either keep duct-taping… or plan refactors like real deliverables.

    We treat tech debt as first-class work:

    • Logged with clear impact
    • Prioritized alongside features
    • Tracked to completion

    The result? A codebase that doesn’t collapse the moment you add two more developers.

    7. Be Explicit About What’s Not Getting Done

    This is huge.

    When you’re scaling, you will make tradeoffs. The mistake is pretending you’re not. Be loud about what’s been pushed, paused, or shelved. This builds trust with both devs and stakeholders.

    It’s better to say “We’re not doing that yet” than to silently let things rot on the backlog.

    8. Mentor, Don’t Manage

    Your developers aren’t there to be task rabbits. They’re there to grow, contribute, and lead.

    The more your team can make good decisions without you, the more scalable your project becomes.

    Make room for that.

    Final Thought

    Scaling a remote PHP project is about more than frameworks and deadlines. It’s about people, priorities, and process that adapts.

    There’s no single magic tactic—but if you build the habits, you build the scale.

    And honestly? That’s the part I’ve come to enjoy the most.

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

  • Aligning Roadmaps With Team Capacity

    Aligning Roadmaps With Team Capacity

    Early in my career, roadmaps felt like a wishlist. Marketing wanted X, sales wanted Y, and we—engineering—were somehow supposed to make it all happen. And when we couldn’t, we were labeled blockers.

    It took years (and more than a few failed quarters) to realize the issue wasn’t execution. It was misalignment. We were promising more than our team could realistically deliver.

    Here’s what I’ve learned about making sure roadmaps aren’t just ambitious—they’re achievable.

    1. Start With Capacity, Not Deadlines

    Before locking in a roadmap, I now ask: “What can this team realistically handle over the next cycle?”

    Not what the business hopes for. Not what looks good on a slide.

    That means looking at:

    • Who’s available (and for how long)
    • Time already committed to support, bugs, or tech debt
    • The velocity you’ve actually observed, not idealized

    Setting the roadmap after capacity is understood isn’t pessimism—it’s adulting.

    2. Separate Strategy From Execution

    Leadership often confuses goals with commitments. Strategy says “we want to grow revenue by 30%.” Execution says “we need three new features to get there.”

    I’ve started drawing a bright line between the two. Strategy sets direction. Execution defines what the team can actually ship.

    If the roadmap doesn’t fit the team’s reality, something has to give—either the timeline, the features, or the resources.

    3. Build in Slack Time

    Every roadmap should include breathing room—for surprises, for iteration, for life.

    If your plan assumes everyone works at 100% capacity, 100% of the time, you’ve already failed. Someone will get sick. A requirement will change. Production will break.

    I typically plan for 70–80% of theoretical capacity. The rest goes to the stuff we can’t predict but always happens.

    4. Be Transparent With Stakeholders

    I’ve stopped sugarcoating what’s feasible. When a stakeholder asks, “Can we squeeze in one more thing?” I walk them through the cost:

    • What gets pushed out
    • What breaks our velocity
    • What causes burnouts

    Instead of just saying “no,” I show why it doesn’t fit—and offer choices. Sometimes, they prioritize differently. Other times, we push the timeline. Either way, they’re part of the decision, not just recipients of it.

    5. Review and Re-align Often

    Roadmaps aren’t static. Things shift—people leave, dependencies slip, goals evolve.

    I do biweekly check-ins to track:

    • Are we on track?
    • What’s blocked?
    • Has capacity changed?

    At work in Caseproof, we use EOS as our company’s “operating system” to help us regularly review and re-align our goals.

    These aren’t full replans—just touchpoints. They let us course-correct before we end up way off base.

    Roadmaps Aren’t Promises—They’re Plans

    If you treat the roadmap like a contract, every delay feels like a failure. But if you treat it like a plan, it becomes something your team and stakeholders can adjust together.

    Alignment doesn’t mean you can do everything. It means everyone knows what you’re doing, why you’re doing it, and what it will cost.

    When you get that right, your roadmap becomes more than a wishlist. It becomes a tool for trust.

  • Setting Boundaries: Managing Workload, Not Just Projects

    Setting Boundaries: Managing Workload, Not Just Projects

    There’s a difference between managing projects and managing workload—and I learned that the hard way.

    Years ago, I was tracking all the right things: timelines, tickets, blockers. Everything looked “green” on the outside. But inside the team, people were burning out. Quietly working late. Missing lunch. Pulling weekend hours they weren’t talking about.

    The projects were being managed. But the people weren’t.

    That’s when I realized: managing workload isn’t about assigning less—it’s about setting and respecting boundaries.

    Boundary #1: Working Hours Are Not Elastic

    If your default culture is “just get it done,” the work will always expand to fill every hour—and then some. I started explicitly reinforcing working hours. If someone posted on Slack outside of their supposed working hours (we choose our own schedule at work), I’d DM and say: “Why are you online?”

    Not to scold. To remind them that work doesn’t own their life.

    Sometimes people just need permission to stop. Your silence might be read as approval otherwise.

    Boundary #2: Protecting Focus Time Is Non-Negotiable

    Meetings creep. Chat pings multiply. Before you know it, your devs have no deep work blocks.

    I began blocking out “no-meeting hours”—team-wide. The effect? Less context switching, more velocity, and (most importantly) less frustration.

    Managing workload isn’t just about what’s on someone’s plate. It’s about how fragmented that plate is.

    Boundary #3: Push Back On Poor Planning

    One of the hardest things I had to learn as a manager: urgency is not the same as importance.

    Just because someone higher up says “we need this by Friday” doesn’t mean it’s realistic—or respectful. I started asking for context: “What happens if this ships next week instead?” Often, the answer is… nothing.

    Pushing back protects your team’s bandwidth. It also teaches stakeholders to plan better.

    Boundary #4: Normalize Saying “No” (Or “Not Now”)

    Burnout thrives in a culture of yes.

    So I made it a habit to publicly say “no” to things (not just at work but in every aspect of my life as well). “We’re at capacity. Let’s revisit this next sprint.” By modeling that behavior, others followed.

    Saying no isn’t negative—it’s leadership.

    Burnout Isn’t a Resource Issue. It’s a Boundary Issue.

    You can’t spreadsheet your way out of an overloaded team. You need to lead with empathy, not just efficiency. That means checking in. Not just “How’s the project going?” but “How are you doing with this load?”

    Sometimes the fix isn’t reassigning tasks. It’s redefining expectations.

    You’re Not Just Managing Work. You’re Managing Energy.

    If you care about sustainable output, you have to care about human input. Burnout costs more than missed deadlines—it drains morale, trust, and creativity.

    Set the boundaries. Protect the energy. The projects will follow.

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