frontend
Looking Back at a Year of Leading Devs
Thoughts from the intersection of code, craft, people, and progress.
What I got right, what I missed, and how I’ll improve.
Leadership has a helpful way of exposing the gap between what you intended and what everybody else experienced. Looking back at the year, the most useful lessons came from the moments where I listened properly, communicated poorly or discovered those two things were connected.
The useful question behind “Looking Back at a Year of Leading Devs” is what changes in the work afterwards. A sound idea should improve a real decision, not only give us a neat phrase for describing it.
This matters because small choices repeat. What feels harmless once can quietly become the normal way of working.
Make the work easier to do well
The leadership part is rarely the grand speech. It is the ordinary environment around the work: whether people can ask an awkward question, whether priorities stay still long enough to act on them, and whether useful effort is noticed.
My practical test is simple: after a conversation, does the other person have more clarity and more agency? Good leadership should not make the leader look essential. It should help the team make sound decisions without waiting for permission at every turn.
Leadership is not having every answer. It is making better answers possible.
Trust is built in small, repeatable moments. Say what matters, make space for challenge, and follow through when somebody takes the risk of being honest.
That is not a dramatic conclusion, but useful work is often built from undramatic conclusions applied consistently.