Generating momentum

These are my notes from a talk and hands-on workshop I gave at Soeltech. The slides were in Portuguese. This is the same argument in English, in the order I presented it.

Momentum comes from the Latin for movement, impulse, driving force. It's movement that gains strength as it continues, so that each step forward gets easier than the one before.

The talk opened with two pictures.

A healthy project recovers after every delivery

Delivery over time. Each release is followed by a week of recovery, and the next climb starts higher.

An engineer's week

Joy and pain, day by day.

And then with one question.

How does a small group turn an idea into useful software with less coordination?

Part 1. Process and decisions

Don't outsource your decisions

When you build with LLMs you're already outsourcing some things. Your decisions shouldn't be among them.

"Spotify uses squads." "Google does it this way." Neither company has your context. Studying other companies is useful. Copying their conclusion without the conditions that produced it isn't. The useful question is what problem they were solving, under which constraints, and which principle I can test in my own context.

The process belongs to the team doing the work

Individuals and interactions over processes and tools.

That's the Agile Manifesto, 2001. It asks us to trust motivated people, let teams organize themselves and reflect regularly to adjust how they behave. If the team is supposed to adjust how it works, the team has to be able to change the process.

The irony is that Agile became an industry of certifications, job titles and consultancies. The question changed from "how do we work better?" to "are we doing Scrum correctly?"

Who decides what

Real autonomy needs a clear split.

The manager, from router to facilitator

Responsibility without authority creates executors

"You're responsible for the result, but I decide how to get there." When something goes wrong, the answer becomes "that's what I was asked to do."

The more responsibility someone carries, the more authority they need over the path.

Trust is horizontal too. A small team owns the whole problem, and nobody owns only "the frontend part". Pair programming and review during the work shorten the gap between making something, discussing it and correcting it.

More people, more coordination

Twenty people have 190 ways to talk to each other

Possible channels between n people: n(n−1)/2.

Adding a person adds capacity. It also adds communication, dependencies and waiting. Linear uses teams of two to four people per project. At 37signals it's a designer and one or two programmers.

Part 2. Small teams

Lockheed, 1943

Kelly Johnson's team at Skunk Works designed and built the XP-80 fighter in 143 days. Johnson's rules asked for one person in charge with real authority, a team much smaller than the standard, little administration, direct communication and trust between customer and team.

I wouldn't take the 14 rules from this. I'd take the question behind them. What is stopping these people from solving the problem directly?

Facebook

Jordan Walke created React out of real problems in the ads interface. React Native started at a hackathon in 2013, and three people wrote much of the first Android runtime. The idea was proven with real use, not with presentations.

A question for the room. Would that idea survive in your team? Was it in the sprint? Did it have an issue, an ROI, an architecture approval?

Nepal, 2025

The Gen Z protests were organized over Discord with no declared central leadership. Human Rights Watch reported communities reaching tens of thousands of people within days.

There are two lessons. Coordination doesn't require someone handing out every action. But without structure there are no shared rules and no way to correct course, as the Carnegie Endowment's analysis pointed out. Autonomy doesn't remove the need for structure.

Linear and 37signals

Cadence isn't a law of nature.

The pattern across all of these is context, trust, autonomy and feedback.

An aligned group coordinates its actions without anyone coordinating each action.

Part 3. Engineering and agents

Mistakes have to be cheap

Extreme Programming gave us pair programming, TDD, small releases, continuous integration and refactoring. None of it is ceremony for managing people. These are practices that let autonomous people change software without losing control of it.

A wrong decision that takes six months to discover is a disaster. A wrong decision that takes thirty minutes to discover is learning. We don't need to be right more often. We need to find out sooner. DORA's research associates small batches with better delivery performance.

Handoffs destroy context

This part follows Linear's 2026 essay "Issue tracking is dead".

Every handoff passes on a little less

Top: work moving through handoffs. Bottom: one small team that keeps the context and hears back from the user.

At every handoff the context gets summarized, decisions disappear and intent turns into a requirement. The developer receives the what without the why.

Issues still exist, but moving issues isn't the work. Feedback, decisions and code need to stay together.

What agents changed

Writing code got cheap, and the bottleneck moved. Execution used to be expensive, so we planned a lot. Today, building a first version can be part of thinking.

What limits us now is understanding the problem, deciding, reviewing, testing, keeping the architecture clear and validating with users.

AI amplifies the process you already have, which is the finding of DORA's 2025 report. A good process with AI gets faster feedback. A bad process with AI gets its problems faster.

The human navigates, the agent drives

I used Fabio Akita's account of building four apps in eight days, with 274 commits and 1,323 tests, as the example. His lessons are worth reading in full. The ones I repeated were that vibe coding without discipline only produces throwaway prototypes, that tests matter more with AI because they're what lets an agent change code safely, that the human decides what and the agent decides how, that refactoring and documentation can't be skipped, that every commit should be small and ready for production, and that an agent never says no. You are the brake.

Tools and architecture

The tools a team uses should make it faster. Pick the ones built for the people doing the work every day. Keeping people productive matters more than producing perfect reports.

Architecture is context too. Every agent is like a new hire with no memory, and confusing code charges for context on every task. Deep modules, with small interfaces, clear contracts and strong tests, let you work in one area without loading the whole system into your head.

A good tool removes coordination. CI answers "does it compile, does it pass?" Preview deployments turn a discussion into a URL. Linear reduces how much context gets lost.

The cycle

Momentum is repeating this cycle without getting stuck

Each lap makes the next one easier.

Momentum is being able to repeat this cycle without the organization jamming halfway through. It takes trust, autonomy, good architecture and good tools.

Part 4. The workshop

After the talk, the room became teams.

Each small group got a real problem, with enough context to start and enough ambiguity to force decisions. There was no finished spec and no mandatory process. The scope was small enough to reach working software. The only constraint was to get something working, and the only requirement was to deliver it in small steps.

The process was theirs. They could use AI and agents, research, change their minds, cut scope, redo things and organize the group however they wanted. They answered for the working result, for the decisions they made, for validating with someone outside the group and for writing down what they learned.

The retrospective didn't ask who built the most features. It asked these.

• Where did you wait?
• Which decision had to go up to someone?
• Where was context missing?
• Where did the agent get lost or do useless work?
• What got too big?
• When did you notice a wrong decision, and what did it cost to fix?
• What would you change in your group's process for a second round?

A few good people, context, authority and fast feedback. That's what generates momentum.