Technical leadership · September 2026 · 7 min

What does technical leadership look like before the team is large?

A conversation about leading software work while you are still close enough to the code to live with the decisions.

What does technical leadership mean in your day-to-day work?

A lot of it is making an unclear request clear enough for people to work on it without each person building a different interpretation. Institutional needs do not normally arrive looking like a tidy software ticket. There can be a policy requirement, an existing manual process, a deadline and several units that experience the same problem differently.

I have to understand what is actually meant to change before we get too attached to a technical solution. Who will use it, who is accountable for the information, what approvals are real and what will another unit need from the same data later? Architecture matters, but if those questions are still confused, a clean architecture can still produce the wrong system.

You use the phrase “orchestrating development.” What are you actually doing?

I am keeping the work connected from the first requirement through implementation, QA and release. That can mean helping turn a broad request into a scope, identifying which existing parts of the system will be affected, making architecture decisions, reviewing the work and checking that the release still matches what the institution asked for.

I do not think orchestration means I need to write every line myself or make every small decision for another engineer. It means somebody is paying attention to the gaps between responsibilities. If the developer finishes but the permission model is unclear, or QA tests the screen without understanding the policy behind it, then the process has moved but the product has not really come together.

Is that different from the way you work on Tilawa?

There are similarities because both need the whole journey to make sense, but the decision environment is different. With Tilawa, I can make a reversible decision quite quickly, put it in front of testers and learn. In an institution, there are records, approvals, reporting obligations and processes that may continue long after the people currently working on them have moved on.

A shortcut that makes one person’s work easier today can create a problem for another unit at the end of the year. I have to understand those relationships before changing them. It does not mean institutional software should be slow. It means speed has to include enough understanding that we are not automating the wrong version of the process.

How has working in QA affected the way you lead engineering?

It made me ask better questions much earlier. When requirements are vague, testing becomes a debate about what somebody remembers agreeing to. When permissions are considered at the end, they usually feel like something being added around the real feature. By then the feature may already assume that everyone can see or change more than they should.

I try to establish the starting state, the action, who is allowed to take it and what must be true afterwards before implementation goes too far. I also want to know what should happen if the operation stops halfway. Those questions help QA later, but they also improve the design because we are discussing the actual behaviour rather than only the happy path on a screen.

How do you balance leading the work with doing technical work yourself?

I am still learning how to protect both kinds of attention. When I am implementing something difficult, I need time to stay inside that problem. When I am leading, I need to look across the work and notice that a change in one place has created a dependency somewhere else. If I switch between those levels every few minutes, I do neither one particularly well.

What helps is settling the important product and system decisions first, then giving the implementation proper concentration. Before release, I come back out and look across the journey again. Does the permission model still make sense, are the failure cases covered, has the documentation moved and does QA understand what must not regress?

What do you expect from engineers you are leading?

I want them to understand the reason for the work, not only the task. If somebody knows the real constraint, they can make a good decision when they meet something we did not predict. If I only give them a list of instructions, every unexpected detail has to come back to me and the team becomes slower.

Standards still matter. We need a shared way to review, test and release so quality is not different every time. I just do not want a standard to remove judgment. A useful review should make the code and the engineer stronger, not turn into somebody senior proving that they can rewrite everything in their own style.

Do you think a technical lead needs to have all the answers?

No, and pretending to have them can make the team less honest. I do think the lead should know which questions cannot be ignored and should be willing to make a decision when the team has enough information. There are moments for discussion and there are moments when leaving everything open is its own bad decision.

I am comfortable saying that I need to investigate something. What matters is that the uncertainty has an owner and does not quietly become code because everybody assumed somebody else had resolved it.

How do you know when you have led a piece of work well?

Another engineer can explain why the system behaves the way it does. The release does not depend on one person remembering a private list of steps. If something fails, we can investigate it without beginning from guesswork. People know which decisions they can make and which ones need wider agreement.

I do not want a team to prove my importance by needing me in every small moment. I want the work to become clearer, more repeatable and easier for good people to carry together. That is a much more useful result than being the person who touched everything.