The conversation had barely started when the first box was opened.
Around the table sat a group of people who had never met before. Software engineers, AI specialists, technical experts, and me. In front of us were two sets of robotic arms and a brief that asked us to turn them into a startup. By the end we needed a working demo, a business model, a financial plan and a pitch. We had fourteen hours.
I had started asking the people around me which problems they cared about and why. At the other end of the table, the packaging was coming off, the instructions were out and an arm was being assembled. Within minutes the room had two centres of gravity. The discussion that was meant to define our project shrank to a thirty-minute chat.
That half hour decided more about the outcome than anything we built afterwards.
What tech teams do brilliantly
The event was La Machine, a robotics hackathon organised by Tech Makers Amsterdam. The hardware was the Hugging Face SO-101, an open-source arm designed to be trained with AI rather than programmed line by line. Put it in front of a group of engineers and within minutes it is moving.
I want to be precise about what impressed me, because it matters for the argument. When something broke, the people with a software background did more than fix it. They turned the failure into a new possibility. A limitation in the code became an idea for a different use, then a second one. Problems generated options. That is a rare and valuable reflex, and it is exactly why tech teams can build so much, so fast.
The same reflex has a blind spot. It treats the problem as given and starts producing answers. It moves past the part where individuals say what they care about, what worries them, and what would make the next fourteen hours worth their energy. In most engineering cultures that part is considered soft. Under pressure it carries the weight of everything that follows.
The sentence that explained the weekend
Over the course of the day, ideas from the group were often met with the same few responses. “I don’t understand.” “I don’t get it.” When I asked what would work instead, the answers were “I don’t know” and “I just want to build something.”
Then came the most honest sentence of the weekend: “I don’t understand how to connect the building to the concept.”
It would be easy to read that as disengagement. I read it as a precise diagnosis. Building and concept had separated because nobody had connected them together at the start. Someone who did not help define the problem has no reason to care about the answer, and no way to contribute to it beyond objection.
The shift that turns a group into a team is the move from “that doesn’t work” to “what would work”. That shift is participation. It cannot be demanded halfway through a project. It has to be designed into the first hour.
We still delivered. Our concept, sandboxHer, was a founder sandbox for women in tech, built around a robot that is steered by voice and taught by demonstration rather than code. The demo worked, the business model held together and the financial plan was there.
We did not win, and that is not the point. The point is how the pitch felt from the inside. A team that never fully agreed on what problem it was solving cannot defend its answer with conviction. The hesitation was not in the slides. It was in us, and an audience can hear that.
What the first hour is actually for
In my work with teams, the first hour has one job: to take the problem away from the context everyone thinks they already understand, and rebuild it from personal perspectives before anyone writes a line of code.
I usually do this with LEGO® SERIOUS PLAY®, and sometimes with design thinking. The principles behind the LEGO method explain why it suits technical teams in particular. Everyone builds and everyone speaks, so the direction is not set by whoever talks first or codes fastest. People build a model of their own view before discussing anyone else’s, which means individual perspectives are on the table before convergence starts. Meaning lives in the model and its story, so disagreement is about the idea rather than the person. And the build, share, reflect cycle gives engineers something they respect: a structured process with a visible output.
Decontextualising the problem matters more than it sounds. Engineers are trained to solve the problem in front of them. Asking them first to describe what they personally care about, and why, surfaces the motivations that will keep them committed at hour eleven, when the demo is broken and the numbers do not add up. Then the group reconstructs the problem for the job at hand, this time as something everyone recognises as theirs.
I have written before about why this method resists the facilitation shortcut. A hackathon is that shortcut in its purest form. The clock rewards whoever starts first.
Collaboration is a business result
Founders sometimes treat collaboration as a culture topic, something to work on once the product is stable. The evidence points the other way.
Amy Edmondson’s study of work teams found that psychological safety, the shared belief that a team is safe for interpersonal risk, predicted learning behaviour, and that learning behaviour was what drove performance. Google reached a compatible conclusion inside its own engineering organisation: in its research on team effectiveness, psychological safety ranked first among the dynamics that distinguished effective teams, ahead of who was on the team. I have argued before that psychological safety is performance infrastructure, not a cultural luxury. The hackathon was the same argument at fourteen-hour speed.
AI sharpens this further. One engineer with a capable model and an open-source robot arm can now build a surprising amount alone. When building is cheap, the scarce competence moves upstream to deciding what to build and why. That is a team capability, not an individual one. A team that cannot align becomes parallel solo projects sharing a table, and the fastest builder sets the direction by default.
A race lost on the question of what to build
Consider GoPro. It created the action camera category and, according to Japanese retail data reported by Videomaker, went from a 75.5 percent market share in May 2023 to 9.6 percent by November 2025, as DJI and Insta360 shipped better cameras faster. Its annual report for 2025 shows revenue down 19 percent and cites market share lost to competitors.
I have no inside view of GoPro’s teams, and I am not claiming that misalignment explains its decline. What is striking is where analysts locate the cause. The analyst quoted in that report points to an earlier drone venture that pulled research and development away from the core cameras. That is not a story about engineering talent. It is a story about choosing what to build, and those choices are made by people in rooms, long before anyone opens a box.
What founders and CTOs can design
The answer is not to slow engineering down. It is to protect a small, deliberate amount of alignment before the building starts, and to treat it as part of delivery rather than a break from it.
Decide what the first hour of any new project is for before the hardware arrives or the repository is created. Make it explicit that everyone takes part, because alignment that includes most of the team leaves the rest to come back later as objection. Ask each person which problem they care about and why, and make those stakes visible. Treat “I don’t understand” as a signal about the process, not about the person. And measure participation rather than presence: the question is not whether everyone was in the meeting, but whether everyone helped shape what came out of it.
Teams that work this way are better places to work. They are also better businesses, because they can stand behind what they build.
On your last new project, could every engineer have explained in their own words how what they were building connected to the problem it was meant to solve?
