I wrote my first production PHP in 2012 at Chillizone, a junior developer fixing bugs on other people’s websites. Today I run technical projects at Adcom Zenith. Looking back across five companies, the promotions never came from the code — they came from three behaviors that had nothing to do with syntax.
First: writing things down. At Orient McCann I started documenting requirements and user stories simply because I kept forgetting details. Stakeholders noticed that projects I documented had fewer surprises, and suddenly I was in the planning meetings. Documentation is invisible work with extremely visible results.
Second: owning the whole outcome, not the ticket. At HTV and East River I made a habit of understanding why a feature was requested before building it. Half the time the real need was simpler than the request. Developers who push back with a better option get remembered as partners, not resources.
Third: making other people faster. The shift from senior developer to leadership happened the day I realized my job was no longer to be the best coder in the room — it was to remove whatever was blocking the room. Unblocking someone else’s week beats optimizing your own day, every time.
The code still matters — you cannot lead technical work you do not understand. But the code is the entry ticket, not the ladder. The ladder is trust, and trust is built with the three habits above, repeated for a decade.
Writing things down is not admin work
The reason documentation gets treated as overhead is that its benefit lands on someone else’s desk. You write the requirement; the person who avoids building the wrong thing is a developer three weeks later. That delay is exactly why juniors skip it and why it is such an effective way to stand out.
In practice it is unglamorous. A short note after every meeting saying what was decided and who agreed. A user story written in the language the business used, not translated into technical terms that only you can check. A list of the assumptions you made because nobody answered your question in time. That last one is the most valuable document on most projects, because it turns a silent risk into something a stakeholder can correct in thirty seconds.
None of this requires permission. That is the point — you can start doing it on your current ticket, today, without anybody promoting you first.
Owning the outcome means asking why
The habit here is a single question asked before estimating anything: what is this for? Not as a challenge, but genuinely. Requests arrive already translated into a solution — the client has decided they need a filter, a dashboard, an export — and the translation is usually where the complexity got added.
When you ask what problem it solves, one of three things happens. Sometimes the answer confirms the request and you build it faster because you understand it. Sometimes a simpler solution appears that takes a fraction of the time. And sometimes the request quietly disappears, because saying it out loud revealed it was not needed.
Developers who do this get remembered as partners rather than resources, and the difference shows up in who gets consulted before decisions rather than after them.
Making other people faster
This is the hardest shift, because everything in a developer’s training rewards personal output. You get good at solving problems, then you get promoted for solving them, and the instinct is to keep solving more of them yourself.
The reframe that helped me was simple arithmetic. If I spend a morning unblocking four people, the team gains more than my best morning of coding ever would. Reviewing a pull request properly, writing the setup guide nobody has written, sitting with someone stuck on an environment issue — none of it appears in your commit history, and all of it compounds.
It also changes what you notice. Once your job is the room rather than the ticket, you start seeing the repeated blockers: the deploy that always breaks, the handover that always loses information, the decision that always takes a week. Those patterns are invisible when you are heads-down on your own work.
What the code is actually for
None of this means the technical skill stops mattering. You cannot lead work you do not understand, and a technical lead who has lost touch with the codebase makes decisions that look reasonable in a meeting and cost weeks in practice. The credibility to say a deadline is unrealistic comes from having built the thing before.
But the code is the entry ticket, not the ladder. Nobody was ever promoted for writing a more elegant loop. They were promoted because people trusted their commitments, and trust is built the slow way — by saying what you will do, doing it, and saying so when you cannot.
If you are early in this
Pick one of the three and do it consistently for a quarter. Documentation is the easiest to start and the fastest to be noticed. The other two follow naturally, because once you are writing down decisions you start asking better questions, and once you are asking better questions people start bringing you problems earlier.
A decade sounds like a long time. It is really just the same three habits, repeated until they stop feeling like effort.
