When AI changes your team, your leadership has to change too
AI tools let developers move faster than ever. But fast in the wrong direction is just expensive. Here's how I changed the way we work at Roccai — from managing tasks to giving developers real problems to own.
AI is changing how software gets built. That means it also has to change how we lead the people building it.
This is something I've been working through at Roccai over the last few months — and I want to share what we've actually done, because I think a lot of teams are facing the same question right now.
The problem: I was the bottleneck
For a long time, I owned the backlog. I'd prioritize tasks, decide what came next, and make sure the team knew what to focus on. It worked — until it didn't.
When I came back from maternity leave with less time than before, I quickly realized something had to change. I couldn't be the person every decision ran through. We were moving, but not fast enough. And not always in the right direction.
But here's the thing — this wasn't just about my time. It was also about AI.
As AI tools became part of how we build, the old way of working stopped making sense. With AI, a developer can move incredibly fast. But fast in the wrong direction is just expensive. And if I'm the only one who understands the full picture, the team can't make good decisions on their own.
The shift: from tasks to problems
The change we made sounds simple, but it required real work to get right.
Instead of giving developers tasks, I started giving them problems to own.
But before I could do that, I had to do the strategic work first. I spent time defining Roccai's direction — where we're going, how we're positioning ourselves, what we're actually trying to solve for our customers. I used that as the foundation for everything that came next.
Then I broke that strategy into concrete focus areas — one per developer.
Here's what that looks like in practice at Roccai:
One developer owns the onboarding experience. Their focus: how do we get a customer from sign-up to having a live guide as fast as possible?
Another developer owns the end user experience. Their focus: once the guide is live, how do we make that experience as good as it can be?
Each person has a clear customer problem they're responsible for. They understand why it matters. And they have the freedom to decide how to solve it.
The North Star: one number for the whole team
With individual focus areas, there's a risk that everyone optimizes for their own area and loses sight of the bigger picture.
That's why we have one shared North Star metric that the whole team works toward.
For us right now, it's this: how long does it take from creating a guide to having it live?
That's the number we want to bring down. Everyone on the team understands it. Every decision — whether it's about onboarding, the end experience, or something in between — connects back to that number.
Individual ownership. Shared clarity. That's the combination.
What this changes about leadership
When your team owns problems instead of tasks, your job as a leader changes.
You stop being the person who decides what comes next. You become the person who makes sure everyone understands the problem they're solving deeply enough to make good decisions themselves.
That means:
- Defining the problem clearly — not the solution. What customer pain are we actually solving? That has to be crystal clear before a developer writes a single line of code.
- Trusting the how — once the problem is defined, the developer decides how to solve it. With AI tools available, there are more ways to get there than ever. That's their domain.
- Staying aligned on direction — the North Star metric keeps everyone moving the same way, even when they're working independently.
What we're still figuring out
I want to be honest: this is not a finished transformation.
The refinement process — how we go from problem definition to actual development — is still evolving. We used to do a lot of refinement upfront before touching any code. Now I think some of that refinement can happen together with AI during development itself.
But what has to happen before development starts is being completely clear on the problem. What are we actually solving? For who? Why does it matter? That's the non-negotiable starting point.
The how can be flexible. The what has to be clear.
If you're thinking about making this shift
Here's what I'd suggest based on what we've done at Roccai:
- Do the strategic work first. Your team can't own problems if you haven't defined what problems matter. Get clear on your direction before you hand anything over.
- Give each person a customer outcome to own — not a feature, not a task. A real customer problem with a real human on the other side of it.
- Define one North Star metric the whole team shares. It doesn't have to be complex. It just has to be something everyone understands and can connect their work to.
- Separate the problem from the solution. Be specific about what you want to achieve. Be flexible about how it gets done.
- Accept that it takes time. Some people take to this faster than others. That's normal. The goal is direction, not perfection.
---
AI is not just a new tool you add to an existing way of working. It changes what's possible — which means it also changes what's needed from the people building with it, and from the leaders guiding them.
The teams that figure this out will move faster and build better. Not because they have better tools, but because they have clearer direction.
That's what we're working on at Roccai. And I'll keep sharing how it goes.
---
Frequently asked questions
How does AI change the role of a tech leader or CTO?
AI tools let developers execute faster than ever, which means the bottleneck shifts from execution to direction. The leader's job becomes less about deciding what gets built next and more about ensuring the team understands the problem deeply enough to make good decisions independently.
What does it mean to give developers problems instead of tasks?
Instead of assigning specific tickets or features, you give each developer ownership of a customer outcome — a real problem with a real person on the other side of it. They define how to solve it. This works because it activates their judgment rather than just their execution, which matters more when AI can handle much of the implementation work.
What is a North Star metric and why does a small team need one?
A North Star metric is a single number that captures the core value your product delivers to customers. For small teams especially, it prevents individual focus areas from drifting apart. Everyone may be working on different things, but they're all pulling toward the same outcome.
How do you lead a team that uses AI coding tools?
The fundamentals don't change — clarity on direction, ownership of outcomes, trust in the people doing the work. What changes is the speed at which mistakes compound. Fast movement in the wrong direction is more costly than it used to be, so the emphasis on problem clarity before execution increases.