Managing Product Engineers: Autonomy + Visibility

The Two Management Traps

Most engineering managers fall into one of two traps.

The Micromanagement Trap: Spending leadership time on Jira boards, sprint tracking, daily standups. This turns high-leverage roles into project coordinators. Engineers become order takers, not problem solvers. Leadership can't focus on architecture, platform vision, or cross-product coherence because they're stuck in tactical coordination.

Harvard Business School research found that executives now spend an average of 23 hours per week in meetings, up from less than 10 hours in the 1960s. During the pandemic, employees attended 13% more meetings, and workdays extended by 48.5 minutes on average¹. Worse, HBS research showed that stand-up meetings actually inhibit innovation; in a field experiment at a Google hackathon, teams using stand-ups developed less-novel products².

The Hands-Off Trap: Engineers have autonomy but no strategic context. Leadership loses visibility into blockers until it's too late. Team capacity is a mystery; overcommitment happens silently. Personal struggles go unnoticed.

Most managers think they have to choose between control and autonomy. The best managers realize you need systems that provide visibility without requiring coordination overhead.

The Two Systems That Enable Visibility Without Micromanagement

System 1: Async Check-Ins (DailyBot)

Instead of 30-minute daily standups where people aren't listening, use async check-ins. I use DailyBot connected to Slack and Jira, asking four questions daily:

What did you do yesterday? (Auto-tracked from Jira)
What's your plan today? (Forces prioritization thinking)
Are you blocked? (Surfaces obstacles in real-time)
What's your score today (1-10)? (Wellbeing check)

The DORA Report 2024, surveying over 39,000 technology professionals, found that teams with effective communication systems remained resilient and productive³. Async updates create that system; they replace meetings with written records, respect timezones, and enable pattern detection.

System 2: Calendar Transparency (Free/Busy Visibility)

Instead of defining explicit "working hours," use a simple principle: block your calendar when you're unavailable. Leadership sees free/busy status, not details.

When someone doesn't respond to Slack, I glance at their calendar. If they're blocked, I know not to expect immediate response. If they're unblocked and quiet, I check their DailyBot for work blockers.

Calendly's 2024 survey found that 67% of Gen Z workers proactively set calendar boundaries, compared to 53% of Millennials and 48% of Boomers⁴. The trend is clear: younger workers understand that transparency enables async work. Calendar blocks explain non-responsiveness, reveal natural work rhythms, and protect focus time.

The implicit contract: "I'll block my calendar when unavailable. You won't question why or expect responses during blocks. When unblocked, I'll be responsive."

The 1-10 Scale Philosophy

The simplicity of using 1-10 across different contexts makes the system intuitive and consistent.

Daily Wellbeing: "Thriving or Surviving"

I call this the "thriving or surviving" check-in. When someone reports 7-10, they're thriving. When they report 5-6, they're surviving. Anything below 5 means they're struggling and need help.

I don't need to know if it's personal or technical. The score is a trigger, not a diagnosis. If someone consistently reports 5s or below, I reach out: "I saw your score; need anything?" No interrogation, just an offer to help.

Gallup's wellbeing research found that highly engaged employees with strong wellbeing achieve 23% higher profitability, while poor wellbeing costs organizations $322 billion globally in turnover and lost productivity⁵. Regular wellbeing check-ins enable real-time pattern detection and intervention.

GitLab, one of the world's largest all-remote companies with over 1,500 engineers across 65+ countries, found that asynchronous communication is more efficient and effective in delivering business value while helping engineers achieve work-life balance⁶. Their research showed that 52% of remote workers would consider leaving a colocated company for a remote role. The daily score creates psychological safety that enables this autonomy; engineers can be honest about struggling without career consequences.

Monthly Performance: "Are You Meeting Expectations?"

Separately from daily check-ins, I give every direct report a performance rating in monthly 1v1s using the same 1-10 scale:

5 is the baseline: You're doing your job; meeting expectations
6-7: Exceeding expectations; you're on the promotion track (if you want it)
8-9: Significantly exceeding expectations; high impact
10: Irreplaceable; operating at next level (I've given this twice in my career)
<5: Not meeting expectations; performance improvement plan (PIP) is imminent

I want everyone to go above and beyond; a 5 is just the starting point, not the goal. And yes, I'm aware that in 2025, "6-7" became a viral meme that Gen Alpha kids were yelling everywhere until schools banned it. So when I tell someone they're performing at a 6 or 7, I can't help but think: at least they're not becoming a TikTok trend.

The 1-10 scale makes performance visible, but what you do with that trajectory should be up to the engineer, not imposed by leadership. Some of the best engineers are happiest at a senior IC level, building great systems without the coordination overhead that comes with promotion.

The Five Questions (Monthly 1v1s)

Monthly 1v1s aren't about status; DailyBot handles that. They're about support, development, and removing friction. After reviewing daily patterns, I ask five questions:

How are you doing personally?
How do you feel about your role on the team?
How do you feel about our team?
What more can I do for you?
What more can we do for the team?

Then I give the performance rating. Giving feedback after listening shows I'm considering their perspective, not just observing from above.

The "what more can we do for the team?" question surfaces systemic issues early. Engineers see patterns leadership might miss. It creates ownership; they're helping improve the system, not just complaining.

How This Enables Product Engineering

This approach creates what McKinsey calls appropriate "span of control" without the supervisory burden Deloitte warns against⁷. McKinsey found no magic number for reports per manager; it depends on work type, process standardization, and team independence⁷. Deloitte found that too-narrow spans force managers into "working manager" mode, spending 100% of time on execution rather than strategic leadership⁸.

Async systems enable leadership leverage. I can read updates in 5-10 minutes versus attending 30-minute standups across multiple teams. This is how you scale from 5 engineers to 50 to 200 without losing visibility or adding layers of middle management. That freed time goes to:

Building train track ahead of the train (proactive architecture)
Serving as technical air traffic controller (cross-product decisions)
Deep technical work (reviewing migrations, writing infrastructure code)
Strategic thinking (platform coherence, grand vision)

Engineers get high autonomy plus high visibility. They work independently, but leadership sees capacity, blockers, team health, and availability. No surprises; no micromanagement.

Google's Project Aristotle found that psychological safety accounts for 43% of variance in team performance⁹. The score system only works when engineers feel safe admitting struggle. Low-trust teams can't adopt this; they'll game the numbers or avoid honesty.

What This Looks Like in Practice

Morning routine (5-10 minutes):

Check DailyBot; scan for blockers and low scores; glance at team calendars. Respond to specific asks.

When someone struggles:

Low wellbeing score (5 or below) triggers gentle check-in: "I saw your score; need anything?" Pattern of low scores means deeper 1v1 conversation.

When leadership needs deep work:

Block your own calendar. Model the behavior. Async system means uninterrupted focus time.

The Tradeoffs

This isn't "set and forget." It requires discipline to read updates, follow through when blockers surface, and build trust that scores won't be used punitively.

This works best when teams are async-first, leadership values leverage over control, and tools integrate seamlessly. This struggles when leadership doesn't actually want to give up control or culture rewards "looking busy" over results.

If you don't have time to read daily updates, you don't have visibility now either. This is the highest-leverage 10 minutes of your day.

The Unlock

The constraint isn't velocity. It's not quality. It's whether your management system enables engineers to think strategically while maintaining high autonomy.

Product engineering doesn't happen when managers work harder; it happens when managers build systems that surface the right information at the right time, create psychological safety for honest communication, and free leadership time for high-leverage work.

The teams that ship great products aren't the ones with the most meetings. They're the ones where everyone knows what matters, what's blocked, and who needs help without turning leadership into project coordinators.

In the Fast/Good/Well framework from Article 1, these systems reveal which quality level is appropriate based on progress and blockers. In the known/unknown unknowns framework from Article 2, blockers surface unknown unknowns early. In Article 4's Trust Tax, the score system demonstrates why psychological safety is foundational; without trust, none of this works.

The question isn't whether to give engineers autonomy or maintain visibility. It's whether you'll build systems that enable both simultaneously.

Harvard Business School Working Knowledge, "You're Right! You Are Working Longer and Attending More Meetings" (2020). Research analyzing 3.1 million people found employees attended 13% more meetings during pandemic and workdays extended by 48.5 minutes. https://hbswk.hbs.edu/item/you-re-right-you-are-working-longer-and-attending-more-meetings ↩
Harvard Business Review, "Stand-up Meetings Inhibit Innovation" (2021). Field experiment at Google hackathon found teams using stand-ups developed less-novel products. https://hbr.org/2021/01/stand-up-meetings-inhibit-innovation ↩
DORA (DevOps Research and Assessment), "2024 Accelerate State of DevOps Report." Survey of 39,000+ technology professionals emphasizing effective communication systems for remote team resilience. https://dora.dev/research/2024/dora-report ↩
Calendly, "The State of Meetings 2024." Survey of 1,200 business leaders found 67% of Gen Z workers proactively set calendar boundaries vs 53% Millennials and 48% Boomers. https://calendly.com/resources/guides/2024-state-of-meetings-report ↩
Gallup, "Employee Wellbeing Is Key for Workplace Productivity." Research showing highly engaged employees with strong wellbeing achieve 23% higher profitability; poor wellbeing costs $322B globally. https://gallup.com/workplace/215924/well-being.aspx ↩
GitLab, "How to embrace asynchronous communication for remote work" and "2021 Remote Work Report." Research from company with 1,500+ engineers across 65+ countries showing async work delivers business value while improving work-life balance; 52% of remote workers would leave for remote roles. https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous ↩
McKinsey & Company, "How to identify the right 'spans of control' for your organization." Research identifying five managerial archetypes and context-dependent optimal span of control. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/how-to-identify-the-right-spans-of-control-for-your-organization ↩ ↩²
Deloitte, "Sustainable Organizational Improvement: Understanding supervisory burden." Framework showing too-narrow spans force managers into "working manager" mode spending 100% time on execution. https://www.deloitte.com/us/en/what-we-do/capabilities/mergers-acquisitions-restructuring/articles/supervisory-burden-root-causes.html ↩
Google re:Work, "Guide: Understand team effectiveness." Project Aristotle multi-year study of 180 teams found psychological safety accounts for 43% of variance in team performance. https://rework.withgoogle.com/intl/en/guides/understanding-team-effectiveness ↩