Protect ~5 hours weekly for reviews, reading, and timeboxed side projects to keep technical judgment without becoming a bottleneck.
Yes - I can stay technical as an engineering manager without doing an IC job. The article’s core idea is simple: I should protect about 5 hours per week for low-risk technical work, use code and design reviews as my main loop, keep a small reading routine, and do timeboxed side projects that help me judge trade-offs without becoming a bottleneck.
Here’s the full article in plain terms:
- I stay close to the system by understanding architecture, trade-offs, and failure points
- I block recurring time on my calendar and protect it like a one-on-one
- I focus on high-context, low-risk work instead of owning production features
- I use reviews to check correctness, tests, alignment, and team thinking
- I keep current with a simple reading mix: books, feeds, newsletters, and release notes
- I turn reading into notes, team talks, and decision input
- I use side projects to answer one unknown at a time
- I borrow a few staff-engineer habits, but I use them for coaching and decision-making, not feature ownership
A short version: don’t try to be the backup senior engineer. Stay close enough to guide the work, but not so close that the team has to wait on me.
| Area | What I should do | What I should avoid |
|---|---|---|
| Weekly time | Block about 5 hours/week | Let meetings erase it |
| Coding work | Do prototypes, reviews, risk checks | Own production-critical features |
| Reviews | Focus on trade-offs and coaching | Nitpick every line |
| Reading | Follow a fixed rotation | Random tab-hopping |
| Side projects | Timebox small experiments | Become the only maintainer |
One stat stands out: the article says a block of around five hours is often enough to finish a design doc or build a prototype. That’s a small slice of a workweek, but it can keep my technical judgment sharp.
If I keep that rhythm, I can stay technical in a manager’s role without sliding back into day-to-day implementation.
Set a weekly technical time budget you can protect
Once you know what staying technical looks like for you, the next step is simple: put time on the calendar and defend it. Treat technical time the same way you treat one-on-ones. It should be recurring and non-negotiable.
Block recurring time for reading, reviews, and small technical work
A practical weekly rhythm is a few short windows for reading and code review, plus one longer block for deeper work. If you can hold that space, a block of about five hours is often enough to finish a design doc or build a prototype . Mark it as busy, and if something has to move, reschedule it the way you would a meeting with a stakeholder. Don’t just delete it.
The main problem is calendar creep. One one-on-one shifts. A planning meeting runs long. Then, before you know it, your technical block has vanished.
Choose work that keeps context high and risk low
Once the time is blocked, the next call is deciding what belongs in it. Pick work that keeps you close to the codebase without turning you into the person everyone has to wait on. That usually means high-context, low-risk work that sits off the critical path, like reviews, prototypes, and system-risk checks.
| Task Type | Context Level | Risk Level | Impact on Critical Path |
|---|---|---|---|
| Building small prototypes | High | Low | None (Off-path) |
| Ambient reading and technical feeds | High | Low | None (Passive) |
| Observability and edge-case reviews | High | Medium | Low (Advisory) |
| Production feature ownership | High | High | High (Bottleneck) |
As the team grows or delivery pressure starts to climb, the first thing people tend to cut is technical time. That’s the trap. A better move is to shrink the scope of the work, not the time itself. Instead of a prototype, do a smaller review task. Instead of a deep review, do a focused code review. The routine stays in place. Only the depth changes.
Use code reviews and design reviews as your main technical loop
Inside that weekly technical budget, code reviews and design reviews give you the most return. They keep you close to the work: implementation details, coding standards, and the habits your team falls into day after day. You're reading code with purpose, not jumping in to write it yourself.
Build a review cadence that fits a manager's schedule
A few short review blocks each week usually work better than one long session. That rhythm is easier to protect on a manager's calendar, and it helps you stay current without getting pulled into delivery. The point is to stay in the loop, not to take over the work.
Be clear with the team about which PRs need your review and when you'll respond. That small bit of structure cuts down on waiting and guesswork.
Not every pull request needs the same level of attention. Put your energy into major product shifts. That's often where architecture starts to drift.
Review for correctness, trade-offs, and coaching value
A simple mental checklist helps: correctness, test coverage, and architectural alignment. You won't need to go deep on all three every single time, and that's fine. A fast pass through each one helps you spot what matters and ignore what doesn't.
The biggest payoff often comes from the reasoning in your comments. A review isn't just about catching bugs. It's also a coaching moment. Your comments show the team how to think through trade-offs, why one path makes more sense than another, and where to slow down.
That leadership piece matters. Reviews are one of the clearest ways to model technical judgment, not just point out defects.
Reading helps fill the gaps between reviews and keeps your judgment current.
Build a reading rotation that keeps you current
Between code reviews, a fixed reading rotation helps keep your judgment sharp without eating up more time on your calendar.
Unstructured browsing is a time sink. You skim a bunch of tabs, bounce between links, and end up with little that sticks. A simple rotation solves that: books for depth, curated feeds for day-to-day context, newsletters for weekly summaries, and release notes for changes in the tools your team uses.
| Source Type | Best Use Case |
|---|---|
| Books | Foundational knowledge and long-term strategy |
| Curated feeds | Daily day-to-day context and timely learning |
| Newsletters | Weekly industry trends and curated summaries |
| Release notes | Tracking breaking changes in tools your team uses |
This isn't about knowing a bit of everything. It's about making better technical calls in the work you already lead.
Use daily.dev as your default ambient feed
Use daily.dev as the default ambient feed for your team's stack. The daily.dev browser extension turns each new tab into a personalized stream of developer articles and discussions based on the topics you care about.
Set it up around your team's actual stack, not just your own interests. If your team works deep in Kubernetes, TypeScript, and AI, follow those tags. That way, you can spot changes that may hit the stack before they show up in a review. Think of it as the daily layer between deeper reading sessions.
"Every day, I check daily.dev for the latest discussions around React, JavaScript, TypeScript, AI, RAG, and more." - Klinger Matheus Vieira da Silva, Developer
Turn reading into notes, decisions, and team conversations
Sort each item into read now, save for later, or discuss with the team. Keep your notes short. One or two sentences on why something matters is enough to turn a link into input for your next design review, coaching chat, or technical direction call.
Try to capture one useful idea each week so it can feed your next review, design discussion, or side project.
Keep your hands dirty with side projects and a simple operating model
Reading and reviews help you stay current. Small projects do something different: they turn that input into judgment. When you build even a small thing, you start to see trade-offs, risks, and implementation gaps before they land on the team.
Pick side projects that sharpen judgment, not your resume
Choose work that helps the team and is small enough to finish fast. Good bets include internal tools, dashboards, automation, and timeboxed proofs of concept.
The point of a side project is to answer one technical unknown and sharpen your judgment. Put a time limit on every project, and stop when that unknown is clear. If the work starts to feel like something you now own, back away.
That’s the hidden-ownership trap. And it can sneak up on you. If you’re the only person who can fix the thing when it breaks, you’ve turned a learning exercise into a long-term burden. That’s one of the fastest ways to block IC growth and burn yourself out.
Borrow from staff engineer learning habits without copying the role
You can borrow the habits without borrowing the job. Staff engineers and engineering managers both need to stay current, but they do it for different reasons. If you want to look closer at how staff engineers handle this, the habits they use look different in practice - the goal is different.
A couple of habits transfer well: keep a short to-learn backlog, and review design docs early.
A staff engineer reads a design doc to shape implementation. You read it to ask better questions, spot risks early, and support coaching and alignment. That shift matters. The goal isn’t to jump back into ownership. The goal is to build better judgment in the conversations you already lead.
Key points from this article:
- Protect a weekly time budget for technical work. Block it on your calendar before other work takes over.
- Code and design reviews are your main technical loop. Use them to check correctness, weigh trade-offs, and coach people, not just approve work.
- A simple reading rotation - books, curated feeds, newsletters, and release notes - keeps your context high without wasting time.
- Side projects should sharpen judgment, not your resume. Timebox everything and avoid hidden ownership.
- Borrow staff engineer habits like a to-learn backlog and design doc reviews, but use them to support coaching and decisions, not implementation.
FAQs
What counts as low-risk technical work for an engineering manager?
Low-risk technical work can sharpen engineering quality and help managers keep learning without putting production or day-to-day operations in danger.
Think of it as staying close to the work without touching the live wire.
That can look like a steady code review cadence, light technical guidance, reading rotations, curated technical feeds, or small side projects kept away from core systems. The goal is simple: help managers stay technically engaged while keeping the blast radius small.
How do I protect five technical hours when my calendar keeps filling up?
Treat those five technical hours like executive meetings. Put them on your calendar as recurring, non-negotiable blocks so nothing else crowds them out.
Then use that time for high-impact work, like deep-dive code reviews or side projects. To keep up without wasting time, use daily.dev to shape your learning feed and stay current more efficiently.
How can I stay technical without becoming a bottleneck for my team?
Protect your engineering time for high-leverage work. Set up a reading rotation you can stick to, keep code reviews on a steady rhythm, and pick up small, well-scoped side projects that turn into reusable patterns.
Shift your focus toward unblocking people, coaching through reviews, and building shared technical learning. Instead of sitting on the critical path for every task, help the team move through clear process and mentorship - not constant intervention.
