Skip to main content

Learning & Growth

The best engineers are not the ones who already know everything. They're the ones who learn deliberately, who treat skill development with the same discipline they bring to writing code. Growth doesn't happen by accident. It happens when you create the structures, habits, and expectations that make it unavoidable.

Why this matters​

S&P's value of Evolution is not a motivational poster. It's a bet that people who continuously improve will build better software, make better decisions, and deliver more value to clients over time. The alternative (a team that ships the same way it did two years ago, using the same patterns, making the same mistakes) is a team that's falling behind whether it feels like it or not.

Learning and growth also feed directly into Merit. If the company recognises and rewards capability, there has to be a credible path for people to develop that capability. Without structured growth, merit-based culture becomes a fixed hierarchy where early impressions calcify into permanent assessments.

The standard​

Engineering career ladder​

S&P uses a career ladder that defines expectations at each level across four dimensions: technical skill, delivery, collaboration, and influence. The ladder is not a promotion checklist: it describes what sustained performance looks like at each level, so engineers and their managers have a shared language for growth conversations.

LevelTechnical skillDeliveryCollaborationInfluence
JuniorDelivers well-defined tasks with guidance. Follows established patterns. Asks questions when stuck rather than guessing.Completes assigned work within sprint commitments. Communicates blockers early.Participates in code review and team ceremonies. Receives feedback constructively.Primarily within their own work.
Mid-levelWorks independently on features end-to-end. Makes sound technical decisions within a known problem space. Understands the "why" behind patterns.Owns features from ticket to deployment. Estimates work accurately. Balances quality and speed.Provides useful code review feedback. Mentors juniors informally. Shares knowledge in team context.Within the project team.
SeniorDesigns solutions for ambiguous problems. Identifies and addresses technical debt strategically. Evaluates trade-offs with business context.Drives delivery of complex features across sprint boundaries. Unblocks others. Spots risks before they become problems.Elevates the team through mentorship, code review, and architectural guidance. Resolves technical disagreements constructively.Across projects and the engineering organisation.
Lead / StaffSets technical direction for projects. Makes architectural decisions that affect multiple teams. Identifies systemic problems and drives solutions.Accountable for technical delivery of an entire project or product area. Coordinates with DMs and stakeholders on scope and timeline.Builds team capability systematically. Creates processes and standards that scale beyond individual projects.Across the organisation and externally (clients, community).

How to use the ladder:

  • Growth conversations reference the ladder explicitly. Instead of "you need to step up," the conversation becomes "at the senior level, we expect you to identify technical debt strategically: here's an example of what that looks like, and here's where you're not doing it yet."
  • Promotion decisions use the ladder as evidence. The question is not "has this person been here long enough?" but "is this person consistently performing at the next level across all four dimensions?"
  • The ladder is public. Everyone can see what's expected at every level. There are no secret criteria.

Skill development expectations​

Growth is not optional, it's part of the job. Every engineer is expected to be actively developing skills, and the organisation is expected to create conditions that make this practical, not aspirational.

Dedicated learning time. S&P allocates time within each sprint for learning activities. This is not "leftover time after all the tickets are done", it's scheduled, protected, and expected. The amount varies by project load, but the principle is non-negotiable: if 100% of an engineer's time goes to ticket delivery, growth stalls and eventually so does delivery quality.

Practically, this means:

  • Engineers dedicate time each sprint to deliberate skill development: reading, building, experimenting, or teaching.
  • This time is visible on the sprint board, not hidden. Managers and DMs know it exists and protect it.
  • The engineer chooses what to learn, guided by their growth plan and the team's technical needs. Self-directed learning with loose guidance beats prescribed curricula.

Growth plans. Every engineer maintains a lightweight growth plan: reviewed quarterly and updated as priorities shift. The plan is a simple document:

  1. Where I am: Current level on the career ladder. Strengths and gaps relative to the next level.
  2. Where I'm heading: Target skills for the next quarter. These should be specific and observable ("lead an architecture review for a real project"), not vague ("get better at architecture").
  3. How I'll get there: Concrete actions: courses, books, mentorship, stretch assignments, side projects, conference talks.

Growth plans are a conversation tool, not a bureaucratic form. The manager and engineer review them together quarterly, but the engineer owns the plan.

The DRI model for growth​

S&P's DRI (Directly Responsible Individual) model from Engineering Principles is one of the most powerful growth mechanisms available, but only if it's used intentionally.

When you assign DRI ownership of a system or process, you're giving someone accountability, decision-making authority, and a reason to learn deeply. A junior engineer who becomes DRI for the team's test infrastructure will learn more about testing in three months than they would in a year of being told to "write more tests."

Using DRI assignments for growth:

  • Rotate DRI assignments every 6-12 months. Long-term ownership builds depth; rotation builds breadth. Both matter.
  • Assign DRI roles that stretch people slightly beyond their current level. A mid-level engineer owning a service-level concern (monitoring, dependency updates, CI pipeline) develops senior-level instincts.
  • The previous DRI stays available as a mentor during the transition. Handoff is not abandonment, it's a teaching opportunity.
  • Document the scope of each DRI role. "DRI for the API" is too vague. "DRI for the API service: owns schema design decisions, coordinates breaking changes with frontend, monitors error rates" gives someone a clear mandate.

Technical mentorship​

Mentorship at S&P is structured, not incidental. Pairing a junior with a senior and hoping they "absorb" knowledge is not mentorship, it's proximity.

How mentorship works:

  • Every engineer in their first year at S&P has an assigned technical mentor outside their direct project team. This creates a safe space for questions and prevents the new hire from being entirely dependent on their tech lead for guidance.
  • Mentors and mentees meet regularly: typically fortnightly for 30 minutes. The meeting has a loose structure: what are you working on, what are you struggling with, what do you want to learn next.
  • Mentors don't have to be senior engineers. A strong mid-level engineer can mentor a junior effectively. The requirement is that the mentor is further along in the specific area the mentee wants to develop, and that they're willing to invest the time.
  • Mentorship is tracked and recognised. It shows up in performance conversations as evidence of collaboration and influence, it's not volunteer work that goes unnoticed.

Cross-project mentorship. When possible, pair mentors and mentees from different projects. This creates cross-pollination, the mentee gets exposed to different codebases, different client contexts, and different approaches. It also builds the inter-team relationships that make knowledge sharing natural.

Code review as a learning tool​

Code review is the most underrated learning mechanism in engineering. Every PR review is a micro-learning opportunity: for both the reviewer and the author.

For reviewers: Reviewing code written by someone more experienced exposes you to patterns and techniques you wouldn't encounter in your own work. Reviewing code written by someone less experienced forces you to articulate why something matters, which deepens your own understanding.

For authors: Review feedback is the most targeted, contextual learning you'll get. It's specific to a problem you just solved, delivered while the context is fresh, and directly applicable. A review comment that explains why a different approach is better is worth more than a chapter in a textbook.

Deliberate review assignments. Don't always assign reviews to the most senior person or the most available person. Assign reviews to the person who will learn the most from reviewing that code. A junior engineer reviewing a senior's implementation of a caching layer learns more from that review than from any tutorial.

See Code Review for the full review process, PR size guidelines, and reviewer expectations.

Knowledge sharing mechanisms​

Knowledge that stays in one person's head is organisational risk. Knowledge that's shared becomes capability the whole team can build on.

Tech talks and lightning talks. S&P runs regular internal tech talks: typically monthly, with a mix of prepared presentations (20-30 minutes) and lightning talks (5-10 minutes). These are not optional for presenters; every engineer presents at least once per year.

Why this matters more than it seems: preparing a talk forces you to organise your understanding of a topic. You can't explain something clearly unless you understand it clearly. The learning happens in the preparation as much as the delivery.

Topics that work well:

  • Post-mortems from real project incidents (anonymised if client-sensitive)
  • Deep dives into a library or tool the team uses but few people understand well
  • Architectural walkthroughs of interesting systems (reference Section 7: Architecture & System Design)
  • Lessons learned from a completed project
  • Demonstrations of new tools, techniques, or patterns discovered during learning time

Brown bags and reading groups. For teams that want deeper engagement with a topic, run a reading group: pick a book, assign chapters, discuss weekly. Past reading groups at S&P have covered topics like system design, API design, and testing strategy. The social commitment of a group makes it harder to procrastinate and easier to discuss ideas.

Internal documentation as knowledge sharing. When you solve a hard problem, write it down. Not as a blog post: as documentation in the place where someone with the same problem will look. A troubleshooting guide in the project wiki, a decision record in the repo, a runbook in the ops documentation. The Confluence L&D space is the hub for learning resources, templates, and shared knowledge at S&P.

Onboarding: the 30/60/90 day plan​

A new engineer's first 90 days set the trajectory for their next two years. A structured onboarding programme accelerates ramp-up, reduces the burden on the existing team, and makes the new hire feel competent faster, which directly affects retention.

Days 1-30: orient.

  • Complete the S&P engineering setup checklist (tooling, accounts, access, see Developer Experience & Setup)
  • Pair with a buddy (different from the formal mentor) for day-to-day questions and social onboarding
  • Read the playbook sections relevant to their role: at minimum, Engineering Principles, Code Review, and Code Standards
  • Make their first contribution: a small, well-scoped PR that gets them through the full development workflow: branch, implement, PR, review, merge, deploy
  • Meet their tech lead, mentor, and DM in one-on-one conversations
  • Understand the project context: client, users, architecture, current sprint goals

Days 31-60: contribute.

  • Own a feature or user story end-to-end with support from the tech lead
  • Start reviewing PRs from teammates (see Code Review as a learning tool above)
  • Attend an architecture review or decision discussion to understand how design decisions are made
  • Identify one area where they need to upskill and start their growth plan
  • Give and receive their first mid-sprint or sprint retro feedback

Days 61-90: accelerate.

  • Deliver features independently, seeking review rather than guidance
  • Take on a DRI role for a small, well-scoped area (a test suite, a documentation section, a CI job)
  • Present a lightning talk to the team: even something small, like a tool they discovered or a debugging technique
  • Complete their initial growth plan with their manager and mentor
  • The manager and the new engineer assess the onboarding together: what went well, what was missing, what should change for the next hire

Onboarding is a team responsibility, not an HR process. The tech lead, buddy, and mentor each own a piece. If a new hire feels lost after two weeks, that's not their failure, it's a failure in the onboarding system.

Conference attendance and external learning​

Exposure to the broader engineering community prevents insularity. Engineers who only learn from internal sources eventually optimise within a narrow frame of reference.

Conference attendance. S&P supports conference attendance for engineers who will bring value back to the team. The expectation is reciprocal: if the company funds your attendance, you share what you learned: through a tech talk, a written summary, or a concrete change to how we work.

Not every conference is worth attending. Evaluate:

  • Does the topic align with the engineer's growth plan or the team's technical direction?
  • Is the conference known for high-quality, practical content?
  • Will the engineer be actively engaged (attending talks, networking, asking questions) or passively present?

Open source contribution. Contributing to open source projects that S&P depends on benefits the whole team: bugs get fixed, features get added, and the engineer gains deep understanding of a library they use daily. S&P encourages open source contribution as part of learning time when the contribution is relevant to the team's technology stack. Open source contributions make strong portfolio evidence and help S&P's reputation in the broader engineering community.

Cross-pollination between teams​

One of the risks of a project-based consultancy is knowledge silos. Each project team develops its own patterns, solves its own problems, and builds expertise that never leaves the team. Cross-pollination is the deliberate practice of breaking those silos.

Mechanisms that work:

  • Cross-project code review. Periodically ask an engineer from another project to review a PR. Fresh eyes catch things that team-internal reviewers miss, and the reviewer learns a new codebase.
  • Rotation between projects. When practical (client contracts, project timelines), rotate engineers between projects for a sprint or two. This is the most effective cross-pollination mechanism but also the most disruptive: use it strategically, not constantly.
  • Shared channels for technical discussions. A Slack channel where engineers from all projects can ask questions, share discoveries, and discuss approaches. This only works if people actually use it: seed it with real questions and let momentum build.
  • Architecture review participation. Include at least one engineer from outside the project in every architecture review (see Architecture & System Design). This guarantees cross-project exposure at the design level.
  • Standardised tooling and templates. When every project uses the same CI pipeline, the same code standards, and the same project structure, switching between projects is less disorienting. The Developer Experience section and the engineering-forward template exist for this reason.

Building T-shaped engineers​

The goal of S&P's growth practices is to develop T-shaped engineers: deep expertise in one or two areas (the vertical stroke of the T) combined with working knowledge across the full stack and delivery lifecycle (the horizontal stroke).

Why T-shaped over specialists or generalists:

  • Pure specialists create bottlenecks. When the only person who can touch the database is on holiday, work stops.
  • Pure generalists lack the depth to solve hard problems. They can contribute everywhere but own nothing.
  • T-shaped engineers can own their domain confidently while contributing meaningfully outside it. A frontend specialist who understands API design, database indexing, and deployment pipelines can participate in architectural discussions, review backend PRs intelligently, and unblock themselves when a ticket touches the full stack.

How to build the T:

  • The vertical stroke (depth) comes from DRI ownership, mentorship, and sustained work in an area. You get deep at something by being responsible for it, not by reading about it.
  • The horizontal stroke (breadth) comes from cross-pollination, code review of unfamiliar code, tech talks, and deliberate exposure to other parts of the stack. Growth plans should include at least one breadth goal each quarter.

Performance reviews for engineers​

Performance reviews at S&P are structured around the career ladder and grounded in evidence, not impressions. They are conversations between the engineer and their manager about what happened, what it means, and what comes next.

Frequency. Formal reviews happen twice a year. Informal feedback happens continuously: in code review, in sprint retros, in one-on-ones. If the formal review contains surprises, the informal feedback loop is broken.

Structure of a review:

  1. Self-assessment. The engineer assesses their own performance against the career ladder dimensions and their growth plan goals. This is the starting point, not an afterthought.
  2. Evidence. Both the engineer and the manager bring concrete examples: PRs, project outcomes, feedback from peers, mentorship contributions, tech talks, incident responses. The career ladder makes this easier, each dimension has observable indicators.
  3. Discussion. Where do the self-assessment and the manager's assessment align? Where do they diverge? What context does one have that the other doesn't?
  4. Growth plan update. Based on the review, update the growth plan for the next period. What should the engineer focus on? What support does the organisation need to provide?

What makes a good review:

  • It references the career ladder explicitly, not vaguely.
  • It contains specific examples, not general impressions ("you delivered the payments integration on time with zero production bugs" beats "you're a solid performer").
  • It distinguishes between performance and potential. Someone performing well at their current level is not automatically ready for the next level.
  • It results in concrete action items for both the engineer and the manager.

Critical thinking​

Learning time is not free time​

Dedicating sprint time to learning only works if there's accountability. "I spent the afternoon learning" without any evidence (no notes, no experiment, no discussion, no applied knowledge) is not learning time. It's unstructured time that happens to feel productive.

This doesn't mean micromanaging learning. It means having a lightweight expectation: if you spent time learning, you should be able to explain what you learned. A Slack post, a PR that applies a new technique, a conversation with a teammate, or a note in your growth plan. The output can be small, but it should exist.

Career ladders are descriptive, not prescriptive​

A career ladder describes what performance looks like at each level. It does not prescribe a linear path that everyone must follow. Some engineers will stay at the senior level for years, getting deeper and more impactful without seeking a title change. That's a valid and valuable career path, not a plateau.

Avoid the trap of treating the ladder as a promotion conveyor belt where time served equals advancement. Merit means recognising sustained performance, not rewarding patience.

Mentorship requires investment from both sides​

A mentor who shows up to meetings without having looked at the mentee's recent work is not mentoring, they're having a chat. A mentee who never brings questions, never acts on advice, and never follows up is consuming someone's time without learning from it.

Both parties should treat mentorship meetings with the same professionalism they bring to a code review: prepared, engaged, and honest. If the pairing isn't working (the chemistry is off, the domain mismatch is too large, or the schedules never align) change it. A bad mentorship is worse than no mentorship because it poisons future willingness to participate.

Not all learning is equal​

There's a hierarchy of learning effectiveness, and it roughly maps to how active the learner is:

  1. Teaching others: The most effective. You don't truly understand something until you can explain it clearly to someone else.
  2. Building something: Applying knowledge to a real problem forces you to confront the gaps in your understanding.
  3. Discussing with others: Reading groups, tech talks, code review discussions. The social dimension adds accountability and alternative perspectives.
  4. Watching/reading: Useful for initial exposure to a topic, but passive consumption without application decays quickly.

Growth plans should lean toward the top of this hierarchy. An engineer whose learning plan consists entirely of "watch video courses" is not growing as fast as one whose plan includes "build a prototype, present what I learned, and mentor a junior on the same topic."

Onboarding never feels urgent until it's too late​

When the team is under delivery pressure, onboarding gets compressed: "just shadow someone for a week and start picking up tickets." This feels efficient in the short term. In practice, it extends the ramp-up period by months because the new hire fills in gaps through trial and error instead of structured learning.

Protect the onboarding process even when (especially when) the project is busy. A well-onboarded engineer becomes productive faster and with fewer mistakes than one who was thrown in and expected to swim.

Checklist​

For every engineer​

  • A current growth plan exists with specific, observable goals for the quarter
  • Dedicated learning time is visible on the sprint board and actually used
  • At least one tech talk or lightning talk is presented per year
  • An assigned mentor (for first-year engineers) or active mentorship relationship exists
  • Code reviews are being used as learning opportunities, not just approval gates
  • The career ladder level is understood and referenced in growth conversations

For managers and tech leads​

  • DRI assignments are rotating and are being used as growth opportunities
  • Onboarding follows the 30/60/90 day plan structure
  • Performance reviews reference the career ladder with specific examples
  • Learning time is protected in sprint planning, not sacrificed for delivery
  • Cross-project code review or architecture review participation happens regularly
  • Mentorship pairings are tracked and reviewed for effectiveness
  • New engineers make a meaningful PR within their first two weeks

For the organisation​

  • Career ladder is published, understood, and referenced in promotion decisions
  • Tech talks run on a regular cadence with a mix of prepared and lightning formats
  • Conference attendance is budgeted and tied to knowledge-sharing commitments
  • Onboarding materials are maintained and updated after each new hire's feedback
  • Cross-pollination mechanisms are in place (shared channels, cross-project reviews, rotations)
  • The Confluence L&D space is current and actively maintained

AI tips​

  • Draft growth plans. Describe your current role, level, and areas where you feel weakest. Ask AI to suggest specific, time-boxed learning goals and concrete actions to achieve them. AI is good at structuring vague aspirations ("I want to get better at system design") into observable goals ("lead an architecture review by end of Q3, complete the System Design Primer, and present a tech talk on caching strategies"). You supply the self-awareness; AI supplies the structure.
  • Prepare for performance reviews. Before a review, paste your recent PR list, project contributions, and growth plan goals. Ask AI to help you write a self-assessment that maps your work to the career ladder dimensions. AI can help surface accomplishments you've forgotten and frame them in terms the ladder uses.
  • Generate onboarding checklists. Describe your project's stack, tools, and conventions. Ask AI to generate a detailed onboarding checklist tailored to that project. This is especially useful when spinning up a new project where no onboarding materials exist yet. Review for completeness. AI doesn't know about your team's undocumented tribal knowledge.
  • Prepare tech talks. Use AI to help structure a presentation: outline the key points, suggest a logical flow, identify areas where the audience might have questions. AI is particularly good at turning "I want to talk about how we solved the caching problem" into a structured narrative with a clear problem statement, approach, trade-offs, and lessons learned. See AI-Assisted Engineering for broader guidance on working with AI tools.
  • Accelerate learning on new topics. When ramping up on an unfamiliar technology or pattern, use AI as a tutor: ask it to explain concepts, generate small code examples, and quiz you on your understanding. This is faster than reading documentation alone, but verify AI explanations against official docs. AI can be confidently wrong about API details and version-specific behaviour.
  • Create mentorship discussion guides. If you're mentoring and aren't sure what to cover, describe the mentee's level and current challenges. Ask AI to suggest discussion topics, exercises, and review activities that target those gaps. This prevents mentorship meetings from becoming aimless check-ins.

Resources​

S&P internal:

  • Standardised Learning & Development (The Confluence hub for L&D resources, templates, and shared learning materials. This playbook section and the Confluence L&D space are companion resources) the playbook defines the practices, Confluence hosts the living materials.
  • DRI & Areas of Responsibility, The DRI model and how responsibility is assigned at S&P.
  • Core Values (Evolution, Integrity, Merit, Care, Teamwork) the foundation of everything in this section.

Playbook cross-references:

  • Engineering Principles. DRI model, decision-making principles, and the "ownership over territory" principle that grounds growth practices.
  • Code Review, The full code review process, including how review assignments and feedback serve as learning mechanisms.
  • Developer Experience & Setup, The engineering setup checklist referenced in the onboarding 30/60/90 plan.
  • Code Standards. Standards that new engineers learn during onboarding and that code review reinforces.
  • Architecture & System Design. Architecture reviews as a knowledge-sharing and cross-pollination mechanism.
  • Communication & Collaboration. How knowledge sharing, tech talks, and cross-team communication fit into S&P's broader collaboration practices.
  • AI-Assisted Engineering. Using AI tools for learning, preparation, and skill development.

External references: