Someone technical on your side of the table

You are not short of information. You are short of a way to check it.

You get updates. They are detailed, they are confident, and you have no way to test a single sentence in them. Most of the time that is fine, because most developers are honest. The problem is that an honest slow team and a team managing you produce exactly the same status report, and you cannot tell them apart.

Who this is for

• You have been told the work is 90% done, and it has been 90% done for a month.
• Every delay arrives with a reason, and every reason sounds plausible.
• You cannot tell whether a task is genuinely hard or just being treated as hard.
• You are paying for a team you have no way to evaluate.
• A supplier's proposal is in front of you and you have no idea whether the price is right.
• You inherited a system and nobody can tell you what condition it is in.

How it works

We do not replace your team, your supplier or your judgement. We give your judgement something to work with.

1. Read

   We look at what exists, not at what is reported

   The codebase, the repository history, the ticket history, the deployment record. How often anything actually reaches production, how long a change takes to go from started to live, what has been rewritten twice. These are facts. A status meeting is not.

2. Report

   You get it in plain language

   One page. What is done, what is genuinely underway, what has not been started, and which of the stated reasons hold up. No architecture diagrams, no vocabulary you have to look up, and no hedging.

3. Questions

   We tell you what to ask, and what a good answer sounds like

   Before your next meeting with the team, you get three or four specific questions and the range of answers that would be reasonable. This is the part that changes the dynamic, because a specific question cannot be answered with a confident paragraph.

4. In the room

   We stay in the room when it matters

   Estimate reviews, proposal reviews, the conversation where a deadline moves. You do not have to relay anything technical, and the team is talking to someone who can check what they say.

What you get

Short, regular and written for you rather than for an engineer.

• An opening assessment

  The state of what you have: what works, what is fragile, what would be expensive to change later, and what it would cost to put right. Delivered in the first two weeks.

• A one-page read, every week

  What actually moved, measured against what was said last week. If nothing moved, it says nothing moved, which is the sentence you are paying for.

• The questions, before you need them

  Ahead of estimate reviews, proposals and any conversation where a date is about to move. Specific enough that a vague answer is visible as a vague answer.

What this is not

This arrangement only works if your team does not experience it as a threat.

We have done this

We have been on both sides of this: we build products ourselves, which is why we know what a reasonable estimate looks like and how long things genuinely take.

• 

  EasyHesap

  Pre-accounting and stock control built for the mobile phone retail market.

• 

  WinningCircle

  A financial education platform giving members practical investment skills, not just theory.

The questions we get asked

• How do I know if my developers are actually making progress?

  Not from the status report, because a report is a claim. Look at things that are produced as a side effect of work rather than described by it: how often code reaches production, how long a change takes from started to live, whether the same area keeps being rewritten, and whether you can open and use the thing that is supposedly finished. Someone has to read those for you if you are not technical. That is what this is.

• My developer says it is nearly finished. How do I check?

  Ask to use it, on a machine that is not theirs, doing the thing a real customer would do. "Nearly finished" that cannot survive that request usually means the remaining work is the part nobody has estimated: the error cases, the edge cases and the bits that only appear under real data. That last stretch is routinely longer than everything before it, and it is where most projects quietly lose a quarter.

• Can you review work from a team we already hired?

  Yes, and that is the common case. We need read access to the repository and the ticket system. We do not need your team's permission to be useful, but we do tell them we are there, because a review nobody was told about produces a defensive team and worse information.

• Will this make my developers defensive?

  Less than you expect, if it is framed correctly. Good engineers are usually relieved: they have been trying to explain a real constraint to someone with no way to evaluate it, and now there is someone in the room who understands what they are saying. The people who object are almost always objecting to being checked, which is itself the answer to your original question.

• Is this a fractional CTO?

  It overlaps, but the job here is narrower and more concrete. A fractional CTO sets technical strategy and often takes over the team. We are not taking over your team, and we are not writing a three-year technology plan. We read the work being done for you and tell you what is true about it, so that you can keep making the decisions you were already making, with better inputs.

• How much of my time does this take?

  About thirty minutes a week to read the page and ask what you want to ask, plus whichever meetings you want us in. The point of the arrangement is to remove work from your week, not to add a second reporting line to it.

Tell us what you have been told

Send the last status update you received. We will tell you what it does and does not actually say.

Start a project

Building the Product for What's Next