The only career blueprint worth considering

I’ve been through enough organisational change now that I’ve stopped believing very much in the idea of job security.

I’ve seen companies acquired, divisions separated and sold, teams reorganised or merged, reporting structures changed, products abandoned, and platforms that once seemed strategically important eventually reach end of life. Sometimes there were good reasons for those decisions. Sometimes they were political. Sometimes they made sense only when viewed from somewhere much higher up the organisation. And sometimes they just seemed like bad decisions.

Whatever the reason, the experience for the engineers involved tends to be similar. There is a period where nobody really knows what happens next. What happens to the team? Does the project still exist? Will the work change? Will the people you enjoy working with still be there? Do you even still have a job?

These are reasonable things to worry about, but increasingly I think there is a limit to how useful that worry is. Most of those decisions are outside our control.

What isn’t outside our control is the engineer we are becoming while all of this is happening.

Job security and career resilience are not the same thing

It is worth making one distinction very clear from the beginning: being an excellent engineer does not guarantee you will keep your job.

The large-scale layoffs across the technology industry over the last few years should have destroyed that illusion by now. Companies don’t necessarily make redundancy decisions by carefully ranking every engineer according to their ability and keeping the best ones. They close offices, remove product lines, eliminate whole organisations, consolidate teams, reduce expensive geographies, or simply decide that a spreadsheet needs a smaller number in the headcount column.

The result can be that an exceptional engineer loses their job while somebody considerably less capable elsewhere in the organisation remains completely unaffected. Sometimes companies lose exactly the people they should have been trying hardest to keep.

It would be both wrong and deeply unfair to look at an engineer caught in something like that and conclude that they simply didn’t make themselves valuable enough.

Ability is no guarantee of job security.

But I do think ability, relationships, reputation and adaptability have an enormous effect on something slightly different: career resilience.

You cannot completely control whether your current job disappears. What you can influence is how well equipped you are for whatever happens after it does. That distinction sits underneath almost everything else I believe about career development.

Loyalty is not a career strategy

I’m also increasingly unconvinced by loyalty as a useful concept when thinking about a career.

That doesn’t mean I think we should treat companies or the people we work with transactionally. Some of the best experiences I’ve had in my career came from caring deeply about a team, trusting the people around me, and wanting what we were building to succeed. I’ve also had engineering managers who invested heavily in my development and colleagues I would happily work with again tomorrow.

There is enormous value in those relationships.

But loyalty and dependence are different things.

The problem comes when our career starts depending on the organisation remaining broadly as it is today. Your manager can leave, your team can disappear, your project can be cancelled, your company can be acquired, or the technology you have spent years becoming excellent at can slowly become less important. None of these things require you to have done anything wrong.

A career strategy that depends on them not happening is essentially hope as a strategy.

A better question is:

What am I building in myself that remains useful when they do?

Your project is not your career

I think engineers can become surprisingly tightly coupled to the systems they work on. We become the Kubernetes person, the mobile developer, the security engineer, the Jenkins person, or the person who knows absolutely everything about one particular internal platform.

There is nothing wrong with deep specialisation. It is often how we become genuinely useful. The danger is confusing the current expression of our capability with the capability itself.

I’ve worked on several platforms that eventually disappeared. For a variety of reasons, the thing we had spent years designing, building and operating was no longer required. It would be easy to look at that as wasted effort, but I don’t.

Every one of those systems left something behind.

I learned things about architecture, infrastructure, security, operations, product strategy, organisational dynamics, automation, failure modes, technical judgement, and working with other engineers. Some of those lessons only became obvious years later when I encountered a completely different problem and realised I had seen some version of it before.

The platform was temporary. What I learned building it wasn’t.

There is a software-engineering analogy here that I think is genuinely useful. We spend a lot of effort trying not to tightly couple software components to things that might change underneath them. It isn’t a bad principle for careers either.

Most career changes are evolutions

About ten years ago I started professionally as a software engineering intern. Since then I’ve worked as, or spent meaningful periods doing the work of, a full-stack developer, mobile developer, backend developer, QA engineer, platform developer, infrastructure engineer, DevOps engineer, platform engineer and DevSecOps engineer.

Written down like that, it sounds like I’ve repeatedly changed careers. It never felt that way. Each step mostly built on the previous ones.

Software development made infrastructure automation easier. Infrastructure made distributed systems more concrete. Operations changed how I thought about application design. Platform engineering forced me to think about other engineers as users of systems I was building. Security added another dimension to almost every architectural decision.

The boundaries between those roles are much clearer on a CV than they ever were in reality. That is why I increasingly think capability is a more useful unit of career development than job title.

A role is just somewhere you happen to be exercising a collection of capabilities at a particular point in time.

The more useful question isn’t necessarily:

What job do I want next?

It is:

What do I need to become capable of doing next?

Engineers can accumulate development debt

There is another engineering analogy that I think maps surprisingly well onto careers: technical debt.

A neglected codebase usually doesn’t collapse overnight. For quite a while, everything appears fine. Features continue shipping and customers continue using the product. The consequences appear gradually: changes become harder, understanding the system takes longer, and the number of things people are afraid to touch increases. Eventually the debt begins limiting what can be done.

I think engineers can accumulate something very similar in their own development.

You can spend years being perfectly productive while slowly reading less, exploring less, reflecting less, building fewer things outside your immediate responsibilities, and encountering an increasingly narrow set of problems. There may be no obvious signal that anything is wrong. You still deliver your work, performance reviews may be good, and your team may depend heavily on you.

But underneath that, your adaptability can slowly erode.

Technical competence is only one part of being a strong engineer. There are a lot of other capabilities that need continued investment:

• designing and reasoning about systems
• understanding architecture rather than only implementation
• exploring unfamiliar technologies and domains
• building things and learning through doing
• writing and communicating clearly
• developing technical judgement
• understanding people and organisations
• building relationships with strong engineers
• reflecting on successes and failures
• connecting ideas across different disciplines

The problem is that many of these things are important without being urgent.

Nobody is likely to create a Jira story telling you that your architectural thinking has become too narrow. There probably won’t be a sprint item asking you to spend time with an excellent engineer in another part of the company. Nobody is going to notice immediately that you stopped reading deeply two years ago, and nobody else has a complete view of where the gaps in your own development are starting to form.

Just like technical debt, ignoring them is cheap today and expensive later.

Good managers should be part of this

Owning your development doesn’t mean doing it alone.

Some of the best engineering managers I’ve worked with have actively pushed me towards exactly the things I’m advocating here. They’ve given me difficult problems, encouraged me into unfamiliar areas, created opportunities, challenged assumptions, and helped me see gaps I couldn’t necessarily see myself.

That is what good engineering management looks like to me. A good manager understands that helping an engineer become more capable is generally good for both the engineer and the company. Better engineers solve harder problems, exercise better judgement, require less direction, and can contribute across a wider area.

The distinction is simply one of ownership.

A manager can guide and sponsor you. They can create opportunities and help remove obstacles. A company can provide an extraordinary environment in which to grow, and strong colleagues can accelerate your learning enormously. Take advantage of all of that when you have it.

But none of them can ultimately own your development for you.

Your company quite reasonably thinks about the capabilities it will need from you. You also have to think about the engineer you are trying to become. When those two things align, you have probably found a very good place to work.

Relationships don’t build themselves

The same applies to relationships inside an organisation. It is surprisingly easy to spend years at a large company while knowing very few people outside the immediate orbit of your team.

Being employed by the same organisation does not automatically create useful relationships. You have to deliberately build them.

Some of the most useful people I’ve learned from haven’t necessarily been people I reported to or even worked with directly. They were engineers in neighbouring teams, architects who had seen different generations of systems come and go, security engineers who understood failure modes I hadn’t encountered yet, or simply people whose judgement I respected.

Those relationships widen the system you operate inside. They expose you to different problems and different ways of thinking, make it easier to collaborate across organisational boundaries, and allow knowledge to move in both directions rather than remaining trapped inside individual teams.

They also often outlive the organisational structure that introduced you in the first place. Teams get reorganised; good relationships don’t have to.

I don’t think of this as networking in the slightly grim sense of collecting contacts because somebody might be useful later. It is closer to building the human infrastructure around your career.

Good work is not automatically visible

There is a similar assumption engineers sometimes make about reputation: do good work and people will notice.

Sometimes they do, and often the people immediately around you will. But organisations are information systems too, and information does not propagate through them particularly reliably.

A team can quietly remove enormous amounts of toil and nobody outside its users really understands what changed. An engineer can resolve an architectural problem that prevented months of future pain. Someone can prevent an incident that, by definition, never happens. A lot of very valuable engineering work is structurally difficult to see.

That doesn’t mean the answer is constant self-promotion. But I do think engineers have some responsibility for making their work legible.

That might mean writing a good design document, explaining the impact rather than only the implementation, sharing lessons from an incident, presenting something useful to other teams, documenting a reusable approach, or simply making sure your manager actually understands the problems you solved and why they mattered.

The engineer often has much more context than anyone else about the significance of the work. If we don’t communicate that context, we can’t assume the organisation will somehow reconstruct it for itself.

Communicating impact is part of the work.

Some evidence should exist outside your company too

The same problem becomes much more obvious when you leave an organisation. Most of the context that made your internal reputation possible disappears.

The people interviewing you didn’t see the system you designed. They weren’t there during the incident you handled. They don’t know the quality of the technical decisions you made or how much influence you had on the engineers around you.

This doesn’t mean every engineer needs to become a social media influencer or spend their evenings manufacturing a personal brand. I have very little interest in that.

But I do think there is value in creating some durable external evidence of what you know and how you think. That might be:

• writing
• open-source or personal projects
• technical talks
• maintaining relationships outside your company
• contributing to engineering communities
• keeping your professional profile representative of what you actually do

None of those need to become a second career. They simply make some of your capability visible outside the company that currently employs you.

Internal reputation is valuable. External evidence creates optionality.

You want both.

The best time to prepare for change is before anything changes

One reason organisational change bothers me less than it once did is that I’ve seen enough of the second-order effects.

I’ve had platforms disappear and ended up working on more interesting problems. I’ve gone through organisational changes that introduced me to excellent people I would never otherwise have worked with. Changes in technology pushed me towards areas that later became significantly more useful.

That does not mean every change contains some hidden positive outcome if we just look hard enough. Sometimes change is simply bad. Companies dismantle excellent teams, strong engineers leave, a reorganisation can make the work worse, and a mass layoff can remove people who did absolutely nothing to deserve being removed.

But change does create new conditions, and new conditions create different opportunities.

The catch is that most of your ability to take advantage of them was built before the change happened. You cannot build ten years of engineering experience during a redundancy consultation, suddenly manufacture trusted professional relationships when you urgently need them, instantly develop architectural judgement when a senior opportunity appears, or retrospectively create years of evidence showing what you know.

All of those things compound slowly.

Which means the best time to build career optionality is usually when you don’t currently need it.

Technology changes the ground underneath us too

Organisational change isn’t the only thing capable of changing the ground underneath us. Technology does the same thing.

Software engineering has always evolved by automating and abstracting away parts of the work that came before. Compilers removed work programmers once performed manually. CI/CD changed how we integrated and released software. Infrastructure as code changed how we managed infrastructure. Cloud platforms and managed services removed entire categories of operational work.

None of those changes made engineering stop mattering. They changed where the valuable engineering work was.

The capabilities that mattered moved upwards.

AI looks like another significant step in that process. Exactly where it leads is much harder to predict, and I don’t think building a career strategy around confidently forecasting that future is particularly useful either.

What seems much more durable is recognising the pattern.

When technology makes one part of engineering cheaper or easier, the bottleneck moves somewhere else. Implementation may become faster, while understanding the right problem, choosing between alternatives, integrating systems, managing complexity, exercising judgement, communicating trade-offs, or understanding the wider organisational context becomes relatively more important.

The useful response isn’t to become emotionally attached to whichever tasks currently make us valuable.

It is to keep following the value.

If tools allow us to spend less time on repetitive implementation, use that leverage to understand larger systems, explore alternatives faster, solve harder problems, make better decisions, and produce more useful outcomes.

That applies to AI today, but the broader pattern is much older: as technology changes, the valuable work shifts with it. Our job is to recognise where that value is moving and keep developing accordingly.

Projects change. Organisations change. Technologies change. The particular work we are paid to do changes with them.

Our career resilience comes from continually developing the capabilities that remain useful as those changes happen.

Our value as engineers was never fundamentally our ability to perform one particular task faster than somebody else. It is our ability to understand problems well enough to make useful things happen.

The blueprint

So when I think about a career blueprint now, it isn’t a sequence of titles or a ten-year plan. It is much simpler:

• Build capability continuously. Keep expanding the range and difficulty of problems you can solve.
• Own your development. Use good managers, colleagues and companies to accelerate it, but don’t outsource responsibility for it.
• Build relationships deliberately. The people around you are part of the system you learn and operate within.
• Make your work legible. Don’t assume valuable work automatically becomes visible outside your immediate team.
• Keep your capability portable. Learn from the technologies and platforms you work on without becoming completely dependent on them.
• Create some external evidence. Make it possible for people outside your company to understand at least some of what you can do.
• Pay attention to development debt. Important things become expensive when ignored for too long.
• Build optionality before you need it. Skills, relationships, reputation and bodies of work all take time to compound.

None of this makes you layoff-proof. Nothing does.

You can do everything right and still find yourself on the wrong side of an acquisition, restructuring, product cancellation or arbitrary headcount target. That isn’t the point. The goal isn’t to somehow guarantee that your current job survives every possible organisational decision; it is to reduce how much power any single one of those decisions has over the rest of your career.

You can’t control whether companies change, whether a particular project survives, or every decision made several layers above you.

But you can keep building your capability, build relationships, make what you know visible, and keep exploring, learning and adapting.

You can make sure that when the environment changes, you are capable of changing with it.

That is about as close to career security as I think we get.