"Making Sure" Is the Hardest Kind of Doing

After 20-something years managing tech product development teams, I still get hit by imposter syndrome. Not the dramatic, paralysing kind — more like a quiet voice that shows up at odd hours and asks: what exactly is your job?

Every time I try to answer that question, I catch myself starting with the same two words: "Making sure…"

Making sure the team is working on the right problems. Making sure we're building the right thing. Making sure the client is aligned.

And that's where the voice gets louder. Because "making sure" doesn't feel like doing. It feels like hovering. Supervising. Being the person who talks while others build.

The cultural weight of "not doing"

This feeling doesn't exist in a vacuum. I live in Portugal, and in Latin cultures — Southern Europe broadly — there's a deeply ingrained dichotomy between the boss and the worker. The boss makes money. The employee does the "real work." The boss sits in meetings. The employee ships code.

It's a simplification, obviously, but it's a cultural undercurrent that's hard to shake. When you grow up with it, it seeps in. You start measuring your own worth by the same ruler: did I produce something today? And if the answer is "I spent the day in conversations, reviewing priorities, and thinking about the roadmap"… well, that doesn't quite count, does it?

Except it does. And it took me a long time to understand why.

Let's unpack "making sure"

When I say "making sure," here's what I actually mean:

Making sure my team is working on the right problems — This means I need to understand the business deeply enough to identify which problems matter now versus which can wait. It means saying no to things that feel urgent but aren't important. It means having difficult conversations with stakeholders about what we're not going to do. That's not passive. That's decision-making under pressure, with incomplete information, where getting it wrong costs real time and real money.

Making sure those problems create the most value for the business — This requires a constant feedback loop between what the market is doing, what our customers are telling us, and what the data says. I need to understand unit economics, customer retention patterns, competitive positioning — not at a surface level, but deeply enough to make trade-off calls. I'm not doing data science, but I'm synthesising signals from every direction into a coherent priority list. That's a skill. And it's work.

Making sure solutions hit the right balance between speed and robustness — This is where the technical depth matters. I need to know enough about architecture, infrastructure, and code quality to have a genuine opinion on build-vs-buy decisions, on when to take on tech debt and when to pay it down, on whether a proposed solution will scale or collapse under load. I'm not writing the code, but I'm shaping the constraints it's written within. And bad judgment here costs months.

Making sure the team has the right context to make their own decisions — This might be the most invisible and most valuable part. A team that needs to ask me for every decision is a slow team. A team that has enough context — business goals, user needs, technical constraints, strategic direction — to make good calls on their own is a fast team. Building that context isn't a one-time briefing. It's a continuous effort of sharing information, being transparent about trade-offs, and trusting people enough to let them disagree with you. That's leadership. And it's doing.

Making sure the client is aligned on expectations — Anyone who's ever been on a project where the client expected one thing and the team built another knows this isn't trivial. Expectation alignment is a continuous, active process. It means translating between business language and technical reality, setting boundaries without burning relationships, and sometimes delivering uncomfortable truths early enough that they can be absorbed. It's diplomacy, negotiation, and communication — simultaneously.

Making sure the tooling works for the kind of delivery we need — This one is quietly critical. The wrong tools slow everything down. The wrong CI/CD pipeline makes deploys scary. The wrong project management setup creates process overhead that kills momentum. I need to stay current enough to evaluate, adopt, and sometimes sunset tools — and do it without disrupting a team mid-sprint. That's operational design.

The actual job behind the words

When I look at that list honestly, I realise that "making sure" is shorthand for an enormous amount of actual, tangible work. It's just not the kind of work that produces a pull request or a design file or a deployment log.

To do all of it well, I need to continuously invest in:

Updated technical knowledge — not to the depth of a senior engineer, but enough to have informed opinions on architecture, evaluate new technologies, and call bullshit when someone says "it can't be done." I read, I experiment, I build side projects. I stay close to the code, even if I'm not writing production code daily.

Business knowledge — understanding how the company makes money, what the market looks like, where the industry is heading. This means reading quarterly reports, talking to sales, sitting with customer support, attending the boring meetings. It's not glamorous, but without it, I'm just a project manager with a fancier title.

Tooling and process design — the meta-work of making work flow better. Which tools, which workflows, which rituals actually help a team deliver, and which are theatre? This is harder than it sounds, because every team is different and what worked last year might be dead weight now.

People — and I don't mean "people management" in the HR-approved, competency-framework sense. I mean genuinely understanding what motivates each person on the team, what they're struggling with, where they want to grow. It means creating an environment where people can do their best work, which sometimes means protecting them from organisational noise and sometimes means pushing them into uncomfortable growth.

Communication — up, down, sideways. Translating between the board and the team. Between the designer and the backend engineer. Between the client and reality. Every single day.

Redefining "doing"

Here's what I've come to accept: the imposter syndrome doesn't go away. It comes with the territory when your output isn't a tangible artefact. You can't point to a commit and say "I did that today."

But you can point to a team that ships consistently. To a product roadmap that makes strategic sense. To a client relationship that survives a difficult quarter. To an engineer who grew into a tech lead because someone gave them the right context and the right space.

That's the work. It's just that nobody teaches you to call it work.

So the next time someone asks me what I do, I'll probably still start with "making sure." But I won't apologise for it anymore.

Because "making sure" isn't the absence of doing.

It's the hardest kind of doing there is.