I had just signed up for Claude to evaluate whether it could realistically replace ChatGPT in my workflow. Copilot already lives inside my IDE and has been solid for a while. ChatGPT fills the thinking space outside it. Codex was new to me, and I hadn’t pushed it beyond small experiments. Rather than rely on opinions, I wanted to see how they behaved when given the same real problem.

I took a feature from a production side project and gave the exact same specification to all three. No prompt tuning between runs. No follow-up corrections. Just the same instructions, copied and pasted.

The project itself isn’t the focus, but for context it’s a 3D print cost calculator that’s been live for some time. The feature came directly from user feedback: support multiple materials in a single calculation.

Modern 3D printers can switch between filament spools mid-print. That means a single object might use two or three different materials. From a costing perspective, the application can no longer assume one material per job. It needs to aggregate several weights, each with its own cost per kilogram, and still produce a stable total.

Previously, the model was simple: one material, one weight. The new version required introducing a list of material usages, updating the UI to support adding and removing entries, migrating existing saved calculations so nothing broke, adjusting the cost engine to sum across usages, and updating exports and tests to reflect the change. It was a contained but multi-layered change, the kind that forces you to think about backward compatibility before aesthetics.

All three tools produced coherent implementations. Nothing wildly off target. Nothing unusable. Each of them understood the structure of the problem and translated the specification into working code.

There was one shared oversight. The feature was meant to be premium only, and none of them added any form of gating. That detail wasn’t in the instructions, so it never appeared in the output. It wasn’t dramatic or surprising, just a straightforward reminder that these systems implement what is written. Anything that lives in your head but not in the spec simply does not exist from their perspective.

Where They Diverged

Claude wrote the most code and made the broadest structural changes. It introduced immutability into the data model and added supporting packages to enforce that pattern. It also flagged localisation concerns, something the others ignored, although the implementation itself only covered English, ignoring the other 9 languages. The overall feel was of an engineer who prefers improving the surrounding structure while adding the feature, even if that means expanding the footprint of the change.

Copilot took a more conservative approach. It extended the existing structures rather than reshaping them and stayed close to established conventions in the project. The implementation felt incremental and aligned with what was already there. Tests were adjusted where necessary, but new work was ignored as far as testing was concerned.

Codex landed somewhere between those two. Its structural footprint was closer to Copilot’s, but the feature felt more complete. The user flow around multiple materials was slightly cleaner, and the test coverage went beyond simply keeping the build green, it updated tests where necessary but also included test for the newly introduced business logic. It did not attempt to modernise the surrounding architecture, but it did seem to push the feature towards a finished state rather than a minimal extension.

Claude also took noticeably longer to produce its output. Codex and Copilot completed within minutes of each other, while Claude took roughly twice as long. That difference did not materially change the evaluation, but it was visible when running the comparison side by side.

What stood out over time was less about correctness and more about inclination. Each tool behaved like a different kind of engineer. One leaned towards structural refinement, one towards continuity, and one towards feature completeness. None of them had context about my longer-term intentions for the project, and none of them could weigh architectural disruption against speed of integration in the way a human maintainer does. They simply optimised within the boundaries of the instructions provided.

The Decision

In the end, I am not merging any of the branches as they stand. Codex is probably the closest to something I could integrate with minimal additional work, largely because its changes sit comfortably within the existing structure while still delivering a rounded implementation. Restoring a removed widget or adding premium gating is straightforward, and extending localisation properly is manageable. The path to integration feels shorter.

But the final implementation will be selective. The strongest elements from each approach can be combined, and the business constraints that were never specified can be applied deliberately. That part still belongs to me.

What this exercise clarified is not which tool is “best.” It is how differently they interpret the same constraints and where they naturally apply effort. Used in isolation, that bias might go unnoticed. Run in parallel, it becomes visible.

That visibility is useful.

Instead of choosing a single tool and treating it as the answer, there is value in letting them generate alternative implementations and then integrating intentionally. They can explore branches quickly. I remain responsible for coherence, consistency, and long-term direction.

That division feels realistic.

Not long ago, someone on my team shared an idea they were exploring. I began with a caution, meaning to help them avoid a pitfall I’d learned the hard way. I followed up with suggestions and examples from my own experience. From my perspective, the conversation went smoothly. Only later did I learn, through someone else, that it hadn’t landed that way. They felt dismissed.

That realisation surprised me. I had genuinely believed it was a supportive, collaborative discussion. The truth is, there’s a gap in my self-awareness-a blind spot around how my words or tone might shape someone else’s perception. My intention was to guide, but the impact was to discourage.

I’ve been working to bridge that gap. Thinking has become my best tool so far-slowing down just long enough to consider how I begin a response, to pause before speaking, to ask a question instead of offering an answer. Curiosity softens the space where instinct once jumped in.

Lately I’ve also started ending my days with a short “catalytic retro.” Ten to fifteen minutes to quietly revisit the day’s interactions and decisions, asking not just what went well but what landed wrong. Wins tend to speak for themselves. It’s the misses that offer the real insight, if you’re willing to see them.

That small pause between intention and impact-that’s where growth lives.

Next time: When Accountability Feels Like Blame

Recently, a report shared something he wanted to pursue. I was supportive — I really was — but my first response came as a caution. By the time I circled back with encouragement, the damage was done. My intent was positive, but because I led with a warning, it landed as dismissive. If I had simply restructured the order, the conversation would have gone much differently.

That first sentence doesn’t just start the conversation, it sets the emotional tone. In leadership, where words echo longer than we imagine, that opening matters.

I’ve become more intentional in 1:1s. Mondays are blocked for them, and I build in prep time before each call. If I roll straight from deep work into a conversation, my attention is split. Reviewing notes and preparing a loose outline helps me switch context and center myself before we begin.

But no matter how much you plan, conversations have a life of their own. You can only plan your side. A loose structure keeps things anchored, but flow makes it human. The art is knowing when to guide and when to let it breathe — and remembering that the very first thing you say will shape how the rest of it is received.

Next time: The Space Between Intention and Impact

When you’re earlier in your career, there’s often a sense that you have to know, that asking questions risks exposing you. The irony is that admitting you don’t know and asking for help are both powerful strengths.

The best conversations often start with not knowing. You either dive into a discussion that unpacks the problem or you step away to do some research on your own. Both paths are valuable. And when you admit you don’t know, you make space for others to do the same. You’re showing trust, and you’re inviting the so-called “stupid questions” that usually turn out to be the ones everyone was sitting on.

That’s not to say I don’t have my moments of blurting out the first answer that comes to mind. I think fast, I talk fast, and I’ll sometimes start with a solution and work my way backwards. It can turn into a one-sided monologue if I’m not careful. Over time, though, I’ve learned to make a conscious effort to sit with the question instead.

Silence can be uncomfortable, but it’s also a tool. It gives both people space to think. Sometimes the other person uses that pause to elaborate further, and suddenly the picture looks completely different than it did when I first thought of an answer.

So when I don’t have the answer, or even when I think I do, I’ve learned that waiting — not rushing in to fill the gap — is often the best answer of all.

Next time: The Weight of the First Word

In my 1:1s, I try to pause before responding. It's not about waiting for my turn to speak, but about listening to understand, not just to reply. Sometimes that pause encourages the other person to keep talking, to elaborate in ways they might not have if I'd jumped in too quickly. Other times, it gives me the clarity to respond more thoughtfully-or even the courage to admit I need time before giving an answer.

When I first joined Loop, someone pointed out that I had a habit of filling silence. Luckily, I caught that before I started running 1:1s with my team. Those meetings aren't meant for my voice to dominate. They're their time, their space. My role is to hold it, not to crowd it.

As for interpreting silence, context matters. In deeper conversations-whether about growth, progression, or tough questions-silence usually means thought. It's the weight of someone considering their words, reflecting before speaking. I haven't yet experienced it as something negative. More often, it's the quiet before honesty.

Silence doesn't need to be awkward. It can be an ally. The courage lies in resisting the urge to break it, and instead trusting what it makes possible.

Next time: When Not Having the Answer Is the Answer

One former teammate stands out in my memory. Brilliant mind, but he often over-engineered his solutions. Feedback came late, after days of work, when the code had sprawled into hundreds of lines across dozens of files. What should have been a simple fix ballooned into a tangle of complexity that testing inevitably sent right back.

As a lead, this was one of the hardest balancing acts I've faced. I could see where he was veering off course, and the urge to step in was strong. But my instinct is to guide through questions rather than directives. I know if I state an answer outright, my team tends to agree too quickly - and we lose the benefit of their independent thinking.

Still, accountability doesn't vanish just because you believe in ownership. In one case, after we had already aligned on a simple plan, the “fix” returned days later as a massive rewrite that didn't even solve the root issue. At that point, I had to step in and block the work. He asked me, almost exasp“Whatd, “what do you want me to do?” Not the kind of moment any leader loves, but a reminder: guiding has limits. Sometimes, you have to draw a line.

That tension is real. Letting people struggle long enough to learn, without letting the team or product suffer. Asking the better question, without abdicating your role. Ownership is a gift, but guidance is still a responsibility. The art is in knowing where one ends and the other must begin.

Next time: The Courage to Let Silence Do the Work

At the same time, I've always been a good listener. My instinct may be to fix, but I've learned over the years that listening doesn't have to mean acting. It doesn't have to mean rushing in with an answer.

Working as a lead has sharpened this skill. Leadership has taught me the discipline of listening - not to respond, not to solve, but simply to hear and understand. And the more I've practiced it, the more I've realized something: fixing isn't always the solution.

Listening creates space. It lets me sense when someone simply needs to be heard and when they truly need help. And even then, the best next step often isn't jumping in to fix. It's offering. It's asking. It's letting them decide if they want support, or if they just needed to let something out.

This is where relationships matter most. Over time, you learn the difference between a quick vent and a real frustration that needs addressing. You start to see when your role is to clear the path and when it's to simply stand beside them while they walk it.

As leaders, our job is to help our teams be at their best. Some obstacles are visible and easy to remove. Others only come out when someone feels safe enough to share. And in those moments, the best thing we can do is not to fix for them, but to help them fix for themselves. To guide them toward their own solution, to help them own it. Because that's where real growth happens.em toward their own solution, to help them own it. Because that's where real growth happens.

Next time: Guiding Without Owning

You know the one. It’s in response to “How are you doing?” It’s polite. Acceptable. Technically honest — yet designed to sidestep the real truth. I’ve given that answer myself more times than I can count.

The thing is, it’s a perfectly fine question, but it’s also incredibly easy to answer without answering. Over time, once the relationship is built and trust is there, you can often skip straight to the second question. Especially when you can feel that something’s off.

My go-to? A simple, “OK… so how are you really doing?”

It’s not wildly different from the first question, but it carries weight. It signals that you’re paying attention, that you see past the surface, and that you actually care enough to ask again. Often, that’s when a short, guarded answer turns into a 5–10 minute conversation.

It’s also a handy tool when you can sense there’s more to the story, but you don’t yet know enough to ask something more direct.

I’ve been on the other side of it too. My lead has caught me in that safe-answer moment and asked the second question. Sometimes, to my frustration, because those are usually the moments I want to keep my cards close. But in hindsight, those were also the moments I needed that second question most.

Sometimes the first question opens the door.

The second question invites someone to step through it.

Next time: How to Listen Without Fixing

Some of the best shifts in perspective I’ve seen have come from what others might call “silly questions.” Even the silliest can spark curiosity, trigger a better solution, or help the group see something they’d missed entirely. But those moments only happen if the questions are spoken out loud.

Why teams stay quiet

• There are plenty of reasons people hesitate to speak up:

• They’re worried about looking unprepared.

• They don’t want to slow things down.

• They’re unsure if their idea is relevant.

• They simply aren’t used to open conversation.

I’ve seen this play out firsthand. You ask a group-level question to a quiet team and get… nothing. But a few minutes later, you ask one person directly, and they talk for five minutes — sharing great feedback and fresh insights you would have never heard otherwise.

How to get people talking

The approach will depend on your team, but one of the fastest ways I’ve found to get ideas flowing is to start “picking” on people. Not in a hostile way, but intentionally choosing someone to respond. Start with someone you know will have an opinion — it gives the rest of the team a chance to think, and often sparks others to jump in.

Even a simple open-ended question like “What are your thoughts?” works better when followed by “Alex, let’s start with you.” It removes the pressure of volunteering and instead gives permission to speak.

Lead by example

One of the most powerful ways to encourage questions is to ask them yourself — especially when you don’t know the answer. During one of my interviews for my current role, I was asked a technical question. I guessed, but made it clear it was a guess. When they told me I was wrong, I simply asked, “What’s the answer?”

That moment mattered. It showed I was comfortable not knowing and more interested in learning than in pretending I knew everything. That’s the kind of behavior I want my team to feel safe modeling.

Make it normal, not exceptional

If you only encourage questions during special “brainstorm sessions,” people will treat speaking up as an exception. If you do it in every stand-up, review, and retrospective, it becomes part of how the team works. The more normal it feels, the more people will share — and the less you’ll risk losing great ideas to silence.

Next time: The Subtle Art of Asking the Second Question

But like most things in engineering, it comes with tradeoffs.

At a previous company, I was the sole owner of two codebases. I'd been hired to rebuild the mobile app into a new framework-originally React-but after some digging, I realized that plan wasn't going to fly. The company pivoted to rebuilding the management console first and revisiting the app later. Eventually, both became my projects. From the ground up. Just me.

It got to the point where, during a year-end company speech, the CTO half-joked:

“If Reme gets hit by a bus, we're fucked.”

Empowering, right?

It's a strange kind of job security. When you're the only one who understands how things work, you carry a lot of influence. But you also carry a lot of weight. Every bug. Every outage. Every weird edge case in support. Yours. Even when you're not officially on support duty.

Eventually we did hire additional engineers, but that shift came long after the systems had already been shaped by one person's habits, patterns, and shortcuts. That level of individual ownership is efficient in the short term, but risky in the long run.

I've seen this play out in other teams and orgs too:

A single person becomes the go-to. Sometimes they like it. Sometimes they hoard it.

Other times, they're desperate to share it-but no one wants to learn. That's the real danger.

Not just the infamous “bus scenario,” but the slow decay of team resilience and growth.

When ownership becomes isolation, it becomes a bottleneck.

The only strategy I've seen that actually works?

The rest of the team has to care.

Act like a team. Step in. Ask questions. Sit with the owner. Review the PRs. Break the silo intentionally.

Yes, documentation helps. But it only gets you so far. A lot of the critical knowledge is “muscle memory” you don't even think to write down.

I had a moment recently where someone posted a support screenshot. No context. No explanation. Just an error.

But I knew what it was.

A license error in the CI?

That's the wrong environment secret getting pulled. I could trace it in my head without even opening the code.

That's the kind of context you build over time. And the kind that's nearly impossible to transfer through a wiki page.

Technical ownership is powerful.

But without support and shared learning, it quietly becomes a liability.

Next time: How to Build Teams That Ask Questions Out Loud

But here's the truth I've come to learn: I often prefer not to know.

And honestly, I think that's part of why I landed the job I have today.

During my technical interview, I hit a question I didn't quite have the answer to. Or maybe I did, somewhere buried in memory, but it didn't feel familiar enough to stand by. So I said what I genuinely felt: “I don't know.” I took a guess, made it clear that it was a guess, and when it turned out to be wrong, I followed up with curiosity: “So what's the actual answer?” That moment, I believe, said more about how I work than any correct response could have.

Over the years, I've come to value not knowing as a strength. Experience doesn't mean you know everything - it means you've learned how to navigate what you don't. And often, the best ideas, the biggest breakthroughs, and the real “senior” moments come not from brilliance, but from perspective.

That's why I deeply believe there's no such thing as a stupid question. Some of the most “out there” suggestions have changed the entire trajectory of a project or exposed blind spots no one else saw. A half-baked idea can be the thing that nudges a good solution into a great one.

I was lucky early in my career to work with leaders who reinforced this mindset. One of the best mentors I've had was obsessed with improvement. I'd complete a task, call him over, and the conversation wasn't “is it done?” It was: “how can we make it better?” That set a tone I still carry with me - not knowing isn't a failure, it's an invitation to explore.

There's this quiet shift I've noticed that separates junior and intermediate engineers from senior and beyond. It's not the depth of knowledge, it's the comfort with not knowing. The humility to admit it. The willingness to figure it out with others.

I don't recall explicitly mentoring someone on this, but I do talk about it. Just recently, a new team member shared their fear of sounding stupid. I reassured them that if they had a “stupid” question, it might be the best one we hear all day. I try to live that out too - I'll pitch an idea in a team session, then immediately be the first to tear it down. Because being wrong is fine. Ideas don't have egos. If it's a good idea, it'll hold. If not, we move on better informed.

When it comes to giving answers, I try not to - at least not right away. I'll usually ask questions, try to guide a bit. That won't work for everyone, but personally, I learn better when nudged than when told. It just sticks more. There's something powerful in discovering a solution for yourself - you learn more, and you remember more. It becomes your insight, not just someone else's instruction.

Being senior isn't about knowing everything. It's about knowing how to navigate what you don't.

Next time: The Tradeoffs of Technical Ownership

At some point you realize: perfection is the enemy of done.

That doesn't mean we should write careless code. There's still pride in craftsmanship. But what shifts is your understanding of what done really means. You start seeing the bigger picture - that your work exists in a system with deadlines, dependencies, and a team relying on forward momentum. That no feature will ever be perfect the first time, or even the tenth.

One of the best things about modern software is that it can change. We can patch. We can refactor. We can iterate. (The gaming industry might abuse this a bit - but that's a separate post.)

I once worked with a CTO who, during a boardroom code review, threw a snippet onto the big screen and said, “Who wrote this crap?” Then he checked the git blame. “Oh. It was me. Moving along.”

This was someone with over 40 years of experience, looking at something he wrote six months prior. That moment stuck with me. Even the most seasoned engineers look back on their work and cringe. Not because they were bad - but because they've grown.

That's what makes perfectionism a trap. It assumes you'll have the clarity and knowledge today that only experience can give you tomorrow.

Instead, I've come to embrace something more sustainable: progress with intent. A little bit better each time. There's a great blog post about applying the Boy Scout Rule to code - leave it better than you found it (LINK). That mindset lets you move, learn, and improve without getting stuck.

In my own teams, I've learned that perfectionism usually shows up as work taking longer than expected. That doesn't always mean overengineering - sometimes it means someone's struggling and not speaking up. Either way, it's a cue to check in. Especially in remote teams, it's easy to miss the signs until someone's already deep in a rabbit hole.

One thing that helps is writing. Documentation, planning, solution design - not as overhead, but as clarity. When we slow down enough to think clearly up front, we're less likely to drift later.

At the end of the day, managing perfectionism is a skill - one we all have to learn. Sometimes we spot it in ourselves. Other times we need a nudge from a teammate or lead to help us zoom out. The goal isn't to lose that eye for quality - it's to make sure it serves momentum, not stalls it.

Next time: Why Senior Engineers Don’t Need All the Answers

One example: A developer once wrote up their own Jira ticket for a feature, loosely based on conversations we'd had. There wasn't a lot of complexity to it, so we didn't bother with a formal doc. The problem? The developer's interpretation of the requirements was off. And since nobody else reviewed the ticket, the mistake went unnoticed - even by QA, who tested against the same flawed assumptions. We only caught the issue when it came up during a live company demo.

It was a good reminder: documentation isn't just for the big stuff. And it doesn't have to be heavyweight or slow you down.

Here's what's been working for us lately:

Make the decision-making process visible, not just the outcome

We've started centralizing both the what and the why of decisions in Confluence, especially for larger projects. Business requirements, technical considerations, and planning notes all go here. Miro picks up the rest - flow diagrams, user journeys, integrations, and in some cases visual breakdowns of use-case-specific expectations.

What we've found helpful is that the doc isn't just a spec - it's a thread of thought. It tells the story of how we got here.

Don't wait for a perfect process - just start capturing what matters

We don't do formal RFCs, but we do write things down. Sometimes it's a bulleted list of tradeoffs. Sometimes it's meeting notes, design sketches, or just a short paragraph explaining a decision in the Confluence doc. That's enough.

More important than format is having a shared habit of putting these notes where people can find and reference them later.

Use tooling to reduce friction

We recently started experimenting with Google's NotebookLM - a tool that lets us load it up with our documentation, transcripts from meetings, and internal context, and then query it like a little team-specific AI assistant.

Instead of digging through notes or Slack threads, we can now ask: “What did we decide to do about use case X?” and get a response that includes who was involved, when the conversation happened, and a link back to the source material.

This has opened up new ways of keeping decisions alive across time - especially useful when onboarding new team members or revisiting work months later.

Find the right moment for sync vs async

Some decisions are best made in a meeting. We've found value in bringing different perspectives together early - it uncovers edge cases faster, aligns the team, and helps us feel ownership over the plan. But after the dust settles, we move things async: documentation, feedback, approvals. This helps prevent decisions from being locked away in someone's memory or lost in a calendar invite.

If we treat documentation as a tool for clarity rather than a chore for compliance, it becomes a force multiplier. And the best part? It doesn't need to be perfect - it just needs to be written.

Next time: The Problem with Perfect Engineers

The First Signs: Repetition, Reinterpretation, and Resistance

One of the earliest red flags is needing to repeat yourself. If you find yourself restating the same direction, goals, or expectations multiple times, chances are people either don't understand, don't agree, or don't believe it applies to them.

Another clue is reinterpretation. You might say one thing, but how it shows up in someone's work is a completely different flavor. Maybe you asked for a quick prototype, and what you get is a full-blown feature with edge cases handled. It sounds like initiative, but it could also point to a misread on intent or priority.

Then there's subtle resistance-not outright disagreement, but delays, dodging, or overthinking. When people aren't aligned, they struggle to move forward confidently. That hesitation is worth paying attention to.

Ask Questions, Don't Just Give Direction

One of the most effective tools in catching misalignment is asking people to replay their understanding. “What are your next steps?” or “How would you approach this?” forces clarity-for both of you. If their response surprises you, it's better to catch it now than after a week of work in the wrong direction.

This also surfaces hidden assumptions. Maybe someone thinks the priority is speed, while you're focused on stability. Maybe they think this is MVP work, and you're thinking proof of concept. Small gaps now become big ones later.

Keep a Pulse on What People Believe

Even with well-communicated plans, alignment can falter if people don't buy in. Listen for friction in the language. Do folks say “they decided” or “we decided”? Are people using the same words to describe the work or the problem?

These things tell you whether alignment exists only in documentation or lives in the culture of the team.

Shared Context ≠ Shared Alignment

You can all be in the same meetings and still walk away with different understandings. This is why I've come to believe that repetition alone isn't enough. You need active reflection. Short write-ups, decision logs, or retro check-ins create opportunities to re-anchor on what matters and why.

Alignment Is a System, Not a Speech

Next time: How to Create Clear Decision Logs Without Slowing DownUltimately, alignment is ongoing. It's built into how you run standups, write tickets, run 1:1s, and make trade-offs. The more space you create for people to ask questions, challenge ideas, and clarify priorities, the more likely you are to catch drift early.

Because the best time to fix misalignment is before it turns into resentment or rework.

Next time: How to Create Clear Decision Logs Without Slowing Down

At Loop, my first week was intentionally designed as a learning week. I was given a schedule packed with conversations across the org—engineers, PMs, even folks outside my direct team. No pressure to build, no assignments, just… listen, learn, connect. It’s a thoughtful setup that allows trust to build not through speed, but through presence.

From there, trust came gradually. As we worked together, shared problems, solved bugs, and debated solutions, it grew. I don’t remember any lightning-bolt moment. It was the kind of slow trust that comes from consistency—showing up, doing what you said you’d do, and being open to feedback.

Something I’ve reflected on more recently is my own relationship with trust. I used to be one of those “you have to earn it” types. But over time I’ve come to see how that posture, while protective, doesn’t actually invite connection. These days, I try to give trust more freely—maybe not the kind that throws open all the doors, but the kind that says, “I believe you’re here for the right reasons.” Especially in engineering, where people tend to be intrinsically motivated, I’ve found that giving trust upfront helps new teammates settle in faster and perform better.

It’s also helped me better support those joining the team after me. Because I remember what that first month felt like. The uncertainty. The quiet checking of Slack channels. The slow rhythm of figuring out how things work. If someone had second-guessed everything I did from day one, I’d probably have never found my rhythm. So I try to hold that same space for others now—ask more than I tell, listen more than I direct, and trust that if someone’s here, they’re here to do good work.

There’s no shortcut to trust. But there is a posture we can take that makes it easier: be curious, be consistent, and be human. Trust follows.

Next time: How to Spot Misalignment Early (Before It Becomes a Problem)

But here's the thing: I've never really been the type to micromanage. If anything, I probably err in the opposite direction. I trust by default. I assume people will get it done - and honestly, I'm usually too deep in my own work to check in more than I should.

That doesn't mean I don't care. It just means I've learned to separate involvement from interference.

What Accountability Actually Looks Like

For us, it starts with rhythm and presence. Standups are the easy one - they help surface blockers and build momentum. But beyond that, we lean into Discord as our virtual hallway. Most of the team hangs around in our channel throughout the day. It's casual, organic, and easy to drop in when someone needs help.

Mic on mute means “I'm here.” Deafen means “headphones on, deep focus, don't poke.” Just like an in-person office - one ear off means “interruptible,” both ears on means “heads-down.” It works because we've normalized the signals.

That kind of ambient presence means we don't need constant updates or heavy check-ins. We know what's happening. And when we don't, we just ask.

Involved, Not Overbearing

To me, being involved means understanding what needs to happen, staying close enough to the outcomes, and being available when things drift or stall. It means stepping in when:

• work is taking longer than expected,

• updates sound too similar day after day,

• or someone actually asks for help.

Being overbearing, on the other hand, is stepping in constantly. It's adding noise instead of clarity. It's checking in so much that you become the blocker.

Why This Matters

When people feel trusted, they step up. They take more ownership. They stretch themselves. Accountability becomes internal, not imposed. And you, as a leader, can focus on what really matters: enabling them, not managing them.

And if something's going off track? That's when you step in - not with blame, but with clarity. Ask questions. Reset priorities. Offer help. But don't assume control unless it's truly needed.

That balance - staying close enough to guide but far enough to trust - is where the real magic happens.

Next time: How to Build Trust When Joining a New Team

When feedback lands, especially the kind that catches you off guard or stings a little, it has a way of stirring up questions: Am I failing? Am I not as good as I thought? Do they still trust me?

It's easy to get defensive. Or spiral. Or overcorrect so hard that we lose touch with our instincts. But here's what I've come to believe: receiving feedback well isn't about blindly accepting everything, nor is it about shielding yourself from discomfort. It's about staying centered while making room for growth.

Here's what I've learned along the way:

Pause before you personalize.

Not all feedback is about you-sometimes it's about a moment, a mismatch, or a misunderstanding. Taking a beat before internalizing lets you process the signal without the noise of self-judgment.

Seek the truth in it, not the whole truth.

Even poorly delivered feedback often holds a sliver of insight. You don't need to agree with every word to ask: What part of this might be useful to me?

Anchor to your values.

The stronger your sense of self, the easier it is to hear hard things without being unmoored by them. Feedback might challenge your methods-but it shouldn't erase your identity.

Let curiosity lead.

Instead of reacting with “That's not true,” try “What did you see that made you feel that way?” This opens space for dialogue instead of defensiveness.

Build reflection into your rhythm.

Whether it's journaling, walking, or talking it through with someone you trust-processing feedback isn't a one-time event. It's an ongoing relationship with your own growth.

When we stop seeing feedback as a judgment and start seeing it as a mirror, it stops feeling like a threat-and starts becoming a gift.

We don't grow by avoiding feedback. But we also don't grow by absorbing it all without filters. The real art is in finding the balance: staying open without losing yourself.

Next time: What Happens When You Stop Chasing the Next Title?

Creating a culture of psychological safety is often misunderstood. It’s not about shielding people from hard conversations or protecting them from failure. It’s about creating an environment where people can take risks, can own mistakes, and can give and receive direct feedback, all while holding the bar high and, ideally, raising it even further.

In our team, maintaining and even improving our high standards is a core part of how we think about "not lowering the bar." Psychological safety doesn’t come from letting things slide. It comes from making sure expectations are clear, consistent, and fair. People need to know what "good" looks like, and that part of being trusted is being held to that level.

One of the ways we’ve tried to encourage direct communication is through feedback coaching. We push for concerns to be raised directly between teammates where possible, rather than allowing frustrations to build up in silence. To help normalize this, we’ve incorporated regular 360 reviews, giving everyone an opportunity to give and receive feedback from multiple perspectives.

We even experimented with team reviews at the end of each sprint — not just reflecting on work done, but practicing speaking openly about what helped or hurt the team dynamic. While it didn’t always deliver the results we hoped for, it was part of the learning process. You cannot improve a team’s comfort with directness overnight. It’s a muscle that builds over time, not a box you tick.

Psychological safety and high standards are not opposing forces. They fuel each other when done right. People feel safest when they know their contributions are valued, their growth is supported, and the expectations are real, not just words on a slide deck.

If we want better teams, we need both courage and clarity. The courage to speak and hear hard truths. The clarity to know that the bar will never be lowered to make hard conversations easier.

Next time: Setting Feedback Up for Success — Before the Conversation Even Starts

Redefine What Innovation Looks Like

Not every breakthrough is a moonshot. Sometimes innovation is finding a faster way to deploy, automating a flaky test, or rethinking how a screen flows. Encourage your team to innovate within constraints. Small, practical improvements often stack into meaningful impact.

Ask:

What’s one small thing we could do differently this sprint that would save us time next time?

Create Micro-Spaces for Creativity

Waiting for a hackathon or innovation sprint every quarter isn’t enough. Instead, build micro-spaces for creativity into everyday work:

• Set aside 10% time for experimentation or learning.

• Rotate a creative lead in retros to explore process experiments.

• Host lightning demos of internal tools or side projects.

These little moments keep curiosity alive—even during crunch time.

Celebrate Experiments, Not Just Outcomes

When timelines are tight, there’s a tendency to play it safe. But safe rarely leads to standout ideas.

Normalize the mindset that experiments are wins, regardless of outcome. Make space in standups and sprint reviews to talk about what didn’t work and what was learned. That psychological safety is the foundation of creative risk-taking.

Guardrails, Not Gates

Structure and process aren’t the enemy of innovation they’re the scaffolding. Use lightweight frameworks to give teams focus without boxing them in.

For example:

• Use OKRs to align innovation with business value.

• Define innovation zones where experimentation is welcome (like internal tooling).

• Timebox spikes or discovery sprints so they don’t derail timelines.

Lead by Modelling Creative Confidence

If you want your team to take risks, you have to go first. Share your rough ideas early. Talk openly about past experiments that didn’t pan out. When leaders show vulnerability and creativity, it signals to the team that it’s safe to do the same.

Make Delivery a Team Sport

Tight deadlines don’t mean everyone has to grind solo. Shared pressure builds camaraderie and shared wins fuel motivation. Use deadlines as moments of alignment, not isolation.

Ask:

• Where can we collaborate to unblock each other faster?

• Is this must-have really must-have for this release?

• What would just enough look like?

Speed and innovation both thrive when teams rally around constraints instead of being crushed by them.

Final Thought :

The best teams I’ve worked with didn’t sacrifice creativity for delivery or vice versa. They understood that constraints can inspire invention, and that fostering creativity is less about finding more time and more about using the time you have differently.

Tight timelines will always be a reality. But with the right mindset, structure, and culture, so can breakthrough ideas.

Next time: Balancing Autonomy and Alignment: How to Empower Teams Without Losing Sight of Strategy

Middleware is a feature that lets you run logic before a request is completed. You can use it to:

• Redirect users.

• Protect routes (authentication).

• Modify responses.

• Handle custom headers or logging.

Example: Protecting Routes with Middleware

Imagine you have a dashboard that should only be accessible to authenticated users. Middleware makes it easy to check the authentication token and redirect unauthorized users.

Step 1: Create Middleware

Middleware files must be named middleware.ts and placed in the root of your app.

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  // Check for a token in cookies (example: `authToken`)
  const token = request.cookies.get('authToken')?.value;

  // If no token, redirect to login
  if (!token) {
    return NextResponse.redirect(new URL('/login', request.url));
  }

  // Allow request to continue
  return NextResponse.next();
}

// Specify routes where middleware applies
export const config = {
  matcher: ['/dashboard/:path*'], // Apply middleware to all /dashboard routes
};

Step 2: Test Protected Routes

Now, if a user accesses /dashboard or any subpage like /dashboard/settings, they will be redirected to /login unless they have a valid authToken cookie.

Advanced: Custom Headers and Logging

You can also modify the request or response directly in middleware. For example, logging user details or setting custom headers:

export function middleware(request: NextRequest) {
  // Log the user's IP
  console.log('User IP:', request.ip);

  // Add a custom header to the response
  const response = NextResponse.next();
  response.headers.set('X-Custom-Header', 'Middleware Works!');

  return response;
}

Step 3: Debug Middleware

Run your app locally (npm run dev or yarn dev) and try accessing the protected routes. If you’re using cookies, you can simulate adding an authToken in your browser’s dev tools.

Use Cases for Middleware

1. Authentication and Authorization: Redirect unauthorized users or check user roles.

2. Localization: Dynamically redirect users based on their location or language preference.

3. Rate Limiting: Throttle requests to APIs or routes.

4. Logging and Monitoring: Log request details (e.g., IP address or user agent).

5. Dynamic Content Delivery: Serve different versions of content based on request headers or cookies.

Why This Is Useful

• Performance: Middleware runs before rendering, reducing client-side overhead.

• Scalability: Centralizes logic for route handling and request validation.

• Security: Helps enforce route protection and authentication without cluttering your page code.

Mastering middleware opens up a whole new layer of possibilities in Next.js for building secure, dynamic, and efficient apps!