How do you get engineers to actually use a new tool?

What the people we asked said would kill it

When we interviewed 29 engineering leaders and developers, adoption was the objection raised most often — ahead of privacy, ahead of whether the idea worked at all.

"The biggest challenge is getting the individual contributor to click that button."

"People have tool adoption fatigue. They want to prove to themselves that it works before bringing it to the team."

"That whole process of getting a tool set up by everyone, adopted by everyone, isn't easy. So if they're not using it, it'll fizzle out."

"The hurdle is the lower level — individuals. If we want to make it a daily thing, we need to build that into rituals, and make it valuable to the individuals."

That last one is the whole answer, said by someone who'd clearly watched several rollouts fail.

Enforcement is a diagnosis, not a strategy

Two leaders in our research, at different companies, independently used the word "ruthless" about getting people to fill in their status tool. One did the enforcing himself. Another VP put it plainly:

"Can't get my guys to fill in their status reports. Or if they do, to get the right level of detail."

It's tempting to read this as a discipline problem. It isn't. People fill in things they believe are read and useful. When a process requires enforcement, the people doing it have concluded the effort exceeds the value — and they're usually right, because a developer's estimate of whether anyone reads the status tool is generally accurate.

Enforcement also produces a specific failure: compliance without content. Fields get filled with whatever satisfies the check. You've now spent the effort and got nothing.

The three things that decide it

Cost per use has to be near zero

Not "quick." Near zero. There's a threshold somewhere below which people stop weighing whether to do it, and above which every use is a small decision that can go the other way. Two seconds is below it. Two minutes isn't.

A senior leader framed the arithmetic that makes this non-negotiable at scale:

"The tax on me is nothing. But on my group? I'm going to make 500 people spend five minutes doing this. So it needs to work."

This is also why "just add a text box" is the single most damaging feature request in this category. Optional free text is fine. Expected free text converts a two-second action into a two-minute one, and the tool dies.

The person doing it has to get something

Most status tooling is a tax on the people doing the work, levied to produce information for people who aren't. Engineers know this, which is why the reflex response to a new one is resistance.

Two benefits do the heavy lifting here, and both were raised by developers themselves rather than invented by us.

Seeing the teams you depend on. This was the most consistent thing developers told us, and it surprised us — we'd expected pure indifference to status reporting. They were indifferent to reporting their own status. They were not indifferent to this:

"Would be beneficial to see the status of other teams who I'm dependent on."

"I'm impacted by other teams sometimes — seeing how their things are going would be helpful."

Status reporting is built to move information upward. Developers get blocked by things moving sideways — the platform migration, the API another team is meant to ship — and almost nothing in the standard toolkit tells you the thing you're waiting on is in trouble until it arrives late. A tool that surfaces this is giving something back rather than only taking.

Seeing how the rest of your own team feels. Less obvious, and people recognise it immediately once it's described. You have a sense that this sprint isn't going well. Is that just you? Nobody says so in standup, and asking around is awkward.

The spread of responses answers it directly. If everyone else is confident and you're not, you may be seeing something nobody has looked at — which is worth raising, and now you have grounds to. If everyone is quietly worried, the problem is real and shared, and it will surface without you having to be the person who says it. One interviewee described exactly this appeal: "Interested in what other people think about how we're doing."

Beyond those: a shorter standup, and a way to register concern without making it a thing. That's covered in what's in it for the team member — and if a tool can't answer this question, no rollout strategy will save it.

Setup has to be trivial

A leader in our research reduced this to five words:

"Onboarding needs to be ridiculously easy."

Every step between hearing about something and using it loses people. An account to create, a password to choose, a workspace to configure, an admin to petition — each one is a place where someone who was mildly interested stops.

Top-down or team-first?

Both work. They fail differently, and the difference matters.

Top-down gets you coverage immediately, which matters because a portfolio signal is more useful when it covers the portfolio. One leader described a status tool rolled out on the strength of the CEO's personal conviction, and it worked — while that conviction was visibly sustained.

The failure mode is quiet. People comply without engaging, the data looks complete, and nobody can tell the difference between real adoption and compliance until a project slips while its dashboard was green.

Team-first is slower and more robust. The same leader contrasted it with how consumer products spread: adoption starting inside teams that found something useful, rather than arriving as an instruction. Evidence that colleagues find something worthwhile travels further than a mandate, and it doesn't need enforcing.

Our suggestion: start with one team that has a real problem — a project where nobody's sure how it's going. Let it run a month. If the team keeps using it without being reminded, that's the only adoption evidence worth having.

The partial-adoption question

Someone always asks: "Is it meaningful if only 70% of people use it?"

Mostly yes, with one caveat. Seventy per cent of a team is enough for aggregation and enough for a trend, provided the same people respond consistently — a stable subset produces a comparable series. What breaks it is if the non-responders are systematically the people with concerns, which would bias the signal upward.

In practice, low response rates are more useful as a diagnosis than a problem: a team that stops checking in has usually concluded nobody acts on it. That's worth knowing.

How Genchi approaches this

The check-in arrives in Slack, where people already are, and takes one click. There's no form and no required text; comments and blockers are optional.

People invited through Slack can respond without creating an account at all — registering gets them the dashboards and team views, but it isn't required to participate. That removes the most common drop-off point.

And it's free for teams under ten, deliberately: a single team can try it for a month without a purchase, an admin, or anyone's approval, which is the rollout pattern that actually survives.