What changes when you stop coding full-time and start leading

For most of my career, “a good day” meant a clean PR, a bug fixed, a feature shipped. Somewhere along the way — for me it was the jump from senior engineer to leading a cross-platform team — that definition quietly changed, and it took me a while to notice.

What actually changes

The obvious thing is you write less code. That part everyone warns you about. What surprised me more was how much of the job becomes making sure other people can make good decisions without you in the room.

At Globant I lead 10+ engineers across iOS, Flutter, and backend, working with clients like OpenBank and Six Flags. Day to day, that looks less like “solve this bug” and more like:

• Setting the architecture so ten people building in parallel don’t step on each other
• Deciding what’s worth a CI/CD pipeline change and what’s over-engineering
• Reviewing code for judgment, not just correctness
• Making goals concrete enough that “we shipped something” and “we shipped the right thing” aren’t the same sentence by accident

What I had to let go of

The hardest part wasn’t technical. It was accepting that the best solution in my head isn’t automatically the best use of my time to implement myself.

I used to measure a good week by what I personally shipped. Now I measure it by whether the team could keep shipping well if I took a week off. Those are different goals, and optimizing for the first one actively worked against the second.

Where the energy goes now

The things I still get hands-on with are the ones that compound: testing strategy, CI/CD, and architecture patterns that make a codebase survive contact with ten different people’s code — Clean Architecture, protocol-based DI, BFF-driven modularisation when a team needs to move independently.

I’m also more deliberate about AI in the workflow than I used to be. It’s genuinely useful for boilerplate and first drafts, but with a team this size I can’t afford output nobody checked — so the review steps and tests that catch bad AI output aren’t optional, they’re part of how the team stays fast and correct.

The actual shift

I don’t think leading is “better” than building — for a long time I assumed it would feel like a promotion away from the interesting part. It doesn’t. The interesting part just moves: from solving one problem well to setting up the conditions where ten people can solve problems well without waiting on you.

That’s the part nobody really tells you in advance. You don’t stop being an engineer. You just start being one at a different scale.