← Learning Pathways Learning Pathway

Intermediate Software Engineer to Senior Software Engineer

🕑 18-36 months Software Engineering

Develop the technical leadership, architectural judgment, and influence that make you the person the team relies on for hard decisions and complex problems.

🎯 Focus Areas

Architectural Judgment

Senior engineers make decisions that live in the codebase for years. You need to develop the ability to evaluate trade-offs at the system level, not just the component level. This means understanding non-functional requirements like scalability, operability, and security as deeply as functional ones.

Cross-Cutting Technical Ownership

Seniors own the hard, cross-cutting concerns that no single feature team naturally takes responsibility for - observability, performance, security, and technical debt. Taking ownership of these requires both technical depth and the influence to get others to care.

Mentoring and Growing Others

A senior engineer's multiplier effect comes through others. Structured mentoring, thoughtful code review, and deliberate knowledge sharing are how you scale your impact beyond what you can personally build. The best seniors make the engineers around them measurably better.

Technical Communication

Senior engineers can explain complex technical topics to non-technical stakeholders without dumbing them down. They write design documents that inform decisions rather than justify ones already made. They are comfortable being the technical voice in cross-functional conversations.

Setting Quality Standards

Seniors define what good looks like for their team - in code, in testing, in operational readiness, and in engineering process. This is not about enforcing rules but about building shared norms through example, conversation, and occasionally pushback.

Skills & Behaviours to Develop

Skills to Develop

  • Design systems that span multiple services or teams, identifying integration points, failure modes, and data ownership boundaries.
  • Evaluate and adopt new technologies with structured due diligence - proof of concepts, team feedback, operational risk assessment, and documented recommendation.
  • Write architecture decision records that capture context, options considered, and rationale clearly enough that an engineer two years from now can understand why a decision was made.
  • Lead the technical response to a production incident including diagnosis, mitigation, root cause analysis, and systemic follow-up.
  • Define and champion observability standards for your team including meaningful SLIs, alerting thresholds, and dashboards that actually surface real problems.
  • Conduct structured technical interviews that reliably distinguish between candidates of different calibres.
  • Identify and drive down technical debt strategically - making the business case for investment in quality and sequencing work to maximise impact.
  • Facilitate technical design sessions with multiple stakeholders, building consensus without sacrificing technical quality.

Behaviours to Demonstrate

  • Proactively identifies architectural risks in upcoming work and raises them before they become production problems.
  • Gives technical direction to the team that is clear, reasoned, and open to challenge - not handed down as decree.
  • Runs code review as a teaching activity, providing context and rationale alongside feedback rather than just marking issues.
  • Speaks plainly about technical complexity to product managers and stakeholders, making trade-offs visible and understandable.
  • Takes responsibility for the team's technical health metrics - test coverage, build times, incident frequency - treating them as engineering outputs to be improved.
  • Produces design documents that the team actually reads and that change the outcome of technical decisions.
  • Mentors intermediate engineers with a structured approach, tracking their growth and adjusting support over time.
🛠 Hands-On Projects
1 Lead the design and implementation of a significant system component that involves multiple services, writing the design document, facilitating review, and tracking delivery.
2 Build out the observability layer for a service your team owns - defining SLIs, creating meaningful dashboards, and setting up alerting with appropriate thresholds.
3 Run a structured technical spike on a technology your team is considering adopting, producing a written recommendation with evidence.
4 Identify a significant piece of technical debt in your system, make the business case for addressing it, and lead the work to resolve it.
5 Design and deliver a team-level engineering standard - for testing, for API design, or for error handling - and get it adopted through persuasion rather than mandate.
6 Mentor an intermediate engineer over a three-month period with explicit goals, regular check-ins, and a written summary of their growth.
AI Literacy for This Transition
AI-assisted architecture and critical AI governance
1

Use AI to explore architectural options for complex systems by describing constraints and asking for multiple design approaches, then stress-test each option against real non-functional requirements.

2

Develop a team-level view on appropriate use of AI coding tools - what types of code warrant AI assistance, what types require more human judgment, and what review standards apply to AI-generated code.

3

Evaluate AI-generated code for production readiness with the same rigour you would apply to human-written code - error handling, logging, security, performance, and testability.

4

Experiment with AI for incident investigation by using it to reason over logs, traces, and error messages, and assess how reliably it surfaces the right hypotheses.

5

Build the habit of documenting where AI tools were used significantly in your design process so that future engineers understand the provenance of decisions.

6

Research and stay current on AI coding tool capabilities and limitations - the landscape changes quickly and your team will look to you for guidance on what to trust.

📚 Recommended Reading

Designing Data-Intensive Applications

Martin Kleppmann

The definitive reference for reasoning about distributed systems, consistency, and the real trade-offs in data architecture - essential for senior-level system design.

Staff Engineer: Leadership Beyond the Management Track

Will Larson

The clearest map of what technical leadership looks like at and beyond the senior level, grounded in real examples from engineers who have done it.

An Elegant Puzzle: Systems of Engineering Management

Will Larson

Understanding how engineering management works makes you a better technical leader - this book is as useful for seniors as it is for managers.

Release It!

Michael T. Nygard

A masterclass in designing systems for production reality - stability patterns, capacity antipatterns, and the operational thinking every senior engineer needs.

Team Topologies

Matthew Skelton and Manuel Pais

Provides the vocabulary and mental models for thinking about how team structure shapes architecture, which becomes essential when you start influencing cross-team technical decisions.

🎓 Courses & Resources

System Design for Tech Interviews and Beyond

Educative.io

Forces structured thinking about system design problems at scale - the practice of explaining trade-offs clearly is as valuable as the content.

Cloud Architecture with AWS or Azure

A Cloud Guru

Senior engineers need fluency in cloud architecture patterns, not just the ability to use cloud services tactically.

Observability Engineering

Honeycomb / O'Reilly

Builds the mindset and tooling knowledge to instrument systems for real-world debugging rather than just metric collection.

Technical Writing for Engineers

Google / Coursera

A senior engineer who can write clearly has disproportionate impact - design documents, RFCs, and incident reports all benefit from deliberate writing practice.

📋 Role Archetypes

Review the full expectations for both roles to understand exactly what good looks like at each level.

→ Intermediate Software Engineer Archetype → Senior Software Engineer Archetype