Green on the dashboard, red in reality: what a tech lead does, and what the interviewer listens for

The tempting reading is that someone misreported. The book argues the opposite: in the launches it describes, false green is rarely a lie. More often it is the truth, produced by the wrong instrument.

People act on the measurement system they are handed. If the dashboard rewards closed tickets, teams close tickets. If integration evidence is optional, integration happens late, because under deadline pressure optional work usually does. Each team reported what it controlled and what it was asked for. The user experiences the path between those reports, and nobody was measuring the path.

There is an incentive under it too. Local completion is easier to prove and safer to claim than integrated behavior, and a team can say "our part is done" truthfully without owning what happens when the parts meet. Support and operations often see the integrated reality first, and what they see gets treated as anecdote because it does not arrive in the shape the dashboard accepts.

In an interview, this paragraph is worth a sentence. A candidate who blames the teams for misreporting has diagnosed people. A candidate who says the reporting system measured the wrong thing has diagnosed the system, and that is what the interviewer wants to hear from someone who will run one.

The request arrives every week: "Can you confirm we are still on track?" Before the Room's method is to look for the decision under a request before answering it. Under this one sits a decision nobody has made: what evidence is allowed to count as green. Until that is decided, the book says, the color is a mood.

Two details make this practical. The first is timing. Raise the evidence question for the first time in the final review and you are the person who blew up the launch. Raise it a week out, while there is room to fix what it exposes, and the same question reads as leadership.

The second is ownership. A program owner often holds the dashboard while a tech lead holds the integration evidence. If the two never agree on what green requires, the dashboard wins by default, because everyone already looks at it. Getting those two owners to agree on one definition is the actual work.

The move is to replace activity status with outcome evidence, specific enough that nobody can drift back to closed tickets. The book's tool is a truth test, three lines long:

• The outcome, as the customer or operator will meet it.
• The smallest proof that it exists outside any single team's boundary.
• The conditions that proof has to run under, and who runs it, by when.

The middle line is the hard one, and it is always concrete. A real client completing the flow against the intended backend path. A rollout working for one production segment with rollback available. Support running the recovery path without the original engineer present. Old and new schemas coexisting through the compatibility window you plan to use. Monitoring catching a failure before a customer reports it.

On mobile the path is longer than the code, which is why "conditions" matters. The release sequence includes store review that nobody outside the store controls, a binary that cannot be recalled once it is on phones, and older app versions still in use. A proof that ran only on the newest build, against a backend that older builds will never see, has not tested the path users will take.

Until the truth test passes, the status is not green. The precise phrase the book gives for that state is the one to learn: locally complete, integration unproven.

"This is not green" attacks the teams and invites a defense of everything they built. "The work is locally complete and the integration is unproven" keeps the work and moves the argument onto evidence, which defensive people can accept. Interviewers notice which of the two a candidate reaches for, because it predicts how status meetings go with that person in them.

The book adds a second line for when the color fight starts anyway: local implementation is green, outcome evidence is amber, and the launch decision depends on whether the sponsor accepts the unproven path. That moves the conversation off green versus not green and onto whose risk it is.

A verbal redefinition of green rarely survives the week, because everyone who was not there renegotiates it. Two objects hold it, and both belong in front of the sponsor before the readiness meeting.

The first is an outcome evidence table: each piece of proof the launch depends on, its owner, its due date, the result, and the decision that result triggers. A row reading "rollback path tested, release owner, Friday, partial" leads to a decision: launch only the paths rollback covers. The unproven rows are the point. In the book's words: "'Not run' is a gap, not an accusation, and a gap with an owner and a date has a path to closed."

The second is a set of status definitions, so the colors stop drifting:

The dashboard can still show local completion. The launch color follows the evidence. And the first real win is often a better amber: a team that reports accurate amber early is worth more than one that reports confident green and surprises everyone at the gate. That only lasts if the status system does not punish early amber, which is something a manager or sponsor has to protect.

To keep those definitions in force every week, not only at the launch gate, the engineering status update template turns them into a weekly update, with the end-to-end evidence as one field of its own.

What does not work: asking every team to add risks to the weekly report, which measures local progress with more words around it; a confidence score, which dresses a feeling up as a number; and challenging the optimism head on, which buys defensiveness.

What works names the evidence gap, names the decision and keeps the local work intact, said to the sponsor before the readiness meeting. The book's version opens with "The work is locally complete, but the launch path is not proven", recommends moving the status to amber until one production-like end-to-end path succeeds with the release sequence, permissions and rollback the team actually intends to use, and then states the decision plainly: whether launch status is based on ticket completion or on integrated outcome evidence.

It ends with a threshold set in advance: if that evidence does not exist by a named day, readiness stays amber and the sponsor gets a choice between delaying, reducing scope, or launching the unproven path as a named risk they accept. That is the shape an interviewer wants to hear: evidence, a decision with an owner, a date, and options.

Candidates sometimes tell this story as if the goal was to stop the launch. It was not. The sponsor can look at amber and launch anyway, because sometimes waiting costs more than the gap. What changes is that the risk is named and owned. The code can be identical and the event still differs: when a named risk lands there is an owner and a plan, and when a hidden one lands there is a surprise and a hunt for whose fault it was.

The book is direct about where the tech lead's job ends: at making the risk visible and owned. Acting as though the launch call is yours is how a status conversation turns into a status war. In an interview, saying who made the call, and that you supported it, scores higher than a story where you single-handedly held the date.

The strong column is not a more dramatic story. It is the same four days with an instrument that measures the outcome and a decision that has an owner.

Before the Room gives one level line for this situation, and it fits an interview answer closely:

For a senior role, "I ran the whole flow myself four days early and found the permission case" is a strong answer. Do not stretch it into a staff story about changing how the organization reports status unless you did. For the wider set of tech lead questions, see the guide to mobile tech lead interview questions.

• "Who said it was green, and why did they believe it?" Tests whether you diagnose the instrument or blame people.
• "What exactly would have proved it was green?" Tests whether you can name the smallest end-to-end proof.
• "When did you raise it, and to whom?" Tests timing and whether you found the decision owner.
• "How did the teams react?" Tests the language you used.
• "What if the sponsor had launched anyway?" Tests whether you know whose call it was.
• "What changed in how the next project reported status?" Tests whether the fix outlived the launch.

• When you blamed a team: "To be fair to them, they reported what they were asked for. The status asked about tickets, not about the path."
• When you raised it late: "I raised it at the final review, which made it look like an ambush. A week earlier, with the evidence table, it would have been a planning input."
• When you cannot name the proof: "The smallest proof would have been one production-like run of the whole flow, with the release sequence and permissions we intended to use."
• When the launch went ahead and failed: "The sponsor accepted the risk by name, so the review was about the gap, not about whose call it was." Use it only if that is what happened.

An accurate story with a gap beats a smooth one that collapses at the second follow-up.

The book names the boundary itself. A truth test proves the path runs end to end. It does not prove you built the right thing: integrated evidence can pass while the product still misses the need it was meant to serve. Saying that out loud, when an interviewer asks what your process does not catch, is a mature answer.

And the residue is real. Some teams will keep a private green on their own dashboards, and the first amber you report may cost you a tense week with a sponsor who liked the old color. For the daily habits that keep your own status honest before any program review, see the engineer nobody chases; for the incident version of this story, see telling a production incident story.

How do you answer "how do you know a project is on track?" in a tech lead interview?

Separate local completion from the integrated outcome. Say what evidence you would accept as green: the end-to-end path running under the conditions you intend to launch with, rollback tested, and support able to recover without the original engineer. Then say who owns each piece of that evidence and when you check it. Ticket counts and burn-down tell you about activity, not about the path the user experiences.

Is reporting amber disloyal to teams that finished their work?

Not if you say it precisely. "The work is locally complete and the integration is unproven" keeps every team's work intact and moves the conversation onto evidence. "This is not green" attacks the teams and invites a defense of their work. Interviewers listen for the first kind of sentence.

What if the sponsor decides to launch anyway?

That can be the right call, and it is theirs to make. Your job ends at making the risk visible and owned: the unproven path is launched as a named risk that the sponsor accepts in writing. What you remove is the ability to take that risk by accident.

What is a truth test?

A three-line check from Before the Room: the outcome as the customer or operator will meet it, the smallest proof that it exists outside any single team's boundary, and the conditions that proof has to run under. Until it passes, the status is not green.