The Most Important Part of Engineering Management: Context
BLUF: A good EM's job is, fundamentally, to spend most their time building broad context so that they can tactfully reshare it out in the right way at the right moments.
From IC to EM
I began my career as a new-grad software engineer at Airbnb, where I got a crash course in all things tech: building new services from scratch, refactoring old systems nobody wanted to touch, getting paged at 2 a.m. to fix production outages, collaborating with PMs and designers, and yes, inevitably breaking the site more times than I’d care to admit. I loved it. As an IC, you learn to focus on shipping code. Whether you’re writing design docs or squashing bugs, there’s always the tangible thrill of solving a problem by turning it into a neat little pull request.
Eventually, though, I realized my passion wasn’t just about making good software—it was about building the team that makes software. I found my way toward co-founding a company, Graphite, where our mission is to create developer tooling that helps other teams ship better code. That means we’re essentially an engineering team that builds software to help other engineering teams build their software. My parents may never understand what that means, but I find it incredibly rewarding.
As Graphite grew, I noticed that the scope of my responsibilities had shifted. I was no longer just heads-down coding. Instead, I found myself reading up on management best practices, talking to seasoned engineering managers, and even hiring a leadership coach, all to help me become an effective leader for our growing team. Over the past few years, I’ve hired, let people go, coded in the trenches, run weekly standups, delivered tough-love feedback, dealt with product and roadmap debates, and everything else you can imagine. Now, I’m lucky enough to be mentoring two of our own engineers in their journey to become managers themselves, which has forced me to articulate the often fuzzy question: “What is the job of an engineering manager, really?”
Below is my best attempt at answering that question from the vantage point of an early-stage startup environment. It won’t be the last word on the subject, but if you’re navigating or considering the leap from IC to EM, I hope this helps.
The Real Job of an Engineering Manager
An IC’s job is to build things. It might sound obvious, but it’s worth stating explicitly: the primary responsibility of an individual contributor is to write, review, and ship meaningful code. While collaboration, design reviews, and planning are all critical, the fundamental output of an IC is the codebase changes that push the product forward.
A manager’s job, by contrast, is twofold: (1) build and maintain context, and (2) apply that context to help the team make better decisions. That’s it in a nutshell. But what does “context” really mean, and why can’t an IC just keep track of it themselves?
Building and Maintaining Context
A manager should have a bird’s-eye view of the organization: upcoming product launches, the company’s financial outlook, the top priorities of adjacent teams, the morale and burnout levels on their own team, as well as the big architectural pain points lurking in the codebase. You become something of a “information sponge.” You’re reading Slack threads, attending product reviews, talking with design, keeping an eye on bug metrics, and noticing who might be hitting a wall or feeling frustrated.
It might take half of your week to keep up with this swirl of information. Maybe more. Early in my own transition, I felt uncomfortable spending too much time in meetings or Slack. But the reality is that building this context is the core part of the manager’s job. If an IC tried to absorb all of these details, they would never have time to get into the flow state required for deep, productive coding. That’s why the org needs a manager to do the heavy lifting of data collection and synthesis.
Where do you get this information? From team standups, one-on-ones, coffee chats, incident postmortems, and countless impromptu conversations. You read design specs, watch product demos, and poke around your analytics dashboards. You also need to invest in genuine human relationships. People will share crucial, often delicate tidbits of information only if they trust you. That trust is built over time, through honest conversations and genuine care.
Applying That Context
Once you’ve built a robust picture of what’s going on, you deploy that context in targeted moments. You might be in a planning meeting where people are debating whether to tackle a new feature or refactor an old system. Drawing on your knowledge of the product roadmap, the team’s workload, and the relative importance of tech debt, you can cut through the noise to advocate for the best course of action. You might be sitting down with a high-potential IC who wants to grow into bigger responsibilities; your breadth of perspective helps you give pointed feedback on where they should focus their efforts. Or you might sense that morale is dipping because the team hasn’t shipped something exciting in a while, so you convene a brainstorming session to get people jazzed about a new initiative.
A manager who fails to build context can only offer generalities, like “Let’s just do what’s best for the user.” But a manager with deep context can back up their decisions with specifics: “We can’t prioritize this new feature right now because we’re already committed to a major migration by the end of the quarter, and if we delay that, we’ll blow up next quarter’s product timeline. Plus, I know half the team’s been on-call too often, so adding more complexity now would risk burnout.” That’s powerful, targeted leadership—only possible when you thoroughly understand the landscape.
The Path to Mastery (and a Beating Heart to the Team)
Becoming truly great at engineering management means refining those two skills—context-building and context-application—until it looks almost effortless. You arrive at meetings armed with detailed knowledge, but you don’t bury people in it. Instead, you deliver the critical points with clarity and tact. You sense when someone’s on the verge of feeling overwhelmed and schedule a quick check-in, or you notice that a project is behind schedule but also see that your PM is overcommitted, so you jump in to realign resources and reset expectations.
Managers often shoulder the formal processes that come with running a team—performance reviews, hiring decisions, roadmap planning, conflict resolution—and these tasks can feel large and intimidating. Yet they are fundamentally just high-leverage moments to apply your context. If someone isn’t hitting expectations, you have the bigger picture of why. If a key candidate is on the fence about joining the team, you can share insights on future product vision and the cultural environment. If a product manager wants to double down on a risky feature, you can offer data on capacity, highlight morale concerns, or compare the opportunity cost with other initiatives. Good managers are always integrating the specifics of the situation with the broader narrative, ensuring decisions serve both immediate goals and the company’s long-term health.
At times, you’ll hear the analogy that a manager is like the “beating heart” of the team, circulating information around the organization the way a heart pumps blood to the limbs. ICs are the “hands and feet” doing the visible work that moves the product forward. Without the manager’s steady circulation of context, the system would lack coordination, starve for resources, or chase conflicting priorities. Conversely, a heart without limbs wouldn’t accomplish much in the real world.
What makes a manager “amazing” is the ability to blend those big-picture insights with genuine human connection. People trust you to represent them well in leadership discussions. They know you’ll catch subtle signals—like a developer who’s close to burnout or a new hire who’s still unsure about their place on the team—and offer targeted support. Over time, your calls on hiring, promotions, or roadmap decisions earn a reputation for being smart, fair, and correct more often than not. The credibility you build in these moments leads people to share even more context with you, which further enhances the quality of your decisions. It’s a virtuous cycle where strong relationships lead to better insight, which leads to better interventions, which reinforces those relationships.
In short, an effective engineering manager is a trusted node of information flow and a decisive guide who can marry that context with good judgment—whether it’s helping a junior engineer navigate a tough design problem or steering the entire team away from a low-impact project. The closer you get to that blend of empathy, clarity, and accuracy, the more you’ll embody the heartbeat that keeps your organization healthy and thriving.
Enjoy content about startups and dev-productivity? Consider following me to stay updated with reflections & insights while I build Graphite
Recommended Reading and Closing Thoughts
If you’re new to management (or contemplating the leap), I highly recommend reading The Manager’s Path by Camille Fournier for a practical roadmap of the journey from IC to CTO, as well as High Output Management by Andy Grove for a fundamental look at how to lead teams effectively. Books like The Making of a Manager by Julie Zhou can also offer valuable insights into daily leadership habits and common pitfalls.
Ultimately, if you’ve ever felt the pull to influence how your team collaborates and how decisions are made—and not just how code is written—there’s a good chance you’ll find fulfillment on this path. Yes, you’ll spend less time coding, and yes, you’ll probably spend more time in meetings than you ever thought possible. But done right, management is a profoundly creative and impactful role. You’re still “building something”—only now, instead of just writing code, you’re building and shaping the people, processes, and culture that make the code possible.
That’s the essence of being an engineering manager in an early-stage startup: you’re the heart that circulates knowledge and keeps the team moving in sync, while your ICs are the skilled hands doing the bulk of the visible work. Both are essential, and when done well, each amplifies the other. If you can master these complementary roles—absorbing context and delivering it at the right time—you’ll find that managing engineers can be every bit as satisfying as building the product yourself.