The short version
- The first month has a shape. Week one is listening and reading. Week two is naming the real constraints, out loud. Week three is one decision, made and written down. Week four is a way of working the team keeps.
- Early value looks like subtraction. Something stops, something gets decided, ambiguity is removed. A flurry of new documents and tooling is a warning sign, not progress.
- There are things this cannot do. It is not a rescue for a team that needs three more engineers, and it is not a substitute for a founder who will not delegate.
- You may not need it. Some situations call for a permanent hire, and some call for nothing at all. Both are covered below, honestly.
What fractional product and technology leadership means here
Fractional means senior product and technology leadership for part of the week, with real accountability for the decisions — not a report handed over at the end, and not an interim executive covering a vacancy. It is judgement, scoped to the company that hires it. There is no standard shape, because the constraint it exists to remove is different in every company; the first month described below is the closest thing to a constant.
Appaya is my studio. I have spent more than fifteen years leading product and technology, most of it in UK regulated fintech; the longer history is at lukeczak.com. This page is deliberately not about credentials. It is about what the work looks like from the inside, so you can judge the shape of it before you judge the person.
Week one: listening and reading
The first week produces nothing visible, and that is by design. Anyone who arrives with recommendations in week one is reciting what worked at their last company. The real work is reading and listening, specifically:
- The backlog, end to end. Not a summary of it — the actual tickets: how old they are, which have been reopened, which have comment trails that go quiet mid-argument. A backlog is an honest diary of how a team really makes decisions.
- The incident history. What broke, what recurred, and what the write-ups blame. A team that has blamed the same component three times has a constraint nobody has named.
- The last three things that shipped late, traced properly. Not the stated reason — the actual sequence. Late work is almost never slow work; it is usually work that waited: for a decision, for a review, for one specific person, for an environment. Where it waited tells you where the organisation is stuck.
- The standup, sitting quietly. Who speaks, who never does, what gets raised and what visibly does not.
- One-to-ones with every engineer, and with whoever owns revenue. Engineers usually know exactly what is wrong. It is often the first time anyone has asked them plainly.
- The release process, done once. Shipping something trivial, or watching it shipped, to feel the friction first-hand rather than hear about it.
By the end of week one I have a private list of what appears to be true. It stays private for now, because first impressions are confidently wrong in predictable ways, and the next week exists to test them.
Week two: naming the constraints
Week two is saying, out loud, what the two or three real constraints on delivery are. There are rarely more than three, and they are rarely purely technical. The patterns that recur: decisions with no owner, so they get relitigated weekly; one engineer everything routes through; a roadmap that is actually a wishlist sorted by whoever asked loudest; a founder approving so much that approval has become the bottleneck.
This is usually where it gets uncomfortable, because the constraint is often in the room when it is named. The naming has to happen out loud, to the people involved — not in a deck circulated afterwards. Done with respect, it is the most valuable thing an outside leader does all month: everyone inside the company has usually known the constraint for a year and been unable to say it, because they report to it, or sit next to it, or are it.
The test of week two is whether the naming survives contact. Pushback with evidence is the system working — some of my week-one list will be wrong, and I want it corrected before anything is built on it. Silence is the worrying response.
Week three: a decision, made and written down
The difference between advice and leadership is that a decision gets made. Week three is one decision that unblocks delivery — not five, one. The shape varies: pausing a second product line for a quarter so the first one ships; stopping a half-finished replatform and committing to the stack that exists; choosing the unglamorous option for a piece of infrastructure and closing the debate; declining a custom feature that would quietly derail the roadmap.
Often the decision is the founder's to make, not mine — the job is to shape it so it is takeable: lay out the options honestly, say which one I would take and why, and absorb some of the discomfort of taking it. Then it gets written down as a short decision record: what was decided, why, what was considered and passed on, and what evidence would change our mind. The writing down is not ceremony. An unwritten decision gets remade every time someone new joins the argument, and a team that relitigates its decisions ships nothing.
Week four: a way of working the team keeps
The last week of the first month is about making the previous three survivable without me. Not a methodology rollout — small, boring mechanics: a weekly rhythm where the team commits to a little and reviews honestly; a definition of done that is observed rather than laminated; decision records as a habit that outlives the person who introduced them; a roadmap short enough to be true.
The test of week four is not what happens in it. It is what happens in week six, in a room I am not in: whether the constraint stays named, the decision stays made, and the rhythm holds. Fractional leadership that only works while the leader is present is dependency wearing a nicer name.
How to tell, within a fortnight, whether it is working
You should not need thirty days to know. By the end of week two, look for:
- Engineers saying things to the new person that they have not said in standup — the clearest early signal that the listening is real.
- At least one uncomfortable truth named out loud, with you in the room. If everything still feels pleasant by day ten, worry.
- A short written list of constraints that you recognise as yours — not a generic diagnosis that could describe any company.
- Something that has stopped: a project paused, a recurring meeting cancelled, a decision unwound. Early value is subtractive.
And treat these as warning signs: a flurry of new documents, proposals for new tooling, a reorganisation sketch in week one, or a leader who has not yet spent an hour with the actual work. Those are the motions of leadership without the substance.
What a fractional CPTO cannot do
Some of this is obvious once said, and all of it is regularly sold anyway.
- It is not a rescue for a capacity problem. A team that needs three more engineers needs the engineers. Leadership removes waste around the work; it does not compress the work itself, and there is only so much waste. If capacity is the real constraint, the honest move is to say so in week two — not to absorb months of engagement pretending otherwise.
- It is not a substitute for a founder who will not delegate. If every decision still routes through you after a month, you have hired an audience, not a leader. That failure is worth predicting early: if you cannot imagine letting someone else make a product call that turns out wrong, you are not ready for this, and no fractional arrangement fixes it.
- It is not full-time presence. Part of the week means choosing what to be present for. Things will happen on the days I am not there; the way of working in week four exists precisely so that they can.
- It does not create product-market fit. It can sharpen how you search for it, and stop the search being derailed by delivery chaos. It cannot substitute for the search.
What the engagement should leave behind in writing
Whatever else happens, a fractional engagement should leave artefacts that survive it. For the first month, the honest minimum is:
- A constraints memo — the two or three real constraints on delivery, in plain language you recognise as describing your company.
- Decision records for each significant call: what was decided, why, what was passed on, and what would change it.
- A way-of-working page the team actually follows, short enough to be read.
- A hiring spec, if hiring is the conclusion — the role, the seniority, what to ask in interviews, and what a good answer sounds like.
If an engagement ends and nothing survives in writing, it was presence, not leadership. Ask anyone you are considering — me included — what they left behind last time.
You may not need this
Some situations genuinely call for something else, and it serves nobody to pretend otherwise.
- Technology is the company's core bet. If the hard technical calls ahead of you are the company — deep infrastructure, novel modelling, a platform play — you need a full-time owner of that bet in the building. Hire permanently, and take your time doing it well.
- The gap is delivery capacity. Hire engineers first. Revisit leadership when the constraint moves, which it will.
- The team is senior, shipping, and honest with itself. Then the right amount of additional leadership may be none, and the kindest thing an adviser can say is that things are working.
- The board wants a title on a slide. That is a governance conversation, not a leadership gap. Solving it with a fractional hire gets you a name, not an outcome.
I would rather say any of these in a first conversation than discover them in month three. An engagement that should not exist does not become good by being run well.
If you want to talk
Appaya's fractional engagements are scoped in a conversation, not sold off a shelf: what is stuck, what the first month would look like in your company specifically, and whether the shape fits at all. If the honest answer is a permanent hire, or nothing, that is the answer you will get — this page should make it clear I regard both as good outcomes.