Teams don’t fail because they’re lazy or incompetent. They fail because no one actually defined what success looks like. I’ve seen it too often: a CTO frustrated that their team isn’t improving, yet swearing they’re “doing all the right things.” A manager giving an underperformer “one last chance”—solely within their own head—without ever stating what improvement means. If you don’t explicitly set expectations with a deadline, you’re not leading—you’re just waiting to be disappointed. And by the time you realize it, the layoffs have already started.

Carefree, Goal-Free

You most likely have goals and deadlines in place, making you tilt your head and wonder what I’m talking about here. I rarely see startups that don’t have some sort of roadmap and times associated with different features they’d like to deliver. Yet those are the obvious goals. What are your expectations regarding how the team operates and improves?

How many times have you “kicked off” something only to have that initiative slowly fade away (or be immediately tossed aside), without even noticing? A year later, you’re digging through Notion to find something and come across that meeting summary where you announced the change. “Hmm, we really should do something about that,” you think to yourself.

When we treat the operating system of the organization less seriously than we do the actual product development, teams stagnate. It might be easier, because you’re not committing to anything, but you’re also not getting better.

Infinite Second Chances

Here’s a real story, so real I’ve heard it several times this month: a startup has been struggling with quality issues for literally years. Meetings are held. Reports are prepared. Perhaps the team has invested in “bug bashes” a few times. But, good intentions aside, no one has explicitly stated their failure to improve over such a long time frame.

That’s because they didn’t properly set expectations and make their intentions explicit. It’s a lot easier to have failures go unnoticed if we never even tried to keep track of them. Like people repeating the same new year’s resolutions year after year, these teams are wasting their opportunities to improve.

Owning the Expectation

Kent Beck, who invented Test Driven Development, teaches how you should approach running your tests. Just prior to hitting the keyboard combination to run them, you should mentally state whether you expect the tests to pass, and if they should fail—what should the failure be. Whereas many mindlessly run the tests and react to the result, Beck’s principle ensures we remain present and committed. Having “committed” our expectations, we’ll notice when there’s a mistake and so know we are missing something.

That same simple approach can work wonders when it comes to your organization’s improvement. By owning the expectation and committing to it, you’re going to do more than merely shrug it off when you notice things aren’t improving as you would have liked (or have it go unnoticed completely).

Making It Work

The solution is simple, yet not easy. We need to treat management and leadership work as we treat product commitments. They deserve the same seriousness. That means taking notes, setting dates, verbalizing expectations, planning, breaking down steps, defining milestones, and retrospecting.

Surprisingly, many managers who are adept at managing execution drop the ball when it comes to change management work and coaching. In The Tech Executive Operating System, I dedicated a whole chapter to breaking this down and listing simple approaches to managing this. As that’s out of the scope of this article, I’ll tackle the most common objection: that’s too much. You’re already overwhelmed with product delivery, how can you be expected to manage these other things the same way?

The only answer is that without doing that, you’re likely to be even more overwhelmed and see things deteriorate with time. You don’t have to tackle all issues at the same time, and part of proper leadership and tracking these changes is to decide how to prioritize them and which will wait. Yet with every iteration and accomplishment, you’ll gain a continuously improving team, making future iterations easier. Sounds like a fair deal to me.