Forem: Secur3-et

I Treated My Team Like Customers and Became a Better Manager

Secur3-et — Tue, 25 Nov 2025 21:03:20 +0000

I used to be terrible at 1-on-1s.

Not because I didn't care. I cared deeply about my team. But every meeting felt like I was starting from scratch.

"How's that project going?" I'd ask.

"I finished that two weeks ago," they'd remind me.

Awkward silence.

Then one day, I had a realization that changed everything.

The Sales Team Didn't Have This Problem

Our sales team managed relationships with 50+ customers each. Somehow, they never forgot what was discussed in the last call. They never asked the same question twice. They always knew exactly where each customer was in their journey.

How?

They had a CRM.

Before every customer call, a sales rep would pull up the customer's profile in Salesforce:

Complete interaction history
All previous conversations
Tracked commitments and follow-ups
Context for the relationship
Next steps clearly defined

Meanwhile, I was managing 8 engineers with scattered notes across Notion, Slack, Jira, and my brain.

The sales team wasn't smarter than me. They just had better systems.

The Experiment: What If I Treated My Team Like Customers?

I decided to try something.

I created a Confluence page for each person on my team. Not a project page. Not a meeting notes dump. A profile.

Just like a CRM, but for people management.

Here's what each profile looked like:

# Sammy  - Senior Engineer

## Career Goals
- Wants to move toward tech lead role
- Interested in infrastructure/DevOps work
- Loves backend systems, less interested in frontend

## Recent Context
- Just shipped auth refactor (2 sprints ahead of schedule)
- Feeling a bit siloed from the DevOps team
- Mentioned wanting more architectural responsibility

## 1-on-1 History (Newest First)

### 2024-01-15 - 1-on-1
**Discussed:**
- Auth refactor completion (shipped early!)
- Interest in learning Kubernetes
- Wants exposure to infrastructure work

**Action Items:**
- [ ] Me: Intro Sammy to DevOps team lead (Mark)
- [ ] Me: Add her to #architecture Slack channel
- [x] Her: Write tech spec for caching layer proposal

**Notes:**
- Really proud of auth work
- Feeling ready for more ownership
- Mentioned she's never worked with K8s before

### 2024-01-08 - 1-on-1
**Discussed:**
- Sprint planning for auth refactor
- Career development conversation
- Mentoring junior devs

**Action Items:**
- [x] Her: Finish auth refactor by EOW
- [x] Me: Add her to architecture review meetings

**Notes:**
- Did great job mentoring Alex on code reviews
- Wants more architectural decision-making

## Personal Context
- Has two kids (flexible schedule appreciated)
- Previous background in security engineering
- Prefers async communication

Simple. Clean. All in one place.

The First Meeting After I Changed My System

Before my next 1-on-1 with Paul, I spent 5 minutes reading his profile.

Last time, he'd mentioned he was nervous about presenting the database migration plan to the architecture team. I'd completely forgotten about it.

But it was right there in his profile.

I started the meeting differently:

"Hey Paul, last time you mentioned you were nervous about the database migration presentation. How'd it go?"

He paused. Looked surprised.

"Wait... you remembered that?"

"Of course," I said.

He smiled. "It went really well actually. The team approved the plan. We're starting migration next sprint."

Then he opened up about something he'd never mentioned before: he was interested in moving into an SRE role eventually, but wasn't sure how to get there.

That one moment changed our relationship.

It wasn't that I suddenly became a better listener. I just had a system that helped me remember.

What Changed After 3 Months

1. No More "What Were We Talking About?" Moments

Before: 10 minutes of fumbling through notes before each meeting.

After: 5 minutes reviewing their profile. I walked in prepared.

2. I Actually Followed Through on Commitments

Before: "I'll introduce you to the DevOps team" → forget → feel guilty → they stop asking

After: Open commitments tracked per person. I couldn't forget. It was right there every time I opened their profile.

3. I Could See Patterns Over Time

After 8 weeks of 1-on-1s with Maria, I noticed a pattern in my notes:

Week 1: Mentioned feeling burned out from on-call
Week 3: Mentioned incident response was draining
Week 5: Mentioned struggling with work-life balance
Week 8: Mentioned thinking about taking a break

I would have missed this completely with scattered notes. But seeing 8 weeks of history in one place? The pattern was obvious.

I talked to her about reducing on-call load and moving her to a project with fewer production incidents. She stayed. She's now one of my strongest senior engineers.

I would have lost her without this system.

4. Career Development Actually Happened

Before: "Let's talk about your career goals" → vague conversation → nothing happens

After: Career goals written at the top of their profile. I saw them before every 1-on-1. I could connect their current work to their long-term goals.

"You mentioned wanting to move toward tech lead. This API redesign project would be a great opportunity to lead. Want to own it?"

5. My Team Noticed

Three months in, Sammy said something in our 1-on-1:

"I feel like you actually remember our conversations now. It feels like you care more."

I did care before. But now I had a system that let me show it.

The Simple Formula

Here's what I learned:

Scattered notes + Working memory = Forgotten commitments
Person-centric profiles + 5 min prep = Relationships at scale

Sales teams figured this out decades ago:

CRM = Customer Relationship Management

Engineering managers need the same thing:

PRM = People Relationship Management

The Tipping Point

This system works at any scale, but it becomes essential around 5-7 direct reports.

Below 5 reports: Your brain can mostly keep up. You'll forget things occasionally, but it's manageable.

Above 7 reports: Working memory breaks down. You need a system.

I hit the crisis point at 8 engineers. That's when I built this.

If you're managing 5+ people and feeling scattered, you're not bad at your job. You just don't have the right system yet.

How to Build This System (15 Minutes)

You don't need fancy tools. Here's how to start:

Step 1: Create One Page Per Person (5 min)

Use whatever you have:

Confluence
Notion
Google Docs
Markdown files in a Git repo
Literal paper notebook

One page. One person.

Step 2: Add Three Sections (5 min)

# [Name] - [Role]

## Career Goals
(What do they want long-term?)

## 1-on-1 History
(Chronological log, newest first)

## Open Commitments
(Yours and theirs)

That's it. Three sections.

Step 3: Log Your Next 1-on-1 (5 min)

After your next meeting, spend 5 minutes writing:

Date
What you discussed
What they're working on
Wins, challenges, concerns
Action items (clearly labeled: you vs. them)

Step 4: Review Before Each Meeting (5 min)

Before your next 1-on-1 with them:

Read their profile
Check what you talked about last time
Check what you committed to
Check what they committed to

Show up prepared.

The ROI

Time saved:

Before: 10 min scrambling before each meeting
After: 5 min focused review
Savings: 5 min per meeting = 40 min/week for 8 reports

Trust gained:

Remember commitments → follow through → trust
Remember personal context → they feel seen
Remember career goals → they feel supported

Retention impact:

Replacing a senior engineer costs 6-12 months of salary
I kept Maria because I saw the burnout pattern
I kept Sammy because I followed through on DevOps intro
Avoiding 1 departure = $100k-200k saved

What I Realized

Systems aren't the opposite of care.

Systems enable care at scale.

I care about my team. I always have. But caring without systems meant:

Forgotten commitments
Repeated questions
Lost context
Eroded trust

Caring with systems meant:

Showing up prepared
Following through
Building continuity
Earning trust

The Mindset Shift

Before: "I should be better at remembering things."

After: "I should build systems that remember for me."

Sales reps don't feel guilty about using Salesforce. They use it because it makes them better at their job.

Engineering managers shouldn't feel guilty about using systems. They should feel guilty about not using them.

What Happened Next

This system worked so well that other managers started asking about it.

"Can you share your Confluence template?"

"How do you organize your notes?"

"What's your system?"

Eventually, I realized: every engineering manager needs this.

So I turned it into a product. It's called Helmly.

It's a CRM for people managers. Person-centric profiles. Meeting history auto-loaded. Open commitments tracked per person. No scattered notes. No context switching.

If you're managing 5+ engineers and feeling the scramble, check it out at helmly.io.

I am looking for ~20 founding members (free lifetime access) to help shape the product. If this article resonated, I'd love to have you join.

Start Today

You don't need Helmly to start. You just need one page per person.

Pick your tool:

Confluence
Notion
Google Docs
Markdown in Git
Physical notebook

Create one profile. Log one 1-on-1. Review it before your next meeting.

Your team will notice immediately.

What system do you use for 1-on-1s? Drop a comment. I'd love to hear what's working (or not working) for other engineering managers.

Follow my build log on Twitter @HelmlyApp - I'm building Helmly in public and sharing what I learn about management systems, product development, and scaling relationships.

The Hidden Cost of Context Switching for Engineering Managers

Secur3-et — Sat, 22 Nov 2025 23:17:01 +0000

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.

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.