A Faster Tool Is Not a Faster Team

You buy the licenses. People install the software. There is a demonstration in which a feature appears with suspicious ease. A few weeks later, the organization is still having its usual meetings about why the work is taking so long.

That opening is hypothetical, although it describes exactly the kind of engagement we want people to bring us. The useful work starts after everybody has access to the tool.

What happens to a piece of work between someone deciding it matters and a customer being able to use it? Who must understand it? Who reviews it? What happens when it is nearly finished but nobody can explain one of the decisions inside it?

A coding assistant enters that system. The system is still there after the demonstration ends.

Follow one change

I would start with one ordinary task: something representative enough to expose the work, rather than a carefully chosen problem that flatters the tool.

Follow it from the request through clarification, implementation, review, testing and release. Notice where people wait. Notice what they have to ask twice. Notice which bits of context live in somebody's head and which parts of the repository make a small change surprisingly difficult to check.

I am not arguing for a heavyweight new process. I am arguing for looking at the process you already have, including the parts nobody remembers choosing.

In a hypothetical team, code generation might become quick while review becomes a queue of increasingly large changes. The right response might be smaller changes, better tests or more visible context. Buying another license would not address those particular conditions. Nor would announcing that the team has failed to embrace the future.

People are learning a relationship

At Rankpay, my work included training people to accelerate their development with AI. A large part of the work was helping people get comfortable changing how they worked. That is the part I would take seriously in another engagement.

Someone may have spent years developing a useful instinct for when code feels wrong. A new tool asks them to work with something they did not compose line by line. The old instinct still matters, but it may need a different place to operate.

What should they inspect closely? What can they delegate? How do they recognize a result that is plausible but misses the request? How do they stop and recover when the tool is producing activity instead of progress?

Those questions deserve practice on the person's actual work. They deserve room for doubt. A class that treats hesitation as a character defect is unlikely to tell you much about what is making the person hesitate.

Build what the lesson needs

Sometimes the useful teaching material is software you did not have when the session started.

A project may need a better test command, an easier local setup, a way to collect the context a task depends on, or a narrower interface for an operation that is too easy to get wrong. These are examples of things we would investigate. Every team needs something slightly different.

When building and teaching happen together, the lesson can leave something usable behind. People do not have to memorize a workaround for a tool you could improve, and the work doesn't end at a slide explaining why the workaround is unfortunate.

Agree what better means

Before calling an adoption effort successful, I would agree with the team on what improvement should look like. Faster completion is relevant. So are review effort, escaped mistakes, the ability to maintain the result and whether people understand what they are responsible for.

A number should come with a description of what was counted. Otherwise it is a decoration with a percent sign.

I have described the Rankpay work as a large acceleration over a few weeks. I would not turn that recollection into a general promise for another organization, or into a public multiplier without the measurement behind it. Different work exposes different constraints.

The goal is a team that can do its work better. The tools are part of how we get there. So are the habits, the environment and the people trying to learn without dropping the work they already owe somebody.