At the early stage of my engineering career, I often wondered, “What do my managers actually do?” What do they do beyond spending their time in meetings and talking to people (the visible part to me)? What was their job?
As an engineer, I thought my role was the hardest—handling complexity, debugging, and shipping features—until I became a manager and faced the same question from others.
“What does the day-to-day of a manager look like?”
This question arises because much of a manager’s work is invisible.
Unlike an individual contributor, whose progress is often measured by the code they write or the features they deliver, a manager’s work shows up in dozens of conversations, decisions, and interventions that are rarely obvious from the outside.
A manager might begin the day planning to review a design document and end it by resolving a conflict between teams, coaching an engineer through a difficult career decision, responding to a production incident, aligning stakeholders on a roadmap change, and making several high-impact decisions.
A manager’s day-to-day work can sometimes be unpredictable, filled with constant context switching and shifting priorities, making every day fundamentally different from life as an individual contributor.
These tasks don’t show up on sprint boards but often have more impact than any single feature a manager could deliver.
This invisible nature of management creates an interesting challenge. Unlike engineering work, where completed tasks provide a clear sense of progress, management often happens through conversations, decisions, coordination, and influence.
Without a clear mental model of your day-to-day activities, it’s easy to feel like you’re spending all day reacting to problems rather than accomplishing meaningful work. This is where a lack of fulfillment often comes from for people taking a leap into management from an IC role, because you can’t easily point to that shiny new feature you shipped.
In a previous post, I wrote about the four areas of responsibility of engineering managers. This post focuses on something more practical: the day-to-day activities that allow managers to guide effectively.
Although these activities may look different depending on whether you’re a frontline manager, director, or executive, they all follow the same underlying cycle:
-
- Gather information
-
- Share information
-
- Make decisions
-
- Influence decisions
-
- Lead execution
-
- Plan
Most of a manager’s day is spent repeatedly moving through this cycle. The better you become at each stage, the more effective you’ll be as a leader.
Information gathering
Every decision, proposed path, and action depends on having an accurate understanding of what is happening within the team, the organization, and the product.
When you are an IC, you have a complete picture of your work. Once you become responsible for people, you can’t use the old methods anymore. You’ll need to be much more intentional about how you gather information.
Information will come from every direction—engineers, managers, customers, executives, dashboards, incidents, metrics, and product feedback. The challenge is dealing with and processing the plethora of information.
No manager can process everything. You’ll need to build capability to filter out the noise and synthesize information into a coherent picture of reality.
Without an accurate grasp of the current state, making great decisions is hard. You might solve the wrong problems, prioritize the wrong work, and miss emerging risks. Thus, a significant portion of your time will be spent gathering context, validating assumptions, and building a deeper understanding of what is happening around you and beneath the surface.
Much of engineering leadership can be viewed as a cycle: gather information, develop understanding, make decisions, and influence outcomes. The quality of each step depends heavily on the quality of the information collected at the beginning.
There are three primary areas where engineering leaders gather information: people, process, and product. I hope to get into this in future posts.
Information sharing
If you think of information gathering as collecting context, then information sharing is about synthesizing that information and ensuring its free flow to those who need it to make well-informed decisions or execute effectively towards the intended outcome.
As a manager, you’ll have access to a broader set of information than the people you lead. You’re expected to maintain not only your team’s context, but also an understanding of the broader organizational context, and to bridge the gap between the two.
Each meeting you attend will present an opportunity for you to gather but also share information. You may gather information from one-on-ones with your reports, company all-hands, conversations with fellow engineering managers, product reviews, metrics reviews, discussions with stakeholders, and regular conversations with your manager and skip manager.
Over time, you’ll accumulate pieces of information that may be valuable to an individual, another team, or your entire organization. Synthesizing this information means deciding what is worth sharing, with whom, when, and at the appropriate level of detail.
Some of the most challenging moments for information sharing I have come across came during organizational change: layoffs, reorganizations, project cancellations, or the departure of a key team member. In these situations, simply communicating the facts isn’t enough. People are looking for clarity, empathy, and confidence. You’ll need to communicate honestly while providing enough context to reduce uncertainty and help the team process the change. The way you deliver difficult information can have as much impact as the information itself.
Decision Making
A large part of any leader’s role is making decisions. Leaders make countless decisions, and you’ll have your fair share as well. And your effectiveness will, in part, depend on the quality of the decisions you make and your ability to execute them. You’ll make decisions about priorities, people, technical direction, investments, risks, and trade-offs every day.
This is also one of the hardest parts of an engineering manager’s role. Decisions are rarely straightforward. More often, you’ll face situations where the available information is incomplete, the options are ambiguous, and the trade-offs are unclear. Waiting for certainty is often a decision in itself—one that can carry its own costs. Some decisions will cost you sleep, agony, and pain, especially when they cost people their jobs. Yet, they still need to be made.
Other times, you will have a conviction about the decision to make but must first align before making it.
Decision-making is a skill that develops through repetition, reflection, and experience. The more decisions you make—and the more you examine their outcomes—the better your judgment becomes. Over time, you build intuition for what matters, what can be ignored, and when to take calculated risks.
Good decision-making starts with understanding reality. This is why information gathering is such a large part of your job. Without that foundation, even well-intentioned decisions can miss the mark. With it, you’re better equipped to make sound decisions and help your team succeed.
Influencing decisions
A significant portion of your time will be spent influencing decisions. Some people think of it as more of an organizational politics; others think of it less so, but at its core, influence is simply the ability to help others understand a perspective, evaluate trade-offs, and make informed decisions.
No team or organization operates in isolation. The actions—or inaction—of other teams can directly impact your team’s ability to succeed. You will rarely have sole decision-making authority over everything that affects your team. Instead, you might have ample chance to provide context, information, data, and perspective that help shape decisions.
As your scope grows, your impact depends less on the work you do yourself and more on the decisions you can influence across the organization.
You will need to influence peers to gain alignment across teams and advocate for your team’s needs. You will need to influence senior leaders by providing clear recommendations and helping them understand trade-offs. You will also need to influence the engineers on your team, guiding them toward better approaches while creating space for them to learn and grow.
I often spend a significant portion of my time figuring out how to get another team to prioritize work that advances my team’s goals. The challenge is rarely that people disagree with the objective; it is that every team has competing priorities, limited capacity, and their own pressures. Before asking for support, I need to understand their goals, constraints, incentives, and timelines. Only then can I frame the request in a way that makes sense from their perspective.
Over time, I have learned that many leadership challenges are not fundamentally technical problems. The technical solution may be straightforward, but success depends on aligning the people responsible for implementing it.
Leadership is less about authority and more about influence. The ability to align people around a shared outcome often determines whether an idea becomes a reality.
Leading and setting directions
Leading and setting direction are among your most visible managerial activities. It’s about helping a group of people move toward a shared goal while creating the conditions that enable them to succeed.
You’ll often spend your day defining a clear path toward a destination and helping your team understand why it matters. A compelling vision gives people purpose, helps them make better decisions, and inspires them to work toward a common outcome.
You may spot trends, technical limitations, or emerging business needs before the rest of the team. For example, you might see that a piece of technology the team depends on is becoming difficult to maintain, or that the current architecture will not scale to meet future growth demand. In these situations, your role is to define a clear direction that moves the team from its current state to a better future state. You’ll spend your time explaining the rationale for the change, why it needs to be done, and helping them buy into it.
At other times, the direction is given to you rather than created by you. You might receive a new business goal or organizational priority. You may spend your day translating that goal into something meaningful for your team—helping them understand why it matters, the opportunities it creates, and how their work contributes to achieving it.
Another part of your day-to-day managerial responsibilities is serving as a role model. Teams pay far more attention to what their leaders do than to what they say. If you expect engineers to write thoughtful design documents, participate constructively in reviews, communicate clearly during incidents, or take ownership of problems, demonstrate those behaviors consistently yourself. By modeling the standards you expect, you make those expectations tangible and credible.
For example, imagine your team consistently struggles with incident management. Simply telling people to improve is unlikely to change behavior. Instead, participate actively during incidents and demonstrate effective practices: communicate clearly while triaging issues, coordinate responders, keep stakeholders informed, and facilitate productive post-incident reviews. As the team repeatedly observes these behaviors, they develop a concrete understanding of what good looks like. Over time, these practices become part of the team’s culture, and the team’s overall effectiveness improves.
Planning
Planning is often viewed as one of the more bureaucratic parts of management. Most people think of quarterly planning, annual roadmaps, and sprint planning. It’s easy to think of planning as something fixed and done within a specific time of the year or month. At least, I used to think about it that way. While those are part of planning, they are not all there is to planning.
I think of planning as deciding how you’ll move from the current state to a desired future state. It could appear in a document that outlines how to approach a task before executing it to achieve a specific goal. It could show up in a document forecasting headcount, budget, and projects for the next quarters.
Every meaningful change requires a plan. Whether you’re improving a process, migrating to a new system, growing your team, or developing your team, planning is the activity that connects today’s reality with tomorrow’s goals.
Once you think about planning this way, you begin to see it everywhere in your day-to-day. And it’s one managerial activity.
Think of the time you wanted to migrate to a new database. You created a plan, right?
Think of the time your team was delivering more slowly than expected? You identified the underlying causes and created a plan with concrete steps to get the execution moving again.
Remember when you were asked to move a goal by X%? You thought hard and developed a way to realistically reach that target and what is needed. That is also a plan.
Remembered when your team was wallowing in incidents? You figured out the root cause, and outlined and discussed how to get the team out of that with your managers? That is still also a plan.
As you lead your team, there will always be a desired future state, no matter how little that is. You will need to articulate what that desired state is, what needs to be done to get there, and who is doing what. This is planning, and a chunk of your day will be spent on it.
In conclusion, many of your day-to-day activities will fall into most of these categorizations, and they’re managerial activities. Activities through which managers lead.