A few months ago, a developer I was mentoring asked me a question that stopped me cold: "What do you actually do all day? You barely commit any code."
He wasn't being disrespectful. He was genuinely confused. He'd been heads-down shipping features for three years and assumed the path to senior engineer was just… more of that. Faster code. Harder problems. More pull requests.
He's not alone. Most mid-level engineers have a dangerously incomplete picture of what senior engineers actually do. And that misunderstanding is the single biggest reason people stall in their careers. Senior engineers don't just write code. In my experience, they spend 50-70% of their time on activities that never show up in a git log. System design. Mentorship. Managing technical debt. Cross-functional leadership. These are the hidden roles that separate people who have a senior title from people who actually drive senior-level impact.
Here's what nobody tells you about those roles.
What Do Senior Engineers Actually Do Beyond Writing Code?
A senior engineer's job isn't to produce the most code. It's to produce the most leverage. Sarah Drasner, who served as VP of Engineering at Google, has described senior engineers as "force multipliers." Their architectural decisions and guidance can make a team of five as productive as a team of ten.
That multiplier effect is the thing most people miss. Early in your career, your impact is roughly proportional to your hours. You write code, it ships, done. But that model breaks at scale. A senior engineer who spends a week designing the right abstraction might save their team months of rework. A senior engineer who mentors a struggling junior might turn them into a reliable contributor within a quarter.
I used to roll my eyes at the "they just go to meetings" stereotype. Then I became one of those people. Yes, senior engineers spend more time in meetings. But the good ones are using those meetings to shape decisions, resolve ambiguity, and keep the team pointed in the right direction. The meetings are the work.
As Gergely Orosz writes in The Pragmatic Engineer, a primary role of a senior engineer is to reduce complexity. Taking ambiguous, messy business problems and turning them into simple, maintainable, scalable technical solutions. That's not something you do in a code editor. It's something you do in conversations, on whiteboards, and in design documents.
If you've been wondering where this shift fits in the broader evolution of engineering work, I wrote about it in how software engineering is becoming 'plan and review'. The trend is accelerating, and senior engineers are at the center of it.
Role 1: System Design — The Decisions That Outlive Your Code
The first hidden role is system designer. Not the whiteboard-exercise-for-interviews kind. I mean making the architectural decisions that your team will live with for years.
I've shipped systems that handled tens of millions of requests, and the hardest part was never writing the code. It was choosing the right boundaries. Where do you split services? What data model supports the business requirements you know about and the ones you can see coming? When do you build for scale and when do you intentionally keep things simple?
These decisions compound. A good architectural choice made early saves hundreds of engineering hours downstream. A bad one creates the kind of accidental complexity that slowly grinds a team to a halt. I've lived through both.
What makes system design a senior-level skill: it requires holding multiple competing concerns in your head simultaneously. Performance versus simplicity. Consistency versus availability. Ship-it-now versus build-it-right. Mid-level engineers tend to optimize for one dimension. Senior engineers navigate the tradeoffs.
Will Larson, author of Staff Engineer: Leadership Beyond the Management Track, describes several archetypes for senior+ engineers, including the "Architect" who designs broad systems and the "Tech Lead" who directs a team's technical approach. Both roles center on decisions that shape technical direction far beyond any single feature.
If you want to grow into system design, start by asking why your current architecture looks the way it does. Trace the decisions backward. Understand the constraints that existed when those choices were made. That historical context is what separates someone who can design a system from someone who can only implement one.
Role 2: Mentorship — Your Biggest Leverage as a Senior Engineer
I spent years thinking mentoring meant occasionally reviewing a junior's code and leaving polite comments. That's not mentorship. Real mentorship is teaching someone how to think about problems. Not just how to solve the one in front of them.
After leading teams for over a decade, I've seen this pattern play out dozens of times: a strong senior engineer who mentors well doesn't just make their mentee better. They raise the bar for the entire team. The mentee starts writing better code, which means fewer bugs in review, which means the whole team ships faster. It compounds.
What effective senior-level mentorship actually looks like:
- Pairing on architectural decisions, not just code
- Asking questions that force the mentee to work through tradeoffs themselves (this is harder than just giving the answer, and slower, and worth it)
- Giving feedback on communication and documentation, not just technical output
- Creating enough psychological safety that people admit what they don't know
- Knowing when to let someone struggle versus when to step in
This matters even more in remote environments. Joel Worrall, CTO at Over, has pointed out that senior engineers in remote settings have to proactively create clarity through documentation, set standards for async communication, and catch ambiguities before they slow everyone down. In a distributed world, mentorship isn't a nice-to-have. It's infrastructure.
And here's something I tell every mid-level engineer I work with: you don't need the title to start. Explain your PR decisions more thoroughly. Write better commit messages. Document the why behind your technical choices. That's mentorship in action, and people notice.
[YOUTUBE:CHVtYzg3cfQ|4 REGRETS from my career as a Senior Software Engineer]
Role 3: Managing Technical Debt — The Boring Work That Keeps Everything Running
This is one of those things where the boring answer is actually the right one. Technical debt management is unglamorous. Nobody gets a standing ovation for paying it down. But it's one of the most important things senior engineers do.
Ward Cunningham, who coined the technical debt metaphor in 1992, originally described it as the cost of shipping code built on an incomplete understanding of the problem domain. You build what you know, ship it, learn from real usage, then refactor as your understanding deepens. It was about learning, not about cutting corners. The popular interpretation — "we chose the quick-and-dirty approach" — is actually a misreading of Cunningham's original idea.
Either way, the debt accumulates. And senior engineers are the ones who see it clearly enough to manage it.
I've been on teams where technical debt was treated as someone else's problem. "We'll fix it later." Later never comes. What comes instead is a codebase that takes three days to add a feature that should take three hours. Deployment pipelines that break every other week. Tests that nobody trusts. I've watched good engineers quit over this.
Senior engineers manage technical debt by doing three things:
- Making it visible. You can't fix what nobody acknowledges. This means quantifying the cost: "this legacy service costs us 15 hours of engineering time per sprint in workarounds."
- Prioritizing strategically. Not all debt is equal. Some debt is fine to carry for years. Some will kill your velocity in six months if left untreated. Knowing which is which is the skill.
- Negotiating with product. This is the cross-functional part. You translate technical debt into business language: "If we invest two sprints in this migration, we cut our incident rate by 60% and ship features 30% faster."
If you've dealt with the specific challenge of AI-generated code introducing debt, I broke down practical strategies in how to audit and refactor vibe-coded applications. Same principles, different scale.
Role 4: Cross-Functional Leadership — Speaking the Language of the Business
The fourth hidden role is the one that surprises most engineers: becoming the technical voice in non-technical conversations.
Senior engineers sit at the intersection of engineering, product, and business. They translate. They explain why a feature that "sounds simple" requires rethinking the data model. They push back when a product manager's timeline doesn't account for infrastructure work. They advocate for engineering investments that don't have obvious customer-facing value.
Tanya Reilly, author of The Staff Engineer's Path, calls this "managing up" — providing clear technical context to product managers and leadership so they can make informed decisions. It's not about saying no. It's about giving decision-makers the information they need to say yes to the right things.
I've seen this make or break teams. One of the most impactful things I've done in my career wasn't writing code at all. It was building a one-page technical summary that helped a VP understand why we needed to delay a launch by three weeks to fix a reliability issue. That single document prevented an outage that would have cost far more than three weeks of delay.
This role requires skills that most engineering curricula don't teach: writing clearly for non-technical audiences, presenting tradeoffs without drowning people in implementation details, building trust with stakeholders who don't speak your language. None of this is glamorous. All of it matters.
Want to practice? Next time your team makes a technical decision, write a one-paragraph summary that a product manager could understand. If you can explain why without using jargon, you're building the muscle.
The engineers who shape their companies aren't the ones who write the most code. They're the ones who make sure the right code gets written.
How Do You Grow Into These Senior Engineer Roles?
Here's the thing nobody's saying about the senior engineer transition: it's not a promotion. It's a career change.
The skills that got you from junior to mid-level — learning frameworks, writing clean code, debugging efficiently — are table stakes at the senior level. They won't get you further. What will is developing real competence in the four roles I've described: system design, mentorship, technical debt management, and cross-functional leadership.
As I wrote about in what's left for software engineers as AI writes more code, the engineers who thrive aren't the ones who type the fastest. They're the ones who think the clearest.
So here's my challenge: for the next two weeks, track how you spend your time. If 90% of it is writing new code, you're building mid-level skills. Start intentionally carving out time for design reviews, mentoring conversations, and stakeholder communication. It will feel uncomfortable. It will feel less productive. Do it anyway.
The engineers who drive real impact at senior and staff levels aren't coding machines. They're systems thinkers, force multipliers, and translators between the technical and the human. Start building those muscles now. The title will follow. Or it won't, and you'll realize you stopped caring about the title because the impact became obvious on its own.
Originally published on kunalganglani.com