Maciej Nuzia · Advisory
A team can close tickets efficiently while decisions about architecture, security and releases keep being postponed. As a fractional CTO, I organise those areas, set the technical direction and help the team make decisions that will affect the product beyond the current sprint.
If it turns out you need someone full time, you will hear that on the call.
Signs
They all describe the same thing: technical decisions are being made by accident.
These are not the signs of a weak team. The team is doing exactly what it was asked to do. They are the signs of a team with nobody accountable for the whole.
Scope
We settle the scope on the first call, because it depends on what you already have in order. This is the list of what I take responsibility for in this role, consequences included.
What the product runs on and why, what can wait, and what has to be settled before the next feature lands. That includes decisions made earlier, the ones that cost time on every change today. Some of them are left alone on purpose, because fixing them would cost more than living with them. What matters is knowing which ones those are.
Who has access to what, what happens to a session after logout, which libraries carry publicly known vulnerabilities. OWASP is the reference point, and releases set the rhythm: every sizeable change is an occasion to check whether something got opened up along the way.
What has to happen before a change goes out, how to roll it back, and how to tell that something is wrong before a customer writes in.
How a feature should be built, what happens to it once it is in production, and who keeps it running. Maintenance is part of the same job and keeps the same owner once the feature is half a year old.
Sometimes that calls for a meeting. Sometimes it takes one person who has made that call before and can say what to expect from it.
How the work runs
We settle the number of days and the billing model on the call, because settling them in advance would be guesswork. A team that is still putting a release process together needs me for different things than a team that already has one and is looking for somebody to make architecture decisions.
The cadence follows the size of the team, how often decisions come up that nobody wants to make alone, and whether something big is running in the background: a migration, entering a new market, a security questionnaire from a large customer. We agree the cadence at the start and correct it along the way when it turns out to be too sparse or too heavy.
There is also the question of what can be raised between one contact and the next. Availability has limits, and I say plainly where mine are.
I work in your team's channels. If the team talks on Slack and in comments on changes, that is where I am. A technical decision often gets made in a comment on a change, and that is exactly where I need to be.
How I know this
In the systems I lead, I am responsible for:
These decisions return with later changes and releases. I therefore assess them from the perspective of future maintenance, not only the next task.
Talk
Start with whatever hurt most recently: a release that had to be rolled back, or a question nobody on the team could answer. There are times in the calendar, and I read the mail myself.