The Telephone Game of Software

By Sam Devine

I've spent most of my working life building things. Houses. A construction company. Canoe trips to Hudson Bay. A resort in Azerbaijan. Podcasts and video for other people's businesses. And for the last several years, software.

The software part started the way it does for a lot of business owners. I had an idea for a tool, I couldn't build it myself, and I went looking for someone who could.

How it used to work

I found a software firm here in Minneapolis. They were good people, and they did what good firms do. They sat down with me, worked through the design, drew up screens, mapped out the logic, and wrote a scope of work. I understood what I was paying for. In that sense it felt a lot like a building project: a plan, a scope, a budget, and then the work.

Then the work started, and that's where it changed.

The firm I hired wasn't building the product themselves. Like many small software firms in Minneapolis and everywhere else, they were managing development teams overseas to keep up with demand. When I started, most of those teams were in India, Ukraine, and parts of South America. The manager here would hand off the work, check what came back, and try to keep everyone on task and headed in the right direction.

I want to be clear about something. I worked with those teams, and I have real respect for their skill and their knowledge. They were good at what they did. What suffered wasn't talent. It was distance. Time zones, language, cultural differences, and most of all, layers.

The telephone game

You probably played the telephone game as a kid. One person whispers a sentence to the next, it passes down the line, and what comes out the other end barely resembles what went in. Nobody did anything wrong. Every person in the line did their best. The message just changed a little at every handoff.

That's what happened to my software.

I explained my vision to the owner of the firm, who understood it fairly well. He translated it for a project lead. The project lead translated it for a few team members. They may have translated it again for several more people who actually wrote the code. By the time anyone was building, my idea had passed through four or five sets of hands, and some of what mattered to me didn't survive the trip.

I knew this from construction

The thing is, I'd seen this pattern before. I spent years as a contractor, and one of the clearest lessons from that work is this: the further the person who owns the vision gets from the people doing the work, the worse the outcome.

On a job site, the best results come when the person who understands what the client wants is standing in the room, looking at the work, and catching problems while they're still cheap to fix. When that person is three layers removed, you end up with walls in the wrong place and a lot of expensive conversations.

Good software and good buildings start the same way. A clear plan. A clear scope of work. A clear picture of the destination: what are we actually trying to accomplish when this is done? And then someone who holds that picture all the way through.

What changed

Over the past couple of years, the tools for building software have changed completely. With modern AI tools, one capable person can now do what used to take a team. I spent about a year learning to build this way, and today I build the tools I used to have to hire out.

That changes more than cost and speed. It changes who holds the vision.

Here's how I work now, and how the best rapid technologists work:

1. We come to you. We sit with the person who has the problem, not their manager's summary of it.
2. We watch the work. How do they actually do it today? Where do they get stuck? What do they wish they could see?
3. We go back and write the plan. We design the tool ourselves and write the scope ourselves, based on what we saw.
4. We build it ourselves. The whole thing, start to finish, using the best modern tools available.
5. We bring it back to the same person. And we adjust until it fits.

One translation instead of five. The person who listened is the person who builds.

Why it matters

We can't eliminate miscommunication completely. People are people. But we can remove most of the handoffs where ideas get lost. And because rapid technologists usually come to this work after other careers, we bring something else to the table: experience running crews, managing budgets, dealing with customers, and solving problems in the real world. We understand your business because we've worked in businesses like it.

That's why I started Rapid Technologists. Not because big firms are bad. They're the right choice for big, critical systems. But for the everyday tools that make a business run better, the best person to build them is the one who sat at your table and listened.