Thanks Unblocked for supporting today’s article!
~80% of my "hands-on" time is now waiting for agents. The worst part is that when they finish, the results are often wrong, and I waste time correcting them.
It's almost always a context problem, and a pile of MCPs doesn't solve it. Each one searches its own silo, but the answer spans a PR, a Slack debate, and a Jira ticket marked won't fix. So your agent tries to do the stitching (on your token bill).
Unblocked ran the same task through Claude Code with and without a context engine. Up to 83% faster, at roughly 40% of the tokens, and actually the right answer. You can use their open source benchmark to see the differences on your own repos.
Sponsor manager.dev and reach 18.8k engineering decision-makers
In my first couple of years as an engineering manager, I took my PM’s word as given. They told me what to do, and I made sure the team did it. Nothing felt weird about it - they know the customers better, they understand the product better, and they have good ideas, right?
It took a few terrible calls by the PMs before I stopped working that way. Once I got into the details, I understood that in many cases product management is broken. So I slowly started to involve myself and my engineers on the product side: offering ideas, challenging decisions, and demanding to be heard.
Over the last 12 months, I asked more than 950 EMs:
“How involved are you in product decisions and the business side of your company?”
I was very surprised by the results:
I expected <5 YoE EMs to be less involved in product decisions, but I didn’t expect 45% of experienced engineering managers to be barely involved.
In too many teams, the mantra is still: “The PMs decide what to work on, the EMs and engineers decide how to accomplish it”. If you want your team (and yourself) to succeed in the upcoming years, you have to do better.
Here’s what happens when an engineering manager focuses solely on engineering:
Wasted effort - the team is releasing features that are not used or end up being rolled back.
Invisible impact - your team works hard, but nobody sees or appreciates it.
Hard negotiations - you need to constantly protect your team in roadmap talks, fight for headcount, and so on.
Constant surprises - there are reorgs and decisions you are not part of.
Disconnected engineers - your engineers don’t really care what happens after they finish a task.
Only 16% of the EMs surveyed answered that they are very involved in product decisions. If you are among the 84% majority (like I was for most of my management career), making that jump is easier than you think.
There are 3 battles you need to win:
Landing a feature vs launching it (awareness of basic metrics)
Watching user behavior
Talking to customers
Level 1 - Land vs Launch
The first level consists of being aware of the metrics your team impacts. It starts with basic access to them - Mixpanel, Amplitude, PostHog, or whatever product you use. Have a dashboard that shows usage over time and make it very accessible to your team. I use PostHog, and they have a ‘subscribe’ feature, allowing me to easily push the relevant dashboards to our team’s Slack channel.
I learned the importance of this one the hard way.
At my last company, we built tools for drone pilots flying over crop fields. One day, the ops team told us pilots were wasting a lot of time driving between fields in the wrong order (the traveling salesman problem!). So we built a phone-friendly route planner that did it automatically.
We launched it, announced it, and moved on.
Two months later, I checked the metrics: only six pilots had used it (out of ~200). Turns out, someone from ops had mentioned it once, and most forgot or ignored it. We tried again - this time with a personal message to each pilot. Over 60 started using it.
Having those metrics available is the difference between ‘launch’ and ‘land’. Launching is the fun part for engineers - solving a problem, writing code. Landing is boring and non-technical - but without landing, your launch is useless.
This is relevant not just for client-facing features - here’s a great post from a Principal Engineer at Google covering his own experience.
Did you release something? Schedule a reminder in a week or two to look at the data.
Level 2 - Watching user behavior
In almost every company, there are session recordings where you can actually see how your users behave. Usually PMs watch them - but nothing stops engineers from doing so. You can start with a ‘movie time’ meeting, 30 minutes where the whole team watches chosen recordings together.
Today, it’s also easy to feed those recordings to agents and have them analyze the pain points - but I’d still argue there is a lot of value in seeing how people use the products and what they are stuck on. Seeing a real human encounter the frustrating part of your product is an important experience.
A second part of this level is to watch recorded discovery calls with customers, even just one every few weeks. In the pre-AI-meeting-recorder days, I used to take the videos, cut the relevant parts, and add them to the matching tickets for a bit more context (or just send directly to the engineer).
Level 3 - Talk to customers [boss]
Most organizations are not structured to encourage direct conversations between engineers and customers. There are many layers between them: PMs, designers, customer success, account managers, user research.
At my last company, it took me 3 years to actually go visit a customer:
Our customers were farmers in the United States, so I had to fly across the ocean. And farmers are super busy, and don’t really want to talk to engineers…
Our CS team got me in touch with one who was really enthusiastic about our latest release. They mentioned that an in-person meeting would be more effective, as usually on Zoom he turns the camera off and doesn’t have a lot of patience. So I drove 10 hours each way from our office in Indiana to that customer in Iowa, for a 1-hour meeting.
It was definitely worth it!
I saw how he used our app in real life - on an iPad! Turns out in one of the critical flows, he switches to another app to get some data, and returns to ours. That’s not something we knew. I asked him about it, and he mentioned it’s very annoying, but he got used to it (who knows how many other customers it cost us!).
There was also a question I asked that he couldn’t answer - so he just called an intern into his office - and it turned out that intern was a super enthusiastic (and technical) user, who of course is never invited to Zoom calls because he is not senior enough (and that encounter led to multiple useful meetings).
And while in-person works best, there are many easier ways to meet customers:
Piggyback on existing meetings - ask to silently join customer discovery calls run by PMs, sales, or CS. Promise not to interrupt - just learn. If you have a question, you can just send it internally in Slack during that meeting.
Reach out via Support - find a user who recently complained, or someone whose ticket you fixed. You’ll be surprised how receptive customers can be. Recently, I had a good experience with Supabase. I had a bug and reached out to support, and they told me they escalated. Then an engineer fixed it, and reached back, asking if there was anything else I needed. If they had offered to jump on a call to understand my usage, I would have happily agreed. Works in both B2C and B2B!
Work with customer success/account managers to identify a power user (or just look at the data). Send a short, respectful email: “I’m an engineer on the team that built X - I’d love 15 minutes to learn how we can make it better for you”. Customer Success teams are often delighted when engineers take this initiative, because the usual mindset from engineers is “don’t waste my time with useless meetings”.
In the second and third methods, we go for the edges - the people who either love us, or need us but are annoyed. Those are the people who are already invested in our product, so they won’t need much convincing to jump on a short call. If someone opens a ticket, it means they need our product.
Here are 3 questions you can start the meeting with:
Feature context: “How do you currently solve X?”
Usability feedback: “Can you show me how you’d use this new flow?”
Pain validation: “What’s the most frustrating part of your workflow right now?”
But I mainly try to just shut up and listen to them. I also highly recommend reading The Mom Test if you’d like to learn how to do such calls properly.
Your product is used by humans
There is no way to truly understand your product without understanding your customers. Every single level here is about being more in touch with the human behavior of the people who use your product every day.
Engineering managers who stay purely technical, without any empathy toward their customers, are missing a critical aspect of their jobs.
And in addition to being able to influence the product roadmap, being closer to your customers makes your work much more fun.
My favorite reads of the week:
Before you delegate, ask yourself these 6 questions. I’m almost always forgetting at least one of the aspects.
What if you’re not supposed to have a long-term plan? On emergence, a process that occurs in nature when multiple parts come together to form a complex whole without a clear plan or intention. Could definitely relate.
What nobody tells you about writing agent skills. Some very useful tips, and a cool prompt at the end!
