Last week, after a particularly tough day, I was speaking with our head of product. He shared a concept I hadn't heard before, so I wanted to share it with you.
He called it "passive vs active time".
If this is a real thing, let me know, because it blew my mind. You know when you hear a concept for the first time, and it's like zen koan - you instantly become enlightened? This was like that.
If you are a manager, I'm sure you know the feeling. You hit the end of the day, and despite all the meetings, and emails, and follow-ups, it feels like you've done nothing tangible. If someone put a gun to your head, you wouldn't be able to say what you did, even though it all felt important. This is passive time.
What Passive Time Is
Managers live in passive time. Their world is full of meetings, documentation, alignment sessions, and keeping information flowing. Passive time isn’t about getting a direct result at the end of each task. It’s more about spinning plates to keep everything moving. It's about stopping friction, smoothing out noise, and clearing obstacles.
Great managers are the interface between business functions. They take in vast amount of data, and make it digestable to people who need different things.
And boy, is it exhausting. If you're an introvert like me, it's crazy how much it drains you. There's a real reason extroverts end up as your boss, even when they aren't as competent as you.
What Active Time Is
Engineers, on the other hand, crave active time. They live for the act of creation. For them, work means writing code, solving concrete problems, and getting things done. They’re driven by visible output—the type of progress you can point to at the end of the day. They want to see commits, they want to see linear tickets in "Done".
They want to see results.
Interruptions like meetings and emails are the enemy. I know loads of great engineers who don't check their email, they focus on the task at hand. One task at a time.
Active time is about building, testing, and delivering. It’s productive, it’s satisfying, and it’s what we hire engineers for. When they’re pulled away from this flow, their days slip by without real results. It's frustrating. But while active time can get things done, too much of it without pause or feedback leads to tunnel vision.
How Passive Time Goes Wrong
Passive time is necessary, but it’s easy to see how it can go sideways. Too many meetings stalls real progress. Passive time also creates distance from the work itself. When work becomes a thought experiment, it's easy to lose focus on what is being built, and whether people want it.
If you work in a startup, stop me if you've heard this before. You get a weird text from the CEO. Everyone needs to come in tomorrow for a full-day workshop. They've had an idea, or revenue is down, and they want to talk about it.
During the day, it actually feels like "progress" is happening. People are being honest, sometimes being brutal, laying out all the issues that are bothering them.
And then Monday rolls around again and nothing has changed. You wrote a bunch of values or new KPIs, but no-one is really following them or held to account when they miss them.
Somehow, everyone got a turn to speak, and discussed everything but the one thing that would make a difference.
How Active Time Goes Wrong
This isn't a rant about how engineers are better than product owners. It's actually the opposite.
Active time, too, has its pitfalls. With heads down, engineers often overlook the bigger picture. Engineers can treat tickets like a to-do list, rather than an active idea to discuss. They skip the "why" of a feature. Then they get frustrated when they spend four weeks building something, and it gets taken out of the product a week later because it's hurting sales.
Engineers get tunnel vision. "Of course it's not performing yet, we've only spent a few weeks on it; there's still lots more we need to add". I've done it. You fall down the rabbit hole spending three months building a feature nobody wants.
Engineers can often feel like that type of thinking isn't their job That's what the product manager is for. Their job to build it.
It's the wrong approach.
It leads to rework or scrapped features when the output is "right" but not what is needed. Without the right passive framework, active time risks goes to waste.
Finding The Middle Ground
What I'm starting to realise is that there is a yin-yang here. Active time requires small doses of passive time, and vice versa.
Here are my takeaways:
- Active Passive Time: Make passive time count by adding an actionable goal. Instead of a loose brainstorming meeting, set a single purpose: “Today, we’ll decide how to do X”. You can't brainstorm three OKRs at once, it just means you lack focus. If you're worried about revenue, then that is what everyone should be talking about. Even your most junior engineer should know exactly how much revenue you are making this month, and how far you are off of your goal. We shouldn't be talking about the product, or bugs, or headcount, or anything outside of that goal. Passive time doesn’t have to be endless; if the goal is to gather input, keep it focused. Trim meetings to the essentials, both in content and in people, and follow up with clear action points.
- Passive Active Time: Engineers need time to think, as well as code. Active work doesn’t have to mean constant productivity. You should encourage engineers to pause and reflect, and look at the work from multiple angles. Is there a way we could test this feature before implementing it fully? What customer has asked for this feature? What did they actually say? Give time for these feedback loops, even within active work.
- Intentional Overlap: Bring engineers into passive time with clear intent. If they’re there, it’s because they’re needed, not as passive listeners. Product Managers often go silent during handover because they don't have the technical knowledge. It doesn't matter, speak up, and make sure the customer's needs are being heard. Engineers can build things they don't understand, but their work will be better when they do. Give them that ownership.
In the end, it comes down to purpose. Great products come from teams who are aligned not only in what they’re building, but in why they’re building it. Whilst building it fast.
I would be very interested in hearing from people who have experienced this, and what their aproach is.
Please share your thoughts with me on X at @alexjackhughes.