Engineering Culture & Career

Engineering Culture & Career

Engineering is a craft and a profession, and career growth in it is neither linear nor automatic. Understanding the career ladder, the different paths available, and the practices that distinguish engineers who grow from those who stagnate is essential knowledge that most engineers learn too late.

The Engineering Ladder

Most engineering career ladders look like:

• Junior Engineer: executing assigned tasks with guidance; learning the codebase, tools, and practices
• Engineer (Mid): working independently on well-defined problems; contributing to design discussions
• Senior Engineer: independently driving work that spans multiple components; mentoring junior engineers; making scope-appropriate design decisions
• Staff Engineer: technical direction at the team or multi-team level; solving ambiguous, cross-team problems; organizational influence
• Principal/Distinguished Engineer: company-level technical direction; setting the technical strategy for a business domain; recognized externally

The key insight: each level requires a broader radius of impact. Junior engineers impact their own code. Senior engineers impact their team's code. Staff engineers impact multiple teams. Principal engineers impact the company or industry.

Individual Contributor vs Management Paths

Around the Senior level, engineers choose:

Management path (Engineering Manager): hiring, performance management, career development for reports, organizational health. Stops writing code regularly (usually). Multiplies output through people.

IC (Individual Contributor) path (Staff → Principal → Distinguished): technical leadership, architecture, engineering strategy. Multiplies output through technical influence and high-leverage technical work.

Neither is inherently superior. A great Staff Engineer has 10x leverage on team output through architecture decisions and mentorship. A great Engineering Manager has 10x leverage on team output through hiring, culture, and removing organizational friction.

A common mistake: great engineers get promoted to management because they were great engineers. Management requires entirely different skills: coaching, conflict resolution, ambiguity tolerance, political navigation. Good at coding ≠ good at managing.

What Gets Engineers Promoted

Junior → Mid: demonstrates reliability; delivers assigned work without supervision; code passes review without major issues; asks good questions.

Mid → Senior: owns problems end-to-end (writes the code, tests, deploys, monitors); makes technical decisions others follow; identifies issues before they become crises; mentors more junior engineers effectively.

Senior → Staff: the "senior engineer" promotion often happens by continuing to do more of the same, better. The Staff promotion requires demonstrating impact at a larger scope: influencing architecture decisions that affect multiple teams, solving problems that others couldn't frame, being a technical resource across the organization.

Common failure mode: high-performing Senior Engineers who optimize for local technical excellence without developing organizational influence. Being the best coder on the team is not sufficient for Staff — influence, communication, and cross-team impact are required.

Glue Work and Visibility

Tanya Reilly's "Being Glue" describes the invisible work that holds engineering teams together: writing documentation, onboarding new engineers, improving processes, coordinating between teams, running post-mortems.

This work is essential but often invisible to performance reviewers. Engineers — particularly underrepresented engineers who are socialized to take on supporting roles — can spend 40% of their time on glue work and receive "needs more technical impact" in their performance review.

The solution: make glue work visible. Describe its impact explicitly in reviews ("I documented the payment module's architecture, reducing onboarding time for three new engineers"). Ensure the manager knows the context. Negotiate with your manager about how much glue work is appropriate versus individually technical work.

Feedback and Performance Reviews

Giving feedback: the SBI framework — Situation (specific situation), Behavior (what happened), Impact (the effect). "In the sprint review last Tuesday [S], you interrupted Alice three times while she was presenting [B], which made her unable to finish her point and left the audience confused [I]."

Receiving feedback: resist the defensive reaction. Separate the message from the delivery. "Thank you for telling me" is the correct response even if the feedback stings. Ask clarifying questions. Decide whether to act on it.

Performance reviews: document your impact throughout the year. Don't leave it to memory at review time. Maintain a "brag document" — a running list of accomplishments, impact statements, and feedback received. Reviews favor those with clear, specific impact over those with vague impressions of being "a good team player."

Engineering Culture Principles

Psychological safety (Amy Edmondson): the shared belief that the team is safe to take interpersonal risks — ask questions, admit mistakes, propose ideas — without fear of punishment or humiliation. Teams with high psychological safety innovate more, learn faster from failures, and retain members longer.

Disagree and commit: healthy teams can have strong disagreements, reach a decision, and then fully commit to that decision even if you were on the losing side. Publicly relitigating closed decisions after commitment undermines team coordination.

Learning from failure: high-performing engineering teams treat failures as learning opportunities. Blameless post-mortems, safe-to-fail experiments, and normalization of "I don't know" create environments where people take intelligent risks rather than optimizing for safety.

Craft and mastery: engineering is a craft that rewards deliberate practice. The best engineers read code (open source, colleagues' code), write code outside of work (side projects, contributions), study systems they use (database internals, networking), and teach (writing, talks, mentorship). Mastery is pursued, not acquired incidentally.

Managing Up

Every engineer, regardless of level, has a manager. Managing up — communicating effectively upward in the organization — is a professional skill:

Give your manager no surprises: if a project is off track, tell your manager early. Managers hate surprises at deadline. Early warning enables course correction.

Understand their concerns: your manager has stakeholders too. Understanding their pressures helps you frame your work in terms that matter to them.

Ask for what you need: blocked on a dependency? Tell your manager and ask them to unblock it. Need clarity on priorities? Ask explicitly. Managers cannot help with what they don't know about.

Own your career: no one is going to manage your career for you. Know what you want to learn, what work would get you to the next level, and what gaps you have. Bring this to your 1:1s; your manager can help only if you're clear about what you want.