Two months after becoming an Engineering Manager, I noticed a pattern.
Every evening I drove home with the same uncomfortable thought:
"I'm sure I forgot something."
Not because I wasn't working hard.
Not because I wasn't organized.
Simply because there were too many moving pieces.
I was responsible for engineers, customer escalations, production incidents, projects, hiring, one-on-ones, operational reviews, process improvements, emails, Slack messages, and meetings.
The amount of information wasn't the problem.
The number of decisions was.
Like many engineers, my first instinct was to solve the problem with technology.
I built dashboards.
I automated reports.
I configured email notifications.
Unfortunately, I discovered something important.
Dashboards only work if you remember to open them.
Email alerts eventually drown inside dozens of other emails.
Automation can generate information, but it cannot decide what deserves your attention first.
The problem wasn't missing data.
The problem was lacking a repeatable decision-making process.
That's when I stopped trying to optimize my tools.
Instead, I started designing a system for myself.
Today, I think of it as my personal Management Operating System.
What is a Management Operating System?
Every Engineering Manager has recurring responsibilities.
Some happen every day.
Others happen every week.
Some are operational.
Others are strategic.
The mistake many new managers make—including me—is treating every incoming notification as equally important.
The result is reactive management.
A Management Operating System is simply a structured sequence of reviews that helps you answer four questions every day:
- Is production healthy?
- Does my team need my help?
- Are my projects moving forward?
- Is anything waiting specifically for me?
Everything else becomes secondary.
Principle 1: Order is more important than the checklist itself
Most people focus on what belongs in a checklist.
I believe the real value is deciding when each item should be reviewed.
For example, I intentionally review communication channels in a specific order.
I look for operational escalations before I answer general emails.
Why?
Because production incidents lose value every minute they remain unnoticed.
A vacation request can usually wait another thirty minutes.
An active customer escalation cannot.
The sequence of review determines where your attention goes.
And attention is one of the most valuable resources an Engineering Manager has.
Principle 2: Separate urgent work from important work
One of the hardest lessons I learned was that urgent and important are rarely the same thing.
Urgent work includes:
- Active incidents
- Customer escalations
- SLA or SLO breaches
- Production failures
Important work includes:
- Career development
- Process improvements
- Technical debt
- Documentation
- Automation
- Hiring
If you don't intentionally separate these categories, urgent work will consume your entire day.
Eventually your team becomes excellent at fighting fires but terrible at preventing them.
My operating system forces me to review both.
Urgent work is addressed first.
Important work is protected so it actually happens.
Principle 3: Every review should answer a question
This changed how I designed my checklist.
Instead of writing tasks, I started writing questions.
For example:
Operational Health
"What could affect customers today?"
This leads me to review service health, SLA reports, ongoing escalations, and recent incidents.
Engineering Execution
"Is anyone blocked?"
Instead of checking every ticket individually, I review aging work, unassigned issues, and engineers who may need support.
Upcoming Risk
"What will become tomorrow's incident if ignored today?"
This includes scheduled maintenance, change management, and planned deployments.
Thinking in questions prevents the checklist from becoming a mindless routine.
Every section exists because it answers a management decision.
Principle 4: Every incident improves the system
One mistake I made early on was assuming the checklist would eventually be "finished."
It never is.
Every significant incident teaches me something.
Whenever my team gets surprised by an issue, I ask a simple question during the retrospective:
Could this have been detected earlier?
If the answer is yes, I don't just fix the incident.
I improve the operating system.
Maybe a new report should be reviewed.
Maybe a dashboard should move earlier in the sequence.
Maybe a recurring follow-up should become a permanent checklist item.
The system evolves because the environment evolves.
My Daily Flow
Although every organization is different, my daily review follows the same high-level sequence.
1. Operational readiness
- Confirm on-call coverage
- Review urgent communication channels
- Scan for production risks
Goal:
Identify anything that requires immediate attention.
2. Service health
- SLA and SLO reports
- Fleet health
- Bug trends
- Customer impact
Goal:
Understand whether the platform is healthy before diving into projects.
3. Execution tracking
- Aging work
- Unassigned tasks
- Escalation follow-ups
- Engineers needing support
Goal:
Prevent work from silently getting stuck.
4. Future risk
- Upcoming production changes
- Planned maintenance
- Process compliance
- Documentation improvements
Goal:
Reduce tomorrow's problems.
5. Leadership
Only after operational risk is understood do I switch my attention toward:
- One-on-one meetings
- Career development
- Project planning
- Coaching engineers
Leadership deserves uninterrupted attention.
I don't want to conduct a career conversation while wondering whether production is on fire.
How to Build Your Own Management Operating System
If you're a new manager, don't copy someone else's checklist.
Build your own.
Start with these five steps.
Step 1
Write every recurring responsibility you have.
Don't organize anything yet.
Just capture everything.
Step 2
Group responsibilities into categories.
Examples:
- Operations
- Customers
- Team
- Projects
- Administration
Step 3
Order the categories by business impact.
Ask yourself:
"If I skipped this until tomorrow, what would happen?"
That question quickly reveals what deserves to come first.
Step 4
Review your system every Friday.
Remove items that no longer provide value.
Add new ones after major incidents.
Your operating system should evolve continuously.
Step 5
Protect important work.
If every day ends after firefighting, you'll never invest in automation, documentation, mentoring, or process improvements.
Those activities are what reduce firefighting in the future.
Final Thoughts
The biggest benefit of my Management Operating System wasn't productivity.
It was confidence.
I no longer leave work wondering what I forgot.
If I've completed my review sequence, I know I've given my team the attention it deserved.
Will incidents still happen?
Absolutely.
Will unexpected problems still appear?
Of course.
No checklist eliminates uncertainty.
But a good operating system dramatically reduces preventable surprises and frees your mind to focus on what engineering managers are actually hired to do:
Make good decisions, support their teams, and continuously improve the systems they are responsible for.
In my experience, that's a much better use of mental energy than trying to remember everything.
