How I lead
Decisions, one on ones, roadmaps, on-call and hiring, the same way every time.
I lead small teams, five to seven engineers, and I still ship code. The two go together. The habits below are how I keep a team moving without standing between it and the work. None of them is clever. They are the things I have found worth doing the same way every time, and each one comes with the moment that taught me it.
Technical decisions
A decision worth making is written down: the options, the one rejected, what the choice costs, and the test or measurement behind it. Not as documentation for its own sake. A decision nobody can find is one the team will make again. A decision with its cost written beside it is one the team can reverse on purpose when the cost comes due.
A review asks two questions out loud: what problem is this solving, and is this a good way to solve it. Behind them I am reading for three more, what breaks, what gets slower and what gets simpler, because that is where the debt hides. The questions are plain on purpose. A review that asks something different each time teaches people to guess what the reviewer wants. A review that asks the same ones teaches them to answer before they open the pull request. The same habit sets direction without a reporting line. On more than one project I was the technical lead for one or two engineers who did not report to me. The written decisions were how we agreed on where the work was going.
The library that solved the problem
The second question earns its keep on dependencies. A new library proposed for a one-off piece of functionality usually fails it: the problem is real, but fifty lines we own are a better way to solve it than a package we have to keep current. The clearest case was a developer who proposed a library they had written and published themselves. It solved the problem. It was still the wrong call, because a team should not depend on a package only one of its members can fix, and the choice was between building the small thing in house and finding an existing, vetted one. Nothing about that conversation was hard once the question was on the table.
Flat arrays for the index
The decisions I would point to are public. In the ShelfLens search engine the first index was written the way it reads, a map of terms to lists of postings, each a small object. On the demo catalog it was fine. On a hundred thousand products the benchmark put it at close to 1 gigabyte of memory and a third of a second for the widest queries, with the slowest queries past a second from garbage collection. The record for that decision names the option kept, flat arrays with the result objects built only for the page returned, the option rejected, and the numbers after: 84 megabytes and about a tenth of a second, measured by the same benchmark. Records like it sit beside that code and beside the inventory ledger, each read again against the code before a release.
The cost is time before the first line of code, and a record that has to be kept honest when the code moves. A record the code has drifted from is worse than no record, which is why each one is read again against the code before anything ships.
One on ones
A one on one is for the engineer, not the status report. Status lives in the tracker and the standup, so the time goes to the person: what is in their way, what they want next, and what they need to hear from me. Some weeks that takes ten minutes and some weeks it runs over, and both are fine.
The rhythm is weekly by default. Some people prefer every other week, and I follow their lead, with two exceptions. When someone is on a performance plan, or a big release is close, we meet more often, because those are the weeks when a small misunderstanding costs the most.
The engineer who pushed back on everything
The one on one I think about most was with an engineer who joined my team after a rough year under another manager. That manager had watched every detail, and the engineer had learned to push back on everything, which from the outside looked like a difficult person. For months our weekly meetings were mostly them talking: what had not worked, what they wanted next, and how they liked to be managed. Once we had that figured out, I managed them that way. They became one of the stronger engineers on the team, and that stretch was a good chapter of their career. Nothing about the fix was clever. It was time, every week, spent listening.
The failure mode is the meeting that drifts into status. When I notice one leaning that way, I say so and turn it back to the person. When it keeps happening, we step back together and ask whether that is really the most important thing to talk about in that meeting. Sometimes it is. More often people have just defaulted to work talk, and naming it is enough.
Roadmaps
A roadmap is negotiated, not handed down. The team sees the constraints, says what the work costs, and the plan that comes out is one they own. Ownership is written down where the work is, on the team's Confluence dashboard and on the roadmap boards in Linear, so nobody has to ask whose job something is.
The roadmap is planned at the start of a project and revised with the team each quarter. Between revisions I update it every week or two and check that we are on track. The director of engineering has the final say and sets the requirements for what the applications must do. Working out the order and the approach is mine, with the team and the product owners. Consistent slippage is a signal, not a failure. When I see it, I sit down with the team to find out what is in the way and what should move, and the plan changes.
70 percent on time to 90
On-time milestone delivery went from about 70 percent to about 90, and the change was not pressure. It was clearer ownership, honest priorities, and a plan the team had written with me.
The cost is speed at the start. A negotiated plan takes longer to make than a dictated one. It is faster by the end, because the people carrying it out never had to be convinced.
On-call
On-call is a design input, not a rota. The observability is set up before the schedule is, and the team that builds a system is the team that answers for it. A quiet rotation is earned by the work done before anyone's phone rings.
A rotation without pagers
On an earlier team we ran a rotation without pagers, only a published schedule and everyone's phone number. Each day had a primary and a secondary, the primary rolled to secondary the next day, and with enough people on the rotation each person's turn came around every couple of weeks. The schedule was published at least a month ahead, and when someone had time off they said so and a teammate took the shift. The main concern was a service or a server going down, so the work that mattered happened before any call: observability with New Relic and custom metrics, and the debugging of latency, congestion and network limits that made calls rarer.
Where there is no standing rotation, the same idea takes the form of standards: the testing and observability the team builds against, with Datadog and CloudWatch, and the retry handling and throttling that cut rate limit failures by about 70 percent. When a big release or an event means a late night or a weekend, it is planned and shared ahead of time, never sprung on anyone.
The cost is that the work is invisible when it succeeds. Nobody notices the call that never came, which is why it is worth saying out loud which change kept the phone quiet.
Hiring
I hire deliberately: a written bar before the first interview, the same screen for every candidate with technical rounds written for the role, a decision made on evidence, and a process that keeps moving. A slow one loses the people worth hiring.
The changes that worked best were about feedback. We standardized the first screen. Every interviewer writes notes and a score with reasons, so a decision rests on what was observed rather than on who spoke last in the debrief. At least two people sit in each interview, which makes the rounds faster and the feedback better. The whole process still takes a few weeks, but a candidate hears from us within days of each round and moves to the next one as soon as there is a decision, so nobody is left wondering where they stand.
The bar that was stricter than the written one
The thing I did not see at first was that some interviewers were holding candidates to a far stricter bar than the one we had written down, and good people were being turned away for reasons that would not have survived a discussion. The scores with reasons are what made that visible, and once it was visible it was settled in one conversation.
Onboarding is part of the hire. On the most recent team I hired for, it went from about 8 weeks to about 5, which is the difference between a hire that pays off this quarter and one that pays off next.
The cost is time up front. A written bar and two interviewers per round cost hours before the first candidate walks in, and a role sometimes stays open a week longer for it. I have never regretted that week. I have questioned a fast hire.
The habit under all five
Each of these is the same habit: remove ambiguity before it compounds. A written decision removes it from a choice, a one on one from a person, a roadmap from a plan, a rotation from a night, a written bar from a hire. The record behind all of it, with the employers and dates, is on the career history page. If you are hiring for a role where that would help, email jasonsdevspace@gmail.com and we can talk about whether I am a good fit.