The Principal Engineer's Path: Skills, Strategies, and Lessons Learned

Sophie Weston opens with a question most engineers have asked silently: you look at someone in a senior role and wonder how they got there, and more usefully, how you could. Her answer is that the career-ladder metaphor is wrong. Careers are not ordered sequences of steps; they are long, winding, and full of turns nobody planned. Her central thesis has two halves that she insists are inseparable. Reaching principal engineer takes far more than deep technical expertise — it takes influence, communication, and strategy — but it also takes an organization willing to bend around the shape of your life. She is explicit that without the second half, she would not have had the first.

Weston is a principal engineer at ClearBank, a company founded in 2015 with offices in London and Amsterdam, roughly 700 people in total and about 270 across product and engineering. She describes it as very much a tech company that is also a fully licensed and regulated bank. August marks 30 years since she started her first job after graduating, most of that time as a software engineer, with the bulk of her hands-on work being Java on some flavour of Unix. About seven years before the talk she stepped away from the IDE into coaching and consultancy roles, working with delivery teams and the wider engineering organization on how they deliver software and on engineering culture. Outside her job she has been an ambassador for Women in Tech York since it started in 2018, and co-organizes DevOpsDays London and Fast Flow Conf. She notes she was a track host at QCon London the year before this talk, curating a track on how teams really work, and co-hosted one of the two tracks at Platform Engineering Day at KubeCon. The InfoQ bio adds a detail the talk itself does not: before ClearBank she worked with Matthew Skelton, co-author of Team Topologies, helping organizations adopt Team Topologies and fast flow ways of working — relevant context given that Team Topologies is the first entry on her reading list.

The InfoQ page files this recording under QCon London 2025, carries the date April 1, 2026, and runs 47:57. These notes report what Weston presented. She is equally explicit that this is a personal talk built from reflection on her own career rather than from research, so treat the conclusions as her considered opinion drawn from one long career, not as measured findings. Where I add background an intermediate engineer needs but the talk did not state, the text says so. Audience questions are folded into the relevant sections below rather than reproduced as a separate block.

What You Will Learn

• What engineering leadership consists of in Weston's definition, and how a principal engineer's focus differs from a team's.
• Why she frames the principal engineer role as reducing friction rather than setting direction from above, and what that looks like day to day.
• Which organizational policies she credits with making her career possible, and why a policy that managers quietly discourage is worth nothing.
• The case for internal promotion, the specific ways it goes wrong, and when hiring externally is the better call.
• What the "engineer/manager pendulum" is, why she moved back to an IC role after becoming a team lead, and where she draws the line on hybrid roles.
• The progression from T-shaped to pi-shaped to "broken comb" skill profiles, and why breadth beats depth for leadership work.
• Her recommended reading list across twelve topic areas, with what each one is for.
• How skills learned outside work transfer into leadership, using her own example of parenting.
• Why community involvement, event organizing, and public speaking form a compounding feedback loop rather than three separate activities.
• The problems she has not solved, including how to evidence senior IC work at promotion time.

What Engineering Leadership Actually Means

Weston's first move is to separate leadership from titles. Leadership is not a role you are promoted into; it is how you behave, how you influence, how you guide people, and whether you create an environment where people can thrive. If you are thinking about your own growth, she argues, leadership is not something to defer until later.

In her definition it comes down to three things. Setting technical direction means guiding teams and helping them make good architectural and technical choices. Driving good engineering practices means helping teams build software efficiently that delivers real value to the business and its customers. Shaping culture means mentoring, coaching, and making the organization a good place to work. She adds that principal engineers focus less on what teams build and more on how they build it: spotting patterns, connecting dots across the organization, and guiding teams towards better decisions without dictating from above. Her formal phrasing is "socio-technical cross-cutting concerns"; her plain one is helping teams do great work.

The analogy she uses is curling. The sweepers do not throw the stone and do not decide its direction. They sweep the ice ahead of it, reducing friction so it travels further and more accurately, making small adjustments along the way. That, she says, is the principal engineer's job: reduce friction so the team and the wider organization move faster, avoid unnecessary obstacles, and stay on track.

Culture is the part she is personally most passionate about. A good engineering culture in her sense is good on two axes at once — the organization can deliver value effectively and efficiently, and the people working in it are not being ground down. Her formulation is that you want impressive DORA metrics, but not at the expense of burning people out.

When an audience member asked how you persuade people when you have said all these things and nobody follows the direction, her answer was unglamorous and consistent with the sweeper framing: you talk to people. A lot of being a principal engineer is talking to people, both in meetings at group level and in one-to-one influencing with stakeholders to get them on board. She offered no technique beyond persistence and conversation.

A follow-up from the same questioner asked how you measure accomplishments for a promotion case when the work is not code or shipped products. Weston's answer was that this is tricky, that she dislikes the "brag list" idea, and, reaching back to the sweeper analogy, that you are quite visible in some ways. She said plainly that it is not one she has solved particularly well, because she does not like saying "look at me, I've done all these things." Readers looking for a method will not find one here, and the honesty is more useful than a manufactured answer would be.

What Organizations Owe People

Weston deliberately starts the practical half of the talk with organizations rather than individuals, because the practices she describes are foundational rather than specific to leadership roles: they are what enables anyone to pursue the career they choose. Her framing question is how many talented people have walked away from careers they loved simply because the job would not bend even slightly to fit their lives.

Flexible Working

This is the policy she credits most directly for her own career. Because she had a young family and wanted both the family and the career, she worked part-time for many years — in fact for the same company for 20 years. Her statement is unambiguous: without part-time work when her kids were young, she would not be in tech today, and would have had to walk away.

Flexibility takes several shapes, and her point is that the shape matters less than the willingness. Some people work three or four days a week. Some compress hours, fitting five days of work into four longer ones. Weston did something different again: she spread four days' work across five, finishing at 3pm every day so she could collect her children from school. For others, flexibility means remote work, or simply knowing that when something goes wrong at home, work will understand. She is emphatic that this should not be framed as a parenting benefit — people caring for elderly relatives, people who want time to study, and people who just want a different work-life balance all still have a lot to contribute. The organizational argument is that flexibility widens the talent pool to include all of those people alongside those able and willing to work a conventional nine-to-five.

The caveat she raises is the one that decides whether any of this is real. A flexible working policy at the organizational level is worthless if managers block people from using it, and if people fear career consequences for working flexibly, the policy is just words on paper. Real flexibility needs support from the top down and the bottom up. Her summary line is that flexible working is not a perk but a necessity of modern life, and the companies that understand this are the ones that keep their best talent.

Internal Promotion

Weston's second organizational lever is promoting from within, which she describes as one of the biggest career boosts available and one that does not require switching companies. For the person promoted, assuming they get the support they need to transition, it produces a sense of being valued and fosters loyalty; her position is that you should not have to move companies in order to progress. For the company, it keeps organizational knowledge in-house, strengthens morale because people like seeing colleagues recognized, and proves that career growth is a reality rather than a recruiting promise.

Her own 20 years at one company produced multiple promotions: developer, senior developer, team lead, technical architect, and finally a sideways move into a role she describes with amusement as "DevOps advocate". She also points to engineers she has worked with who started on first-line support at the service desk and were later given the opportunity to train as platform or security engineers, which she describes as wonderful to watch.

She does not present internal promotion as free of problems. It involves navigating friendships during selection, avoiding perceptions of favouritism, and the genuine difficulty of stepping up from colleague to leader, which without support can feel more like a battlefield than a stepping stone. An audience question pushed specifically on that colleague-to-leader transition, and her answer names the mechanism: you go from being one of the crowd to being outside it, sometimes having to tell people what to do or say no. Her recommendation is that organizations recognize this and give the person moving into the role a mentor — someone in the same boat who can answer questions and act as a point of contact. She draws the parallel with onboarding buddies for new joiners: somewhere to ask the question that feels stupid, rather than expecting people to make the jump and succeed instantly.

She is also clear that hiring externally is sometimes the right call, when you need a different skill set, experience of a particular technology or industry, or deliberately want someone without organizational history who can bring fresh perspective and new ways of thinking.

The combination of the two policies is what she singles out as the real enabler. Working part-time was not treated as an issue day to day and was not treated as a limiter on promotion. Her conclusion is that no one should have to choose between family and career, and a genuinely supportive workplace ensures you can have both.

Squiggly Careers and the Engineer/Manager Pendulum

A squiggly career, in her use of the term, is a dynamic evolving journey where people take on diverse roles and sometimes switch industry, as opposed to a predictable straight climb up a corporate ladder. Her stronger claim is that every career is squiggly to some degree and there is no such thing as a normal career path. As an industry she thinks we should support people who want to change roles over time — software development into security or quality engineering, or into product ownership — and she notes these are not random examples but changes she has watched people make successfully. The organizational benefit is retention, engagement, and fresh perspectives.

The biggest squiggle she identifies is the IC-versus-management crossroads, which she says is too often framed as a one-way street rather than a flexible choice. For some people the move into management works out; for others it produces frustration after a few years as their technical skills atrophy. She reports this first-hand: she was thrilled to become a team lead and lead a small team, then found herself coding less and less and becoming increasingly frustrated and disconnected from tech, so when an opportunity came up to return to an IC role she took it.

Her argument for making that reversibility normal has three parts. Organizations sometimes hesitate because they fear a move back signals failure or disrupts teams; she counters that flexible paths ensure managers are managers because they want to be rather than because they felt pressured into it, that it produces managers with strong up-to-date technical skills, and that people returning to IC roles bring leadership experience that makes them stronger technical contributors. She credits Charity Majors, founder and CTO of Honeycomb, with writing extensively on this under the name the engineer/manager pendulum, and directs the audience to those articles.

Her limit on this idea came out in the Q&A. Asked whether organizations should offer hybrid roles where you spend part of your time managing and part as an IC, and whether individuals should seek them, she was cautious. It depends somewhat on the size of the organization — in a very small company with small teams it might work — but she considers them genuinely different skill sets and says she is not advocating for people moving backwards and forwards. Her preference is to focus on one or the other: an engineering manager should be focused on people and helping them develop their careers, and an IC should be focused on the tech and doing good work for the team. This is a useful nuance, because it distinguishes being able to switch tracks over the span of a career from doing both jobs at once, and she endorses only the first.

She also asked engineering leaders in the audience to reflect on whether their organization enables career flexibility, promotes from within, and supports role changes — both as something to use for themselves and as something to make happen for others, since moving into senior roles means shaping the career paths of the people coming after you.

Driving Your Own Development

Policies and frameworks can support you, but they will not define your path. The second half of the talk is what you do with the space an organization gives you.

From T-Shaped to Broken Comb

The skill-profile progression Weston walks through is a useful piece of shared vocabulary. T-shaped means deep expertise in one area — the vertical stroke — plus broad understanding across other areas, the horizontal stroke. That evolved into pi-shaped, meaning deep expertise in more than one domain (the legs of the mathematical symbol π, she clarifies, not the edible kind) with the same broad understanding on top. Leadership, she argues, demands more breadth still, which brings you to the broken comb: varying depths of knowledge across many areas rather than deep expertise in one or two, where the unevenness is the point — the varying depths are what let you bridge gaps, connect ideas, and solve problems creatively, and some areas being deeper than others is what produces the broken-comb shape.

What makes this effective for a leader, in her phrasing, is the ability to integrate and apply that knowledge across different contexts. Her honest framing is that you cannot predict which scenario will make a given piece of knowledge useful, but you have it there ready anyway, and the breadth gives you more options and more ways of approaching a problem. This is worth pausing on as a career-planning claim, because it inverts the usual advice to specialize: she is asking you to invest in knowledge whose payoff is unknowable in advance, justified by optionality rather than by a specific return.

Writer's note, not from the talk: the T-shaped and pi-shaped terms predate her usage and are widely used in hiring and consulting contexts; Weston introduces them as assumed background and builds the broken comb on top rather than claiming any of the three as her own coinage.

The Reading List

Weston is explicit that there is no universal syllabus for engineering leadership and no checklist to follow, only common skills and knowledge that most successful engineering leaders in her experience develop. She calls it a reading list because books are her favourite way to learn, and notes that if books are not your thing, conference talks on YouTube work just as well. Her closing advice on the list is the important part: these are starting points, so pick the one thing that inspires and excites you, and you will naturally find one topic leads to another.

Two of her comments about the list carry more weight than the citations. On psychological safety, she says not enough leaders really understand what it is or how important it is. On systems thinking, her claim is that once you start getting into it, it changes how you see everything permanently and you will never look at your organization the same way again.

An audience question about how she stays on top of new technologies after so long in the industry drew a partly organizational answer. She acknowledges it is easier for her now because she is not hands-on and does not need the same depth. What she objects to is the industry expectation that learning happens in your own time, and the "what are your side projects?" framing. Her position is that staying current is part of the job — you cannot do the job without it — so organizations need to give people the time to train and learn rather than leaving it to home life.

Bring Your Whole Self to Work

Work is not the only place to develop leadership skills, and Weston's argument is that skills acquired elsewhere are not merely acceptable substitutes but carry extra value. A sports team builds teamwork and resilience. Volunteering with a youth group builds coaching and problem solving. Gaming builds strategic thinking and adaptability. Organizing community events builds a long list she returns to later.

Her personal example is parenting, which she says prepared her for leadership better than anything else: negotiation, time management, multitasking, stakeholder management, well-laid plans that explode when you least want them to, constant practice at being adaptive and resilient, and influencing rather than controlling. The anecdote she tells is that when interviewing for promotion from senior developer to team lead, the head of development asked whether she had good organizational skills, and she laughed and said she had three children under seven and was sitting there — what did he think. She got the job.

The reason she thinks these skills are arguably more valuable than ones learned on the job is twofold: they represent more teeth on your broken comb, and the perspective of having acquired them in a different setting is itself worth something. She connects this back to psychological safety and the idea of bringing your whole self to work, extending it from day-to-day team behaviour to how you account for your own capabilities across a career.

Make Connections

Weston's claim here is that one of the fastest ways to grow is not what you learn but who you meet, because community exposure produces new ideas, opportunities, and people who challenge you. She lays out an escalating set of entry points.

Social media is the low-effort start: follow interesting people, engage in discussions, share insights, and even small interactions such as commenting on a post or resharing an article build connections. Blogging is another option, though she is candid that it is not for her — she finds writing very difficult and is slow at it, having published only a few articles about psychological safety for a previous employer's blog. That candour is worth noting, since it undercuts any implication that you need to do all of these.

Meetups are what she considers the best route in. Her own city of York, which she describes as not very big, has meetups on .NET, frontend development, testing, software development, tech startups, and Women in Tech; and virtual meetups and online communities can be just as valuable wherever you are. The reasons to go are learning — there are always good talks, and even on a familiar subject you get someone else's perspective — and meeting people, where the format guarantees at least some overlap in interests. She singles out networking as a genuinely important career tool, giving access to career advice, job and other opportunities, and emotional support. On Women in Tech York specifically, she names something more personal: it is one of the few places where she is not one of only two women in the room, or the only one, which she says still happens all too frequently, and being among people with that same shared experience is a very positive thing.

Volunteering or organizing goes further. It is hard work and time-consuming, but she calls becoming a co-organizer of DevOpsDays London and Fast Flow Conf one of the best things she has done in her career, personally and professionally. Some of the best teams she has worked with are ones she joined as a volunteer, working with people she would not normally collaborate with and learning skills she would not get the chance to learn at work. Her specific observation about why event teams work well is sharp: putting on an event is a very clear mission with a focused goal and none of the shifting priorities you get at work. Professionally, it raises your visibility and supercharges your network, because you are working alongside other organizers and speakers who are often at the top of their profession.

An audience question about mentoring models fits here. What she has seen work best is straightforward one-to-one mentoring, where you find someone with the skills and experience you want to learn from and with whom you can have a good relationship. Organizationally, the version she has seen work is simply asking who wants to be a mentor and who wants to be a mentee and pairing them up. Her useful qualifier is that it does not have to be a long-term relationship: short-term mentoring aimed at one specific skill is fine, as long as both parties go in knowing that is what they are doing.

Public Speaking

Weston is direct in disagreeing with the belief that public speaking requires ability or confidence you either have or lack. Her evidence is her own first attempt, which she says did not properly count as public speaking at all — she was only introducing some lightning talks she had organized at work — and yet she was so nervous that her heart was pounding and she had a whooshing sound in her ears. She adds that she knows very few people, including regular conference speakers, who do not get nervous, and makes the separate and more interesting point that being comfortable grabbing a microphone does not make someone a skilled speaker. Public speaking is a learned skill, and one anyone can learn.

The benefits she lists are credibility and the chance to demonstrate your knowledge; the growth that comes from sharing knowledge, where you become the one creating learning opportunities for others; stronger communication skills, since learning to articulate and present ideas clearly makes you more persuasive in meetings, presentations, and leadership roles; and confidence.

Her recommended starting point is internal talks within your own organization, and if your company does not already run weekly tech talks, being the person who introduces them. Her argument is that they give people a safe, friendly, supportive environment to practise in, and are separately one of the best ways to create a learning culture by sharing knowledge, breaking down silos, and building connections across the engineering organization. She has been championing and organizing internal tech talks wherever she has worked for nearly ten years.

Bringing It All Together: The Compounding Loop

Weston's key claim is that broadening skills, community engagement, and public speaking do not simply add up — they have a multiplier effect and create positive feedback loops. Her stated sequence is that learning new things leads to meetups, meetups lead to speaking, speaking leads to organizing, and before you know it you are at the centre of the communities that once inspired you, contributing to and helping shape them.

The diagram below is my own rendering of that verbal description, not a slide from the presentation.

flowchart TD
    A["Desire to learn"] --> B["Engage with experts
on social media"]
    B --> C["Attend local and
virtual meetups"]
    C --> D["Meet people;
new ideas and perspectives"]
    D --> A
    C --> E["Volunteer / co-organize
events"]
    C --> F["Speak: internal tech talks,
then lightning talks"]
    F --> E
    E --> G["Raised visibility:
knowledgeable, eager to learn,
eager to share, committed, dependable"]
    F --> G
    G --> H["Unplanned opportunities"]
    H -.serendipity.-> A

Her own path is the worked example. A desire to learn led her to engage with subject matter experts on social media and find local meetups; that produced new people and new perspectives, which added more items to her list of things to learn about; after that she volunteered to help run events and took her first tentative steps into public speaking. The concrete instance she gives is that her first proper public talk was a lightning introduction to DevOps at a Women in Tech York event, and one of the co-organizers of DevOpsDays London happened to be there that night to donate free conference tickets to the community. She never spoke to him, but he heard her speak, and that was the first step towards eventually being asked to join the organizing team.

The caveat she attaches to this is the most important part of the section, and it cuts against reading the loop as a career tactic. The sequence runs from social media and local meetups through volunteering to a QCon stage, includes an element she calls luck, and comes with an explicit warning not to pursue it transactionally. Intrinsic motivation and a growth mindset are key: you do these things because you love them and find them rewarding, because they challenge you and make you grow. Through that growth some doors may open that otherwise would not have, but her instruction is explicit — do not do these things because you expect doors to open as a result. Her phrasing is that when you focus on what you love, opportunities often come your way, and she reaches for the Field of Dreams line: build it and they will come. She also acknowledges directly that some of it is still down to luck, or serendipity, while arguing that to a certain extent you create your own possibilities.

She closes this section by turning the questions back on leaders in the audience: does your organization encourage people to attend and speak at meetups and conferences, and give them the time and budget to do it; do you encourage and support others to do it; if your office space is suitable, do you make it available to host meetups in the evening; and do you have weekly tech talks.

Trade-offs And Limitations

• The evidence is one career, reflected on with hindsight. Weston frames the entire talk as personal insights from looking back on 30 years, and signals this before she starts. There are no measurements, comparisons, or outcomes for anyone other than herself and a handful of colleagues she names in passing. The claim that flexible working and internal promotion were decisive for her is credible self-report; it is not evidence about how often those policies produce that result.
• Friction reduction is hard to attribute. This is the structural reason behind the promotion-evidence problem she says she has not solved well, and it is worth naming even though Weston does not connect the two explicitly. Work whose success looks like problems that never happened and decisions that turned out well produces no artefact, which is precisely why evidencing senior IC work is difficult rather than merely uncomfortable.
• Several of her strongest points are contingencies she cannot control. Flexible working depends on manager behaviour rather than on the policy document; staying technically current depends on employers funding learning time; internal promotion depends on someone providing the transition mentor. In each case her answer is an ask of organizations, not a mechanism that enforces itself.
• Time and energy are the unpriced input. Not addressed in the talk: organizing conferences, attending meetups, speaking, and reading across a dozen topic areas all consume discretionary time, which is exactly the resource least available to the people the flexible-working section is about. Weston makes both arguments without reconciling the tension between them.

Practical Takeaways

• Audit your own broken comb. List the areas where you have some depth and the areas where you have none, and pick the gap that interests you most rather than the one that looks most strategically valuable — her guidance is to follow what excites you and let one topic lead to another.
• Start the reading list with systems thinking or psychological safety if you want the two she rates most highly for changing how you see your organization and your team.
• Count non-work skills as career assets. Coaching from volunteering, strategy from gaming, resilience from team sport, stakeholder management from parenting — bring them into how you describe yourself rather than leaving them at the door.
• Begin public speaking internally. Propose weekly tech talks if your organization does not have them; it doubles as a learning-culture intervention and gives you and everyone else a safe place to practise.
• Attend a meetup for the people, not only the talks. The overlap in interests is guaranteed by the format, which is what makes the networking work.
• Ask for a short, specific mentoring relationship rather than assuming mentoring must be a long-term commitment, as long as both sides agree that is the scope.
• If you manage people, check the gap between policy and practice. Ask whether anyone on your team has actually used the flexible working policy, and whether people believe using it would cost them a promotion.
• Give a new internal promotee a mentor who has made the same colleague-to-leader jump, on the onboarding-buddy model, rather than assuming they will succeed instantly.
• Open a return route off the management track. Name at least one senior IC position a current manager could move into, and say so out loud in their next career conversation, so the move is a known option rather than an admission.
• Put learning hours in the sprint, not the evening. Book a recurring, protected block for training and reading and defend it when delivery pressure arrives.
• Answer her two-hat challenge. For yourself: what steps can you take to grow and shape your journey? As a leader: what concrete steps can you take to create opportunities for people earlier in their careers?

Key Terms

Definitions marked "background" are mine as the writer, not Weston's: the talk names these terms but assumes the audience already knows them.

• Principal engineer — In many organizations the highest level of the individual contributor track; in Weston's description, a role focused on how teams build rather than what they build.
• Broken comb — A skill profile with varying depths of knowledge across many areas rather than deep expertise in one or two, producing an uneven comb-like shape; Weston's proposed profile for engineering leadership.
• T-shaped / pi-shaped — Earlier skill-profile models: deep expertise in one area, or in more than one, combined with broad understanding across others.
• Engineer/manager pendulum — Charity Majors' term for moving between individual contributor and management roles over a career rather than treating the first move into management as permanent.
• Squiggly career — A non-linear career of diverse roles and sometimes industry changes; Weston's stronger claim is that every career is squiggly to some degree.
• Socio-technical cross-cutting concerns — Her formal description of principal engineer work: problems that span both the technical systems and the human organization and belong to no single team.
• Psychological safety (background) — A team environment where people can admit mistakes, ask questions, and be themselves without fear; Weston argues most leaders underrate it but does not define it in the talk.
• DORA metrics (background) — The delivery performance measures popularized by the State of DevOps Reports and Accelerate; she treats good scores as desirable only when not achieved by burning people out.
• Theory of constraints (background) — Goldratt's management theory that a system's throughput is governed by its bottleneck, introduced in The Goal and retold for DevOps in The Phoenix Project.
• Fast flow — The approach and methodology described in Team Topologies by Matthew Skelton and Manuel Pais, and the subject of Fast Flow Conf, which Weston co-organizes.

Closing Assessment

The most reusable part of this talk is the pairing rather than either half alone. Career-advice talks usually put the burden entirely on the individual; organizational talks usually treat careers as a policy output. Weston insists both are required and gives a concrete account of why: the skills, community engagement, and speaking she recommends only compound if there is a job flexible enough to keep you in the industry while they do. Her own summary is that the support organizations provide through policy and culture is foundational — it builds the path you are able to travel along — while how far you travel and how fulfilling the journey is comes down to you.

The weakest part is measurement, and the consequence is concrete: an engineer in an organization that has not already decided the senior IC track is real will finish this talk persuaded of the destination and still unable to make the case for it at promotion time.

The idea she explicitly designates as the one to take away is not about the title at all: "If there's one key idea I'd love for you to take away from this talk, it's that the journey matters just as much as the destination." Her designated takeaway is that careers are not ladders with neat ordered steps but winding squiggly journeys full of unexpected turns, and that the route to engineering leadership is a journey of learning, adapting, and growing rather than a fixed path. The instruction she leaves with senior people in the room is to pay it forward — advocating for and supporting those coming along the path behind you, even while you are looking ahead and planning the next steps of your own.

Reference: Sophie Weston, The Principal Engineer's Path: Skills, Strategies, and Lessons Learned, QCon London, published by InfoQ.