Stop. Start. Keep.

Every high-performing team I've worked with has a version of this conversation. Usually at the end of a sprint, a quarter, or a project. Sometimes after a failure. Occasionally after a success.

Three questions:

What should we stop doing?

What should we start doing?

What should we keep doing?

It sounds simple. It is simple. But the answers, applied consistently, separate teams that compound capability from teams that compound dependency.

At Teachnology, this isn't just a retrospective technique. It's a philosophy. And when you apply it to the questions that actually matter (team experimentation, professional growth, build versus buy), it becomes a framework for organisational transformation.

Stop

Let's start with what to stop. Because stopping is harder than starting, and most teams are drowning in activities that no longer serve them.

Stop buying software by default.

The reflex to purchase has become so ingrained that most organisations don't even consider alternatives. Need a capability? Find a vendor. Issue an RFP. Sign a contract.

This made sense when building was expensive and slow. It makes less sense every month as AI makes building faster and more accessible.

Stop treating "buy" as the default answer. Start treating it as one option among several, evaluated honestly against building, partnering, or doing without.

Stop waiting for permission to experiment.

Most organisations have created cultures where experimentation requires approval. Business cases. Steering committees. Risk assessments. By the time you've secured permission, the window for learning has closed.

Stop asking permission for small experiments. If you can try something in a week, try it. Learn from it. Then decide whether to scale it. The cost of a failed small experiment is trivial compared to the cost of never experimenting at all.

Stop confusing activity with progress.

Meetings, reports, status updates, alignment sessions. They feel like work. They often prevent work.

Stop measuring effort and start measuring outcomes. What did we ship? What did we learn? What capability did we build? If you can't answer these questions, you've been busy without being productive.

Stop treating vendors as partners.

They're not. They're vendors. Their incentives are revenue retention and expansion. Sometimes that aligns with your success. Often it doesn't.

Stop expecting your account manager to tell you when you should switch to a competitor or build capability yourself. That's your job. Treat vendor relationships as commercial transactions, not friendships.

Stop protecting people from learning.

When you shield your team from challenges, you shield them from growth. When you do the hard things for them instead of teaching them, you create dependency on you.

Stop being the bottleneck. Start creating conditions where everyone develops capability. Your job as a leader is to make yourself progressively less necessary, not more.

Start

Now, what to start. Not everything at once. Pick one or two. Build the muscle. Then add more.

Start building before you buy.

Not instead of buying. Before buying. When a new need emerges, spend a week exploring whether you could build it. You'll learn something regardless of the outcome.

Sometimes you'll discover building is easier than you thought. Sometimes you'll discover the problem is more complex than you realised, which makes you a better buyer. Either way, you've developed capability.

Start running small experiments constantly.

Not big transformation programmes. Not multi-year initiatives. Small experiments. What can you try this week? This sprint? This month?

Small experiments compound. Ten small experiments teach you more than one big project. They fail faster, cost less, and generate learning that feeds the next experiment.

Start measuring capability development.

Most organisations measure project delivery. Did we ship on time? On budget? To spec?

Start measuring something different: what can we do now that we couldn't do before? What have we learned? What capability have we built that we can apply elsewhere?

Capability compounds. Projects end. Measure what compounds.

Start protecting time for learning.

If your team is 100% utilised on delivery, they're 0% available for growth. That's not efficiency. That's slow-motion decline.

Start blocking time for learning. For experimentation. For building skills that aren't immediately billable. Treat this time as non-negotiable. The organisations that out-learn you will eventually out-perform you.

Start documenting decisions, not just outcomes.

When something works, you want to know why. When something fails, you want to know why. But most teams only document what happened, not why they made the choices that led there.

Start capturing decision rationale. What did we believe? What options did we consider? What made us choose this path? Future you will thank present you when you're trying to understand why things are the way they are.

Keep

Finally, what to keep. The practices that are working. The disciplines that create value. The habits worth protecting.

Keep shipping.

Nothing teaches like shipping. The feedback from real users beats the speculation of internal stakeholders every time. The pressure of a deadline forces decisions that would otherwise drift.

Keep shipping regularly. Keep putting work in front of people who'll use it. Keep learning from what happens when theory meets reality.

Keep asking "why are we doing this?"

It's easy to inherit activities that no longer make sense. Reports nobody reads. Meetings that could be emails. Processes designed for problems you no longer have.

Keep questioning. Keep asking whether each activity still earns its place. Keep pruning what doesn't serve you.

Keep developing your people.

When budgets tighten, training is often the first cut. When deadlines loom, development conversations get postponed. This is false economy.

Keep investing in your people. Keep creating opportunities for them to grow. Keep remembering that your competitive advantage walks out the door every evening and you need them to walk back in tomorrow.

Keep evaluating build versus buy.

The calculation changes constantly. What made sense to buy three years ago might make sense to build today. What was too complex to build last year might be straightforward now.

Keep revisiting these decisions. Keep treating vendor relationships as temporary, not permanent. Keep asking whether you're building capability or renting it.

Keep focused on business value, not technology for its own sake.

It's easy to get seduced by new tools, new platforms, new approaches. Shiny objects are compelling.

Keep coming back to: does this create value? Does it solve a real problem? Would we do this if nobody was watching? Technology serves business outcomes. Keep that hierarchy clear.

Applying the Framework

Here's how to make this practical:

For team retrospectives: Spend ten minutes at the end of each sprint on Stop/Start/Keep. Not just what happened, but what you should do differently. Capture one action from each category. Actually do them.

For professional growth: Apply it to yourself quarterly. What habits are holding you back? What skills should you be developing? What practices are serving you well? Write it down. Review it next quarter.

For capability development: Apply it to your organisation's build-versus-buy decisions. What purchases should you stop renewing? What capabilities should you start building? What investments in learning are paying off?

For culture change: Apply it to how your organisation operates. What meetings should stop? What experiments should start? What values should you keep reinforcing?

The framework is simple. The discipline of applying it consistently is hard. But consistency is where the value lives.

What This Looks Like at Teachnology

Let me make this concrete with how we apply it:

We stopped:

• Waiting for perfect before shipping
• Treating SaaS as the default answer
• Asking permission for small experiments
• Optimising for consensus over speed

We started:

• Building products in public
• Running weekly experiments
• Measuring capability development alongside delivery
• Documenting decisions and rationales

We keep:

• Shipping constantly
• Questioning whether each activity earns its place
• Investing in learning even when busy
• Treating every vendor relationship as temporary

This isn't a one-time exercise. We revisit it regularly. The specific items change. The discipline of asking the questions doesn't.

The Compound Effect

Here's why this matters: small changes compound.

Stop one wasteful activity. Start one valuable practice. Keep one discipline that's working. Do this consistently, week after week, quarter after quarter.

In a year, you're unrecognisable. Not because of any single dramatic change, but because of dozens of small ones, each reinforcing the others.

Teams that do this build capability. Teams that don't build dependency.

Teams that do this develop people who can adapt to anything. Teams that don't develop people who can only operate within existing constraints.

Teams that do this create options for their future. Teams that don't narrow their options until there aren't any left.

Stop. Start. Keep.

Three questions. Applied consistently. The difference between building your future and having it built for you.