Attention is All A Manager Needs
As I dive deeper into the current renaissance of Artificial Intelligence for a project I’m working on (more on that at the end), I find myself revisiting research on how to process and make sense of information at scale.
Discussions about managing large-scale information naturally remind me of the challenges engineering managers and directors face. They must navigate both information overload and scarcity at the same time—a paradox that becomes especially evident when coaching new managers or those transitioning from line management to senior leadership. In this article, I’ll explore these challenges and share a few practical tools that have helped me on my own journey.
The challenges with attention
Managing is a constant balancing act of deciding where to direct your attention—knowing when to zoom in on details and when to step back for the bigger picture.
In modern organizations, this is made worse by the proliferation of multiple inboxes managers must keep up with. Every tool used by teams daily—Jira, Slack, Workday, Expensify, and countless others—has its own notifications and alerts. As a manager, you’re constantly sifting through them, deciphering which issues demand immediate attention and which can wait.
Information overload is a major pain point, consuming valuable time and draining your energy. At the same time, the opposite problem arises—critical information often fails to reach you when you need it. Team members may not proactively share key updates, leaving you in the dark about important tasks or projects unless you explicitly request a status report.
These challenges manifest differently depending on your level of management. Let’s take a closer look at how they play out at different stages.
Engineering managers
When coaching an engineer or individual contributor through the transition to management, the first challenge is usually shifting their attention from individual tasks to the team and project as a whole.
This shift requires learning how to delegate and trust the team, but the hardest part is understanding what needs attention and where to look for it. Widening the lens can feel overwhelming, and new managers are often terrified they won’t be able to provide a competent answer when their director or an important stakeholder asks about something.
How people navigate this depends a lot on their personality. More extroverted managers tend to rely on conversations with their team to gather information. While this might seem like a good approach, it can quickly turn into a stream of interruptions for status reports and a team bogged down in meetings. In remote work, the problem is compounded by the lack of quick, spontaneous conversations.
On the other hand, more introverted managers often dread asking for status updates. Instead, they spend hours combing through Slack messages, Google Docs comments, and GitHub PRs rather than bothering someone for an update. This approach preserves the team’s flow but leaves the manager working with incomplete or outdated information pieced together from artifacts. It also results in misalignment—without regular sync points, team members naturally drift apart, forming micro-teams rather than functioning as a cohesive unit.
And even when they do have a good grasp of what’s happening, another major challenge for first-time managers is avoiding reactivity.
As a manager, you’re exposed to a constant stream of activity that could impact your projects and people. New managers often fall into the trap of handling issues as they arise, dealing with each one individually. While resolving problems feels productive, reacting to every fire means you’ll quickly become a troubleshooter rather than a leader. You’ll spend so much time firefighting that there’s little room left for your actual job, which is putting systems in place to prevent these issues in the first place. And even when you do have time, hours of constant context-switching will leave you mentally drained.
Directors and above
After plenty of trial and error (and hopefully some good coaching), most new managers eventually find a system for managing information within their own team. They start feeling less overwhelmed and build processes that work well enough.
Unfortunately, this is usually the moment they’re given a larger scope. Maybe they’re assigned a second or third team or promoted to senior manager or director. And that’s when they realize that keeping track of their own team was the easy part. As their responsibilities grow, so does the area their attention needs to cover.
The role of a senior manager varies wildly depending on the company’s size and structure—much more than that of an engineering manager. One constant, however, is the expectation that someone in this role will impact and support more than just their immediate teams and stakeholders. A senior manager is also expected to influence the broader organization. A lot of this falls under the concept of what Patrick Lencioni calls “first team”: the idea that the leaders in your group—you, your peers, and your manager—form a team in its own right, one that prioritizes the company’s overall success rather than just advocating for individual groups.
This expectation exists whether or not the company is mature enough to implement first team in practice. To meet it, senior managers must stay up to speed not only on their own teams and projects but also on what’s happening across peer teams and the organization as a whole.
In practice, this means your attention can’t just be directed downward at your teams—you also need to look sideways across the organization.
With this widened aperture, keeping track of what’s happening by reading Slack threads, PRs, Google Docs, and Jira tickets becomes humanly impossible. Worse, now that you’re in a higher-ranking role, your requests for updates carry more weight. A simple Slack message asking for an update can turn into a 30-minute walkthrough of a rehearsed 40-slide deck. Before long, you become selective about when and from whom you request updates—partly to avoid unnecessary deep dives, but also because you don’t want people dropping everything just because “the boss wants a status report pronto.”
What has worked for me
Like many crafts, learning to manage attention and information effectively comes mostly through experience. While every manager’s journey is unique, some practical strategies consistently help across different cases.
Build recurring information checkpoints
You may loathe the eight-hours-per-iteration-spent-in-planning ordeal suggested by early versions of Scrum, and I won’t blame you for that. But regular planning sessions—for both the short and medium term—are invaluable. They give teams a chance to step back from the daily fog of war and think strategically about the next few weeks or months.
Similarly, a daily stand-up provides a structured forum where everyone can broadcast what they’re working on and self-organize around blockers.
It doesn’t matter how often these rituals happen or how long they take. What matters is that they create a predictable cadence for actionable information sharing. First, they allow teams to plan around these sessions instead of being interrupted by a manager’s ad-hoc requests for status updates. More importantly, they set the expectation that information should be shared regularly and give team members implicit permission to ask for updates—something that might seem trivial but is crucial, especially for less extroverted folks who may need the encouragement of a structured setting.
Create a UX for information sharing—even if you need to fake it
The only thing worse than not having the information and context you need in Jira, a document, or some other system is having that information be outdated. And both problems are rampant in organizations of all sizes.
You can try to fix this by enforcing diligence—making it clear that keeping information up to date is a core expectation that impacts performance. Or you can take a softer approach, reminding people that the best way to avoid interruptions is to ensure key details are always documented.
But whether you use a carrot or a stick, these tactics only go so far. The real problem isn’t forgetfulness or lack of effort—it’s the user experience. And I don’t mean the UX of tools like Jira (which, let’s be honest, are universally awful but tolerable). I’m talking about the entire process of keeping information up to date across multiple systems.
Typically, a team doesn’t use just one system but several, all of which need to stay in sync. People waste an absurd amount of time manually copying, pasting, and linking items between Jira, Trello, GitHub PRs, and various spreadsheets.
To reduce this friction, I maintain a single spreadsheet listing all projects in our portfolio, each with an individual accountable for it. Every row includes status and planning information, the relevant goal (usually an OKR), and a link to the project’s charter. The charter itself can live anywhere—some people use a Google Doc, others an Epic in Jira—as long as it follows a standard template.
Every two weeks, we hold a project portfolio meeting with all project owners—something that deserves its own article. I expect each project owner to keep their row in the spreadsheet up to date, as this serves as the single source of truth.
In return, I take on the administrative burden of ensuring this spreadsheet feeds into whatever other systems need the data—whether it’s OKR tracking tools, company roadmaps, or other reporting structures. The project owners don’t need to worry about those; they just need to keep the spreadsheet accurate.
As you might imagine, this can be a lot of work. Over time, I’ve tried different approaches to avoid spending all my waking hours copying and pasting data—everything from scripts that sync data across systems to, when I’m really lucky, hiring a Chief of Staff to manage the process.
Regardless of the method, the key takeaway is this: the best way to improve information quality is to reduce friction in the process.
Have recurring one-on-ones not only with reports but also peers
I joke that every book on engineering management is just 200 pages teaching you how to run one-on-one meetings. Joke or not, holding regular one-on-ones with your direct reports is already a well-established practice in software engineering. What’s less common, though, is having recurring one-on-ones with your peers and your manager’s peers.
Just like with direct reports, the structure and cadence of these meetings vary depending on the person and evolve over time. In my experience, executives tend to prefer meetings with a clear agenda, while peers from departments you don’t interact with as often may prefer informal conversations.
Regardless of format, holding these conversations regularly is crucial for building relationships. You don’t want the only time you interact with a peer to be when something has gone wrong. These meetings also provide a space to discuss events that aren’t yet time-sensitive, explore early ideas that may or may not materialize, and create opportunities for serendipity—where a passing comment unexpectedly reveals something relevant to your team.
Calendaring software is terrible. Unless you have an executive assistant, managing recurring one-on-ones at different cadences quickly becomes a nightmare. You lose track of who you should be meeting with and how often, forget to remove meetings that are no longer necessary, and struggle to keep everything organized.
To tackle this, I use a simple spreadsheet—a poor man’s CRM. It’s nothing fancy:
Besides the shared agenda for each meeting, I keep a private document for every person I meet with. Whenever something important but not urgent comes up related to that person or their team, I take a screenshot, save a link, or jot down a quick note in reverse chronological order. This helps me keep track of things I need to bring up without feeling the pressure to act on them immediately.
Avoid name-dropping
When someone is new to a role or a peer group, it’s natural to feel awkward asking questions. A common defense mechanism is shifting the blame—saying you need information or a task completed because “I have to report to my manager on this soon.” It’s an easy way to justify the request, but it causes all sorts of problems.
The biggest issue is that it invites your direct reports and peers to question your role as a leader. Are you adding value, or are you just relaying information up the chain? They wouldn’t be wrong to ask. And if you don’t have a good answer, it might be time to rethink where you’re spending your time as a manager.
Even if your team understands your value, student syndrome kicks in. People will delay giving you the information until right before your meeting with the big boss. That leaves you scrambling to process everything at the last minute, without time to think strategically. Worse, it makes you dependent on these rushed updates instead of having a continuous understanding of what’s happening across your teams.
As tempting as it is, never justify an information request by saying your boss needs it. It’s perfectly reasonable for people to ask why you need certain details. Instead of name-dropping, share the context. This shifts the conversation from a transactional status update to a strategic discussion—one where your reports or peers can help you figure out the best way to achieve the intended outcome, rather than just ticking a box.
More importantly, it reinforces that you’re not just a messenger—you’re a leader who understands and owns the bigger picture.
Plug: Where my attention is at
Update (2025): When this article was published in 2023, we were building an AI-powered Chief of Staff for engineering leaders. Within a year, it attracted 10,000 users, surpassing even well-funded incumbents.
By 2024, demand shifted—not for the assistant itself, but for the technology behind it. Engineering leaders kept asking how we made our AI agents work so reliably at scale. That realization led us to pivot to a developer platform for building AI products.
Leaders spend at least two hours every day just catching up—whether it’s first thing in the morning or after hours of back-to-back meetings. We can’t talk about increasing efficiency in tech while ignoring this massive drain on time and focus.
My co-founder and I have debated this problem for years. With the latest breakthroughs in Artificial Intelligence and Large Language Models, we saw an opportunity to solve it—building something that, until recently, wasn’t even possible.
Our platform integrates with the tools your team already uses, learning not just from the artifacts they create but from how they interact and collaborate. This lets us build an Interest Graph that delivers relevant, timely updates based on the topics and projects that matter to you.
And because we understand how your tools work—and how you use them—we can automate much of the manual work that leaders spend hours on each day.
It’s like GitHub Copilot, but for managers.
Our first release helps both new and experienced managers cut through the noise and focus on what’s most important to them.
We’re launching publicly this Fall and are currently onboarding partners for our private beta. If you’d like to see what we’re building, join the waitlist at Outropy.ai. For more about the company and our vision, you can reach me at phil <at> outropy.ai.