What does a senior engineer actually do? The job description no one writes but every senior engineer is evaluated against.

#Career #Senior #Leadership

Not Just "More Senior"

The senior engineer job description is famously vague — "handles complex technical problems," "works independently," "mentors others" — and the vagueness is a problem because it means different things to different people. The engineer thinks "senior" means "I write harder code." The manager thinks "senior" means "I can assign this person a feature and not worry about it." The recruiter thinks "senior" means "five years of experience." These are all different jobs, and the mismatch between expectations is why senior engineer roles are often disappointing for everyone involved — the engineer feels underutilized, the manager feels let down, and the recruiter is confused about why the hire didn't work out.

The job description I've converged on after years of doing the job and hiring for it is this: a senior engineer is someone who takes a problem that's ambiguous in both requirements and approach, and turns it into a delivered solution that the team can maintain. That description has three parts, and each is important. "Ambiguous in both requirements and approach" means the senior engineer handles the ambiguity that a mid-level can't — not just "how do I implement this?" but "what should we implement, and is this even the right approach?" "Delivered solution" means the senior engineer is accountable for the outcome, not just the code — the solution has to work in production, not just on the developer's machine. "The team can maintain" means the senior engineer optimizes for the team's long-term capacity, not just for the current feature's deadline.

The Three Responsibilities

The first responsibility is technical leadership: setting the technical direction for a project or area, making the architectural decisions that determine the system's shape, and being accountable for the technical quality of the result. Technical leadership isn't about being the smartest person in the room — it's about being the person who facilitates the smartest collective decision, which means creating the space for others to contribute, synthesizing competing viewpoints, and making the call when consensus doesn't emerge. The senior engineer who tries to make every decision themselves becomes a bottleneck; the senior engineer who facilitates good decisions from the team multiplies their impact.

The second responsibility is mentoring: helping mid-level engineers grow into senior engineers, helping junior engineers grow into mid-level, and helping the team as a whole develop its capabilities. Mentoring isn't just answering questions — it's creating the conditions for growth, which means giving people work that stretches them, providing feedback that's specific and actionable, and creating a culture where mistakes are learning opportunities rather than career liabilities. The senior engineer who doesn't mentor becomes a single point of failure — the team depends on them for too much, and when they leave, the team's capability drops. The senior engineer who mentors builds a team that can operate without them, which is the actual measure of leadership.

The third responsibility is cross-team influence: working with other teams to align on standards, share learnings, and avoid duplicated effort. This is the responsibility that's hardest to measure and easiest to neglect, because it doesn't show up in your team's metrics — it shows up in other teams' metrics, and the connection is invisible. But cross-team influence is what prevents the organization from fragmenting into siloed teams that each solve the same problems differently. The senior engineer who participates in cross-team discussions, shares their team's learnings, and adopts other teams' good practices is doing work that compounds across the organization, even though it doesn't show up in any single team's review.

What It Isn't

The senior engineer job isn't "the person who writes the hardest code." Writing hard code is part of the job, but it's not the differentiator — mid-level engineers can write hard code too, given enough time. The differentiator is the judgment about what code to write, what code not to write, and how to structure the code so it's maintainable over time. That judgment is what you're evaluating when you promote someone to senior, and it's what you're paying for when you hire a senior engineer. The senior engineer who writes beautiful code that solves the wrong problem is less valuable than the senior engineer who writes adequate code that solves the right problem, because the right problem is the part that's hard to identify.

The job also isn't "the person who works the most hours." There's a culture in some engineering organizations that equates seniority with availability — the senior engineer is the one who's on call constantly, who responds to Slack at midnight, who works weekends to meet deadlines. That culture is toxic and counterproductive, because it burns out the people the organization needs most and it models unhealthy behavior for the juniors who are watching. The senior engineer I want to work with is the one who sets boundaries, who takes vacations, and who demonstrates that the work is a marathon, not a sprint. That modeling is itself a form of leadership, and it's the kind that the profession needs more of.