Let's do some quick math.
You have 8 engineers reporting to you. You meet with each one for 30 minutes every week. That's 4 hours of 1-on-1 time, right?
Wrong.
Before each meeting, you spend 10 minutes hunting for notes, scrolling through Slack, checking Jira tickets, and trying to remember what you talked about last time. That's 80 minutes per week just on the pre-meeting scramble.
After each meeting, you spend 5 minutes trying to remember where to save your notes, updating your task tracker, and sending follow-ups. Another 40 minutes.
Your actual cost: 6 hours per week, not 4.
And that doesn't include the mental overhead of feeling unprepared or the trust you lose when you forget something important.
Welcome to the context-switching tax. It's costing you more than you think.
The Three Hidden Taxes
Most engineering managers only count the time they spend in meetings. But there are three context-switching taxes you're paying that never show up on your calendar:
Tax #1: The Pre-Meeting Scramble (10 minutes per meeting)
You know this routine:
Open Notion. Or was it Confluence? Maybe that Google Doc?
Search for their name. Find 12 different note pages.
Scroll through months of unorganized notes trying to find the last 1-on-1.
Give up. Check Slack DMs instead.
Find a conversation from two weeks ago about the auth refactor, but not the career goal they mentioned.
Open Jira to see their tickets.
Check your calendar to remember what sprint work they're on.
Cobble together a vague sense of context.
Get into the meeting hoping you remember enough.
Time cost: 10 minutes per meeting × 8 meetings = 80 minutes per week
Tax #2: The In-Meeting Distraction (ongoing)
You're in the meeting now, but you're still context switching:
"Let me just pull up my notes..." (awkward 30-second pause while they wait)
You ask "How's the authentication refactor going?" They remind you they shipped it two sprints ago.
They mention something important about wanting to learn Rust. You're frantically searching for where you wrote down their career goals instead of listening.
You miss critical signals because half your brain is hunting for context.
Time cost: Hard to quantify, but you're losing quality and trust in every meeting.
Tax #3: The Post-Meeting Admin (5 minutes per meeting)
The meeting's over. Now what?
Where do I save these notes? Notion or Confluence this time?
Update Jira with the action items they mentioned.
Send a Slack follow-up about that thing you promised to do.
Add "introduce Sammy to the DevOps team" to your personal task list.
Try to remember to actually do it.
Forget by tomorrow.
Time cost: 5 minutes per meeting × 8 meetings = 40 minutes per week
The Total Cost
Meeting time: 240 minutes/week (4 hours)
Pre-meeting scramble: 80 minutes/week
Post-meeting admin: 40 minutes/week
─────────────────────────────────────────────
Total: 360 minutes/week (6 hours)
Context switching tax: 120 minutes/week
Over a year, that's 100+ hours just hunting for information that should already be at your fingertips.
At an engineering manager's hourly rate ($75-150/hr), you're burning $7,500-$15,000 per year on context switching.
But money and time aren't even the biggest cost.
The Real Cost: Cognitive Overload
Here's the uncomfortable truth: your brain can't handle it.
Research by cognitive psychologist George Miller shows that humans can hold roughly 7±2 items in working memory at any given time.
Now let's look at what you're trying to remember when managing 8 engineers:
For each person, you need to track:
Current sprint work (2-3 tickets per person)
Longer-term projects and technical initiatives
Career goals and growth areas (tech lead track? IC track?)
Recent wins and challenges
Commitments you made to them ("I'll get you access to the database")
Commitments they made to you ("I'll finish the code review by EOD")
Technical blockers or architectural concerns
Performance trajectory
Personal context (family situations, burnout signals, life events)
That's roughly 10 context items per person.
8 engineers × 10 items each = 80 things to actively remember
Your brain's capacity: 7±2 items
The math doesn't work.
You're trying to manage 80 items with a system built for 7. It's like trying to run a modern web app on a Raspberry Pi Zero.
What Happens When You Exceed Capacity
When your working memory maxes out, things start breaking down:
You forget commitments you made.
Three weeks ago, you told Sammy you'd introduce her to the DevOps team so she could learn more about infrastructure. You forgot. She brought it up again. You apologized and promised to do it. You forgot again.
You ask the same question twice.
"How's that authentication refactor going?" Paul stares at you. "I told you last week. It's done. We shipped it two sprints ago." Awkward silence.
You lose track of career goals.
Alex mentioned six months ago that they wanted to move into a tech lead role. You said you'd help create a development plan and give them opportunities to lead. It never happened. Alex assumed you didn't actually care. They started looking elsewhere.
You can't connect dots between conversations.
Maria told you last month she was feeling burned out because of the incident response rotation. Next meeting, you jump straight into asking about the database migration project without checking in on how she's doing. She feels like just a resource, not a person.
Your team notices.
And every time this happens, trust erodes a little more.
The Trust Erosion Problem
Let me give you a real example of what this costs.
I promised Sammy I'd introduce her to the DevOps team. She was interested in infrastructure work, and I thought it would be great for her growth into a senior engineer role.
I forgot.
Three weeks later, she brought it up again in our 1-on-1. I apologized. "Absolutely, I'll do it this week." I meant it.
I forgot again.
She never brought it up after that. And here's what I didn't realize at the time:
She stopped bringing up career development topics entirely
She assumed I didn't actually care about her growth
She started quietly interviewing at other companies
She stopped volunteering for stretch projects
Her engagement dropped, and I couldn't figure out why
Six months later, she left for another company.
Replacing her cost us:
6-9 months of salary to recruit, hire, and onboard someone new
3-6 months before the new person was fully productive
Institutional knowledge that walked out the door with her (she was the only one who understood our legacy auth system)
Team morale impact from losing a strong senior engineer
All because I had no system to track a simple commitment.
This is what context switching costs. Not just time. Not just money. Trust.
The Tipping Point: When Memory Stops Working
I've talked to hundreds of engineering managers about this, and there's a clear pattern:
2-3 Direct Reports
Memory works fine
No systems needed
High context, high trust
You remember everything
5-7 Direct Reports
Starting to forget things occasionally
Basic notes usually enough
Occasional context loss, but manageable
You feel a little scattered
8-10 Direct Reports
Can't remember everything anymore
Using multiple tools (Notion, Confluence, Slack, Jira), still losing context
Frequent repetition and forgotten commitments
This is where the context crisis happens
The tipping point is around 5-7 direct reports.
Below that, working memory is enough. Above that, you need systems.
But most engineering managers hit 8-10 reports with no system in place. That's when everything breaks down.
Why Engineering Managers Don't Have Systems
Sales teams solved this problem decades ago.
When sales reps scaled from managing 10 customers to 100, they didn't try to "remember better." They built systems. They created CRMs.
Before every sales call, a rep sees:
Complete customer history
All previous interactions
Tracked commitments
Context for the conversation
Next steps clearly defined
Meanwhile, engineering managers are scrambling through scattered notes in Notion, Confluence, and Slack, hoping to remember what they talked about last sprint.
So why haven't engineering managers built the same systems?
Reason #1: The tools don't exist
Management tools are built for projects, not relationships.
Jira/Linear: Task-centric. Organized by sprint and project, not by person.
Notion/Confluence: Document-centric. Great for wikis, terrible for relationship tracking.
Slack: Conversation-centric. Search is painful, history is scattered.
Google Docs: File-centric. No structure, just piles of documents.
None of these are organized around people. They're organized around projects, documents, or tasks.
Reason #2: Cultural resistance
"1-on-1s are personal. They shouldn't be systematized."
This sounds good, but it's backwards. Systems don't replace care—they enable care at scale.
Reason #3: The "good managers just remember" myth
We believe that great engineering managers have photographic memories. But that's not how great managers succeed. They succeed because they have great systems.
Reason #4: No clear category
Sales → Salesforce, HubSpot, Pipedrive
Support → Zendesk, Intercom
Projects → Jira, Asana, Linear
Code → GitHub, GitLab
Management → ???
There's no established category for "CRM for managers." So most engineering managers cobble together solutions with the wrong tools and hope for the best.
What a System Should Do
If you're managing relationships at scale, here's what you actually need:
- Eliminate the Pre-Meeting Scramble Context should auto-load when you open a person's profile. No hunting. No scrambling. Just instant access to:
Complete 1-on-1 history with this person (chronological, newest first)
All open tasks and commitments (theirs and yours)
Career goals and development notes
Recent wins, challenges, and personal context
Think of it like opening a GitHub PR. All the context is right there: commits, comments, reviews, history.
- Reduce Cognitive Load Everything in one place, organized by person, not by project or date.
Instead of:
Notes → Notion (organized by date)
Tasks → Jira (organized by sprint)
Messages → Slack (organized by channel/DM)
Calendar → Google Calendar (organized by time)
You should have:
Sammy's Profile:
├─ Complete 1-on-1 history
├─ Open tasks (hers + yours)
├─ Career goals
└─ Personal context
One profile per direct report. Everything about them in one place.
- Enable Follow-Through Tasks should be tracked per person, not buried in a generic to-do list.
Not:
☐ Intro Sammy to DevOps team
(lost in a list with 47 other tasks across 8 people)
But:
Sammy's Profile > Open Commitments:
☐ You committed to intro Sammy to DevOps
Status: Not done
Created: 3 weeks ago
When you open her profile before your 1-on-1, it's right there. You can't forget.
- Build Continuity Your 1-on-1s should build on each other like chapters in a book, not standalone episodes.
A good system shows you:
What you talked about last time
What they were excited or worried about
What you both committed to
Patterns over time (Are they consistently blocked on the same thing? Are they showing burnout signals?)
That's how you build relationships at scale.
The Confluence Workaround I Built
After I realized how much context switching was costing me, I made a change.
I started treating my team like customers. I created a Confluence page for each engineer. Not a project page. A profile.
Each profile included:
Sammy - Senior Engineer
Career Goals
- Tech lead track
- Wants to learn infrastructure/DevOps
- Interested in distributed systems
1-on-1 History (Newest First)
2024-01-15
- Discussed: Auth refactor completion, next project
- Wins: Shipped auth refactor 2 days early
- Concerns: Feeling siloed from DevOps team
- Action items:
- [ ] Me: Intro Sammy to DevOps team lead
- [x] Her: Write tech spec for caching layer
2024-01-08
- Discussed: Sprint planning, career development
- Wins: Mentored junior dev on code reviews
- Concerns: Wants more architectural work
- Action items:
- [x] Her: Finish auth refactor by EOW
- [x] Me: Add her to architecture review meetings
Personal Context
- Has two kids, prefers async work
- Previous background in security
- Enjoys backend systems work Before every 1-on-1, I'd spend 5 minutes reviewing their profile:
What did we talk about last time?
What did I commit to? Have I done it?
What were they excited or worried about?
Then I'd start the meeting by following up.
"Last time you mentioned you were nervous about that architecture presentation. How'd it go?"
The first time I did this with Tom—the engineer who'd called me out for asking the same question twice—he actually paused.
"Wow. You remembered."
Of course I remembered. It was right there in his profile.
But to him, it felt like I was paying closer attention. Like I cared more.
That's when I realized: systems aren't the opposite of care. Systems enable care at scale.
Start Here
You don't need to build a full system overnight. Start small:
Step 1: Create one page per direct report
Use whatever tool you already have—Notion, Confluence, Google Docs, even Markdown files in a Git repo. One page per person.
Step 2: Log 1-on-1s chronologically
Newest at the top. Include:
Date
What you discussed
What they're working on (sprint work, projects)
Wins, challenges, concerns
Career development topics
Action items (clearly labeled: you vs. them)
Step 3: Track commitments per person
Don't bury action items in a generic task list. Track them on each person's page.
Open Commitments
Me
- [ ] Intro Sammy to DevOps team lead (Created: 2024-01-15)
- [ ] Add her to #architecture channel (Created: 2024-01-08)
Her
- [x] Write tech spec for caching layer (Done: 2024-01-16)
- [x] Finish auth refactor (Done: 2024-01-12) Step 4: Spend 5 minutes before each meeting reviewing
Read their profile. Refresh your memory. Show up prepared.
That's it. That's the system.
Your team will notice immediately. And you'll feel the difference.
The ROI
Let's do the math on what you get back:
Time Savings
2 hours per week reclaimed from context switching
100 hours per year = 2.5 full work weeks
At $75-150/hr, that's $7,500-$15,000 per year in value
Trust & Retention
Fewer forgotten commitments = stronger trust
Better context = more engaged engineers
Lower attrition = $50,000-$150,000 saved per avoided replacement (engineering salaries are expensive)
Team Performance
Better prepared meetings = better conversations
Clearer follow-through = faster execution
Stronger relationships = higher psychological safety
Higher psychological safety = better performance (backed by Google's Project Aristotle research)
The ROI is massive. And it compounds over time.
The Mindset Shift
Stop asking:
❌ "What note-taking app should I use?"
❌ "Should I move my 1-on-1 notes to Notion?"
❌ "How do I organize my Confluence better?"
Start asking:
✅ "How do I manage relationships at scale?"
✅ "What system will surface context when I need it?"
✅ "How do sales teams do this?"
Salespeople don't say "I need a better notepad." They say "I need a CRM."
Engineering managers should do the same.
Final Thought
You're not bad at your job because you can't remember everything.
You're trying to manage 8-10 engineering relationships with the same mental tools that work for 2.
The problem isn't you. It's the absence of systems.
Memory doesn't scale. Systems do.
Your team deserves a manager who shows up prepared, remembers commitments, and builds on every conversation.
You can't do that with scattered notes and working memory.
But you can do it with systems.
Calculate your own context-switching cost. Count how many minutes you spend before and after each 1-on-1 just hunting for information.
Then ask yourself: is this how you want to spend your time?
Or are you ready to build a system that actually works?
About Me
I'm Evan, an Engineering Manager who learned the hard way that you can't manage 10 engineers the same way you manage 2.
After burning 100+ hours per year on context switching—and losing Sammy because I forgot a simple commitment—I built a system. It worked so well that I eventually turned it into a product: Helmly.
Helmly is a CRM designed specifically for people managers. Meeting history and open tasks, auto-loaded before every 1-on-1. No hunting. No scrambling. Just context.
If you're managing 5+ engineers and feeling the context scramble, check it out at helmly.io.
We're looking for ~20 founding members (free lifetime access) who want to help shape the product. If this resonates, I'd love to have you join.
I'm also building in public on Twitter [@YourHandle]—follow along if you want to see how we're building a CRM for managers from the ground up.
Found this helpful? Drop a comment with your own context-switching horror stories. I'd love to hear how other engineering managers are handling this problem.
Top comments (0)