Hi, I'm Matt Watson, founder and CEO of Full Scale. This is my weekly newsletter, based on my 20+ years of experience as a CTO and CEO in tech.
Every week we read more headlines about AI. It is a mix of sensational hype and a reality check that our world is changing around us. Not to mention half of our teams are depressed because their craft of coding has been reduced to directing agents.
One thing is for sure: because of AI, we've never felt more busy than we do today. Keeping multiple agents running and trying to QA all this AI slop is giving us all headaches.
But being busy is not the same as making progress.
AI will happily help you pour a huge amount of effort into building something nobody wants, and it'll do it in half the time. The one thing it won't do is stop and ask whether you're building the right thing at all. That part is still your job, and nobody trained you for it.
Nobody trained you for this
Almost nobody trains you to be an engineering manager. You were good at writing code, so they handed you more people and more meetings, and one day the job was leading a team instead of shipping features.
You learned it on the job, in the middle of doing it, which is both the best and hardest way to learn anything.
And the pull is always back toward the work you already know how to do: tickets, standups, and putting out the next fire. Getting into the weeds feels productive because it's the thing you're actually good at. It's also easy dopamine.
But a manager who only does that has quietly stopped doing the real job, which is noticing whether the work still makes sense and where the team is actually headed.
One day I was thinking about how to get my own managers to stop and see the big picture through the noise of the weekly chaos. That is where I coined "The Focus Five."
The Focus Five
The Focus Five is a small habit I put together to fight that pull, and one I give the managers on my team at Full Scale.
Once a week you sit down, by yourself, and answer five questions. Not to report status to anyone. Just to pull your head up and look at the whole picture.
Underneath all five is really one question.
Are we maximizing our efforts?
Software development is a huge investment at many companies. The manager's job isn't to keep everyone busy. It's to make sure all that money and effort turns into progress on something that actually matters.
Here are the five.
What did we accomplish last week? A momentum check, not a victory lap. Did the team move, or did we tread water? Don't recite a task list, render a verdict. If the honest answer is "not much," that's the signal to change something.
What did we learn from it? Shipping and learning aren't the same thing. A team can ship a ton and learn nothing, or ship nothing and learn the whole approach won't work. If the answer is always "nothing," you're either coasting or not pushing on hard enough problems. Compounding learnings is the real growth lever.
Are we still building the right thing? The most important one, and the easiest to skip. The team can be focused, fast, and cranking, and still build something nobody needs. Would it matter to a real customer if you shipped it tomorrow? This is the question AI will never ask for you.
What help do we need right now? What's blocking us, and who can clear it? The point is to catch a blocker while it's still small, before it quietly costs you a week. How do we go faster?!?
What can we say no to? Focus is a weekly decision. What can the team drop, defer, or kill? If you can't name a single thing to cut, you probably aren't really focused. Success is largely based on doing less and not by doing more.
That's it.
This isn't about Jira tickets or a roadmap. It is about the gut feeling if we are doing the right things the right way. And generally, how do we do them better and faster?
A thin week is the most useful answer
A couple of rules keep this from collapsing back into a to-do list.
Be honest with yourself. "I don't know," "nothing," and "not much" are real answers, and they're usually the most useful ones. Don't talk yourself out of them.
A thin week is a signal, not a failure. The week you and your team didn't get much done is the most valuable thing this can surface, as long as you do something about it.
And end with a change. Reflection that changes nothing by Monday is wasted. At least one of these questions should turn into something you actually do differently this week.
The goal is to get a little better every week. Slow and steady growth as a leader and team compounds.
You don't get better by moving faster
No single week is the point. The point is the loop.
You reflect, you learn one thing, you change one thing, and you do it again the next week. Run that loop fifty times a year and it compounds. The team keeps catching what isn't working while it's still cheap to fix.
But you only get the loop if you stop.
A team that never pauses to reflect doesn't improve. It just repeats the same week over and over and calls it experience.
You don't get better by working harder or moving faster. You get better by stopping long enough to see clearly, and then changing something.
The most valuable thing that ever comes out of it is the week you realize you need to quit doing something. Not do it better, not do it faster. Stop. Some project, some process, some meeting that made sense six months ago and doesn't anymore. Nobody catches that with their head down. You only see it when you pull up and look.
Somebody has to ask why
Most people just do what they're told. Change is uncomfortable, so they keep their heads down and keep the work moving. In a lot of the world that instinct runs even deeper, where asking "why" can come across as disrespectful, or like you're creating friction on purpose. It's human, and it isn't going anywhere.
But if you're the manager, asking why is the job. Nobody else is going to stop the machine and check that it's aimed the right way. That's on you. Be a leader, and go fight for what actually needs to get done.
The courage to improve yourself
That willingness to ask why out loud, when it would be easier to stay quiet, is courage. In Product Driven I write about it as one of the pillars of a healthy team: the psychological safety that lets engineers speak up and push back.
The Focus Five is that same courage, pointed inward.
It takes courage to write "not much" and mean it. It takes courage to admit the team is building the wrong thing, or that the meeting you set up is the one to cut.
Nobody trained you for this job, so getting better at it is on you. And it starts with the honesty to see clearly, even when what you see isn't flattering.
The courage to improve yourself.
