Flock is reportedly offering buyouts after a backlash hit 'internal morale'. The question that asks what you were measuring.
On September 19, 2026, TechCrunch reported, citing a report in Wired, that the surveillance technology company Flock Safety had unveiled a "generous" severance package for voluntary employee departures on Friday. According to TechCrunch, Flock reportedly expects a significant portion of its 1,500-person workforce to express interest in the buyouts, and said it will grant them to a majority of those who are interested; the company's internal announcement described the packages as the "most generous" it has ever offered. Wired also reports, per TechCrunch, that without buyouts the company would "almost certainly" need to lay off some staff. The backdrop is a backlash over Flock's license plate recognition technology. TechCrunch noted that in August The Washington Post identified 46 cases where police officers have been accused of misusing Flock technology, that Florida and Texas both said they will stop using it, and that an anti-surveillance advocacy group identified 90 cities that dropped Flock in August alone — a fourfold increase from the previous month. TechCrunch said it had reached out to Flock for comment.
The detail worth slowing down for is a remark from the CEO. Garrett Langley, TechCrunch reported, recently told the All-In podcast that the "biggest damage" caused by the backlash has been to "internal morale." The report says nothing about what Flock tracked internally, and it would be wrong to guess. But the shape of the remark is familiar to anyone who has run a project: the cost that mattered most arrived somewhere the plan had no line for. A project can be succeeding on every number chosen at kickoff while the damage accumulates in a place nobody decided to look. Deciding where to look is a behaviour, not a topic, and it is the behaviour this question tests.
Why they ask it
The question — How do you measure the success of a project? — sounds like a request for a framework, and weak candidates supply one: a goal-setting system, a north-star metric, a dashboard. At the manager level, interviewers are asking something narrower. They want to know whether the candidate chose the measure or inherited it, whether it was fixed before the work began or fitted afterward, and whether the candidate knows what the measure could not see.
A manager who defines success after the fact can declare anything a success. A manager who defines it beforehand, and then reports honestly against it, is showing the interviewer how they will report upward when the news is mixed.
There is a further read. The measure a person reaches for reveals who they think the project was for. Shipping on schedule is a measure for the team. Adoption is a measure for the user. Fewer escalations is a measure for the organization around the project. None of these is wrong, but experienced interviewers notice which comes to mind first.
The trap
The first trap is answering in the abstract. The question is phrased generally, so candidates answer generally: a philosophy of measurement with no project in it. That answer can't be wrong, which is exactly why it earns nothing.
The next trap is subtler: listing only delivery measures. On time, on budget and in scope describe whether the work was delivered, not whether it succeeded. A project can hit all of them and change nothing.
The last trap is the clean scoreboard. An answer in which every metric moved the right way and nothing was missed reads as either luck or editing. The strongest answers include a measure that was added late, because something surfaced that the original set could not see.
Applying STAR-T
Treat the question as behavioural despite its phrasing. Pick a project where the definition of success was contested, or changed partway through, and let the principle emerge from the story.
Situation. Keep it short and name the ambiguity. Our support tooling migration had an executive sponsor who wanted it finished by quarter end, and a support floor that had been burned by the last tool change. The job of the situation is to establish that success was not self-evident, and that different people would have scored it differently.
Task. State the measure you committed to, and when. Before kickoff I wrote down what done would mean: handle time no worse than the old system within a month of cutover, the migration finished inside the quarter, and agents choosing the new tool without being told to. The last item is the interesting one, because it is hard to count. Say so.
Action. Describe how you measured, especially the thing that resisted measurement. Handle time came from the system. Agent preference didn't, so I sat in on shifts every week and tracked how often people kept the old tool open in a side window. Midway through, handle time looked fine but side-window use was climbing. I paused the rollout to the next queue and spent the sprint on the search function the agents kept leaving for. This is the centre of the answer: a leading signal, noticed because someone went looking, acted on before the lagging number moved.
Result. Report against the original measure, misses included. We finished a few weeks past quarter end. Handle time matched the old system inside the window. Side-window use dropped to near nothing, and the old tool was switched off without a petition to keep it.
Trade-off. Name the cost and own the choice. I missed the sponsor's date on purpose. I told them the week I made the call, with the side-window numbers in hand, and I would make the same call again: a migration delivered on time to a floor that refuses to use it is a project that has to be run again.
The follow-up that breaks weak answers
The follow-up is some form of what did your measure miss? Occasionally it arrives as how did you know the number was telling the truth? Either way, it separates candidates who chose a metric from candidates who were handed one. A borrowed metric has no known blind spots, because its owner never had to defend it.
A strong answer names a specific gap without flinching. We never measured what the migration cost the engineers who ran it. Weekend cutovers were treated as free, and they weren't; I heard about it in a retro a quarter later. On the next project, the team's own load was on the scoreboard from the start.
Langley's remark is a version of the same admission. By his account, the biggest damage landed on morale, a thing that rarely has a line on a project plan. An interviewer asking how success was measured is, underneath, asking whether the candidate would have found that line before someone else had to name it.
Score your answer against the director’s bar
Q: How do you measure the success of a project?
Bank the project where your definition of success changed midway, and rehearse it until the question about what your measure missed has a ready answer. Try it free →