Are you climbing the corporate ladder or the value ladder?

Have you ever looked at the next rung of the corporate ladder and wondered whether that’s actually a job you’d want to do?

When I left university, I had a fairly conventional ambition. I wanted to become the CTO (or something similar) of a large telecommunications company.

At the time, it seemed like a logical destination for an aspiring Engineer / Technologist. Start with the technical details, gradually take on bigger responsibilities and eventually earn a seat at the executive table.

But once inside the telco industry, it didn’t take me long to realise that I wasn’t interested in climbing that Corporate Ladder. However, I did soon realise that there was another ladder I was more interested in climbing.

In fact, I’ve spent much of my career deliberately avoiding the corporate hierarchy, whilst still looking for opportunities to solve increasingly large and important tech / people / process problems.

And it turns out that those two objectives aren’t mutually exclusive.

I’ve come to think of this alternative pathway as the Value Ladder.

It’s a concept that’s been rattling around in my head for years, largely formed from observing the different types of problems that Engineers, Architects, Executives, Consultants and Entrepreneurs spend their time solving.

The interesting thing is that the further up the ladder we go, the less it’s about knowing all the technical answers. It’s increasingly about understanding the bigger problem, knowing which dots need connecting and bringing together the ideas, technologies, people, projects, etc that can help solve it.

But before getting into the model, let me share a couple of career experiences that helped shape this thinking.

.

1. Sometimes missing out is the best thing that can happen

Straight out of university, I was applying for graduate placement positions with some of the big Tier-1 carriers and equipment vendors here in Australia.

I was pretty disappointed to miss out on a number of them (side-note: I think I placed around 50 applications before picking up my first role).

These potential employers were the organisations with the impressive graduate programmes, sophisticated engineering departments and well-established career pathways. Surely the best place to start a career in telecommunications?

As luck would have it, my first position was with a smaller, unknown brand company that still happened to be working on some fairly substantial projects.

Within six months of graduating, I found myself put in charge of approximately $100m worth of work within a $200m project, with up to about 40 people involved.

That’s quite a responsibility for someone who still had a lot (ie everything!) to learn!

I wasn’t suddenly an expert in managing large programmes or designing complex enterprise architectures. Far from it. But I was being forced to think about problems involving many different technical disciplines, people, delivery teams, dependencies, budgets and stakeholders.

It was the sort of exposure I almost definitely would not have received so early if I’d been accepted into one of those more prestigious graduate programmes. Not getting those roles turned out to be a blessing in disguise.

Those programmes might have made me a much better specialist Engineer in the early years. Instead, I was being stretched to think about much bigger problems.

In hindsight, I’d accidentally skipped several rungs of what I now call the Value Ladder (the green steps on the diagram below).

I wanted to find a way of disconnecting the blue pyramid from the green ladder and giving greater autonomy over how I could ascend it.

The loose connection between the blue pyramid and the green ladder is a reminder that career progression isn’t always about getting into the biggest or most prestigious organisation. Sometimes it’s the smaller organisation, with fewer layers of hierarchy, that gives you access to the biggest opportunities.

Or perhaps more accurately, gives you the opportunity to take on responsibilities that would otherwise be reserved for people much further up the corporate pyramid.

.

2. The nine rungs of the Value Ladder

Most of us are familiar with the traditional technical career progression on the ladder from Engineer to Architect to Solution Architect to Enterprise Architect.

But what if we extended that progression much further?

What if we weren’t measuring technical seniority or job titles, but the size and breadth of the problems we were capable of helping solve?

Here’s my suggested reasoning behind the nine-rung green Value Ladder.

The names aren’t particularly important, and I’m sure there are other ways of describing the upper rungs. I also don’t see them as rigid boundaries or a precise ranking of the value of different professions.

What matters is the progression in the scope of the problem. For example,

1. An Engineer might be focused on resolving a performance issue on a specific network element.
2. A Systems Architect might be looking at the performance of an entire network domain.
3. A Solution Architect might be trying to connect multiple network domains with assurance, inventory and orchestration systems to deliver an end-to-end service.
4. An Enterprise Architect might be considering how the entire network and OSS/BSS stack can support a new business strategy.
5. An Enterprises Architect (yes, plural!) might be trying to work out how two operators can merge their networks, customers, operational processes and technology stacks after an acquisition.
6. An Industry Architect might be considering why hundreds of telecommunications operators keep solving essentially the same problems independently, with enormous duplication of effort.
7. And an Institutional Architect might be working with standards bodies, industry associations or regulators to change the rules and frameworks within which all those organisations operate.
8. The higher rungs potentially expand the scope even further, looking for connections and solutions across industries and society.

Notice that the problems are becoming broader, with more interdependencies, competing objectives and constraints. They’re arguably harder even if not more technically difficult.

Of course, a brilliant Engineer who solves an incredibly difficult technical problem might create far more value than someone working on a poorly conceived industry initiative.

So let’s be careful not to confuse the breadth of a problem with the value of the solution.

However, the potential for creating value can expand enormously as the scope of the problem expands… As you rise up the value ladder.

.

3. The corporate pyramid and the Value Ladder are two different things

Here’s where I think the concept gets particularly interesting.

There’s clearly some correlation between the two models.

As people progress through an organisation’s hierarchy, they’re generally given responsibility for larger teams, budgets, systems, business units and strategic outcomes.

A CEO is likely to be dealing with a much broader set of considerations than an individual Engineer.

But here’s the important distinction.

You don’t necessarily have to climb the corporate pyramid to climb the Value Ladder (or vice versa even!)

Quite early in my career, I started noticing that the skills needed to succeed in the upper levels of a large corporate hierarchy were becoming increasingly different from those I wanted to optimise.

Executive politics, internal governance, navigating competing empires, organisational positioning and managing upwards all seemed to consume more and more time.

I could 100% see why these skills were important. They’re necessary to get things done in large organisations.

But I didn’t really want to spend much of my working life developing them. Not my greatest areas of strength to begin with!!

I wanted to keep working on fascinating technical and business problems. Preferably bigger and bigger ones. And I do want to emphasise the “business problems” part of that previous sentence. Many Engineers fall into the trap of wanting to solve “technical problems,” but the reality is that in most cases the tech is just the means to an end.

I soon realised that consulting offered a way of disconnecting the blue pyramid from the green ladder.

By operating from outside the corporate pyramid, I could advise senior leaders and decision-makers on their challenges without needing to occupy those positions myself.

I could work with multiple organisations, gain exposure to different approaches and help connect ideas that weren’t necessarily visible from within any single organisation.

There was also less need to become embroiled in the internal politics of each client organisation.

Another PAOSS article (Was Working in Telco Always Boring? 5 Ways to Reignite Energy Across the Industry) mentions how working from outside the big corporate structures often allows me to achieve far more in a week than when I’m working inside them. Less time in meetings and bureaucracy, more time actually solving problems.

This certainly isn’t to suggest that consulting and/or running a business is a better career pathway for everyone. Just pointing out that it has been for me.

Some people love being part of a large organisation. Some want the stability of employment. Others genuinely enjoy leadership, organisational development and the challenges of managing large teams. Some people have the skillsets that are perfectly adapted to driving big businesses.

And some people want to spend their entire careers as specialist Engineers because they love the technical work.

All perfectly reasonable choices.

It’s just that the corporate pyramid and the Value Ladder aren’t the same thing.

You might climb both simultaneously. You might climb one without climbing the other.

In fact, an individual working independently could potentially influence an entire industry without having a single person reporting to them.

That’s a fascinating possibility, isn’t it? Can you think of anyone in your circles who have disconnected the two?

.

4. Abstract, but connect. The TMN pyramid analogy

Long-time PAOSS readers will be familiar with my fondness for the old TMN (Telecommunications Management Network) pyramid.

Even though it’s a framework from decades ago, I still find it useful for explaining the way OSS/BSS operate.

We previously discussed the TMN pyramid and the way information flows through the different management layers here (Orders down, faults up).

One of the fundamental principles is that each layer up the pyramid tends to do two things:

• Abstract: partially disconnect from the technical details in the layer below
• Connect: apply a broader set of information, resources, services and business considerations

For example,

• An EMS might understand an enormous amount about the specific network elements it manages
• A network management layer abstracts some of that detail, but understands how multiple elements interact across a broader network
• The service management layer needs less information about specific device configurations, but much more about how the underlying resources combine to deliver services to customers
• And the business management layer needs even less of the technical detail, but a much broader understanding of the commercial context

Each layer up abstracts more, but connects more.

It’s a principle that applies equally well to the Value Ladder.

• At the lower rungs, we tend to specialise in the details.
• As we move higher, we’re increasingly required to understand how those details fit into a much bigger picture.
• We need to connect more systems, more people, more organisations, more objectives and sometimes even more industries.
• And in most cases, that means relying on other people / connections to handle the details.

A CEO doesn’t need to know every configuration parameter in the network. But they do need to understand how the network contributes to their organisation’s strategy, competitive position and profitability.

An Industry Architect doesn’t need to know the intricate details of every participating operator’s OSS/BSS. But they do need to understand enough about those systems and the organisations surrounding them to identify common challenges and possible solutions.

There’s an important caveat here, though.

I’ve worked with some brilliant Architects who have an extraordinary ability to zoom in and out of the details.

They can sit with executives discussing multi-year transformation objectives, then join a technical workshop and understand the gnarly implementation challenges that might prevent those objectives from being achieved.

They don’t necessarily know all the answers, but they know enough to ask the right questions and recognise when something doesn’t stack up.

This zooming in and out capability was a central theme of another earlier article.

I think it’s one of the essential skills for moving up the Value Ladder.

BTW. Too much abstraction without sufficient understanding of the underlying detail can lead to some spectacularly bad decisions too.

.

5. Valuable Tripods and the ability to connect the dots

This brings me to another concept we’ve discussed many times on PAOSS.

Valuable Tripods.

For those unfamiliar with the concept, Valuable Tripods are the relatively rare individuals who have enough knowledge across three different areas to make meaningful connections between them:

1. IT / Technology / Systems: The applications, databases, software architectures, integrations and technical building blocks
2. Operations: The networks, business processes, people, organisation structures and practical realities of operating them
3. Business Value: How all of the above contribute to competitive advantage, commercial performance, customer outcomes and strategic objectives

We’ve previously discussed how OSS/BSS projects often have lots of people who are incredibly capable in one of these areas.

Some have deep expertise in two.

But those who can make valuable connections across all three are relatively rare. They also happen to align with the handful of most valuable people I’ve ever worked alongside.

And this is where I think the Value Ladder and Valuable Tripods intersect.

• A specialist Engineer might understand exactly why a particular data field isn’t being populated correctly in a network inventory system.
• A Valuable Tripod might recognise that the missing data is preventing the operator from accurately identifying available network capacity.
• They might then connect that with the business problem of unnecessarily building new infrastructure when existing assets could potentially be reused.
• And that might lead to an entirely different solution, potentially saving millions in capital expenditure.
• Same underlying technical issue. A much bigger frame of reference.

Now consider taking that thinking a rung or two higher.

What if the problem isn’t confined to a single operator?

What if hundreds of operators are dealing with similar data integrity challenges because of structural weaknesses in the way inventory information is captured, maintained and exchanged between systems?

Could we solve that problem at an industry level rather than forcing every operator to develop its own workarounds?

That’s a different sort of problem.

[Side note: We’re just about to launch a detailed discussion pack on Data Foundations and Data Quality Improvement Techniques. Keep your eyes out for it, as we plan to publish it imminently, just adding the finishing touches to it currently]

Bigger, industry-wide, problems tend to require technical knowledge, operational knowledge, business understanding and the ability to connect people and ideas across organisational boundaries.

It also requires the ability to see the underlying problem rather than simply the symptoms.

That’s what I think of as tripod thinking at increasingly larger scales.

The three legs of the tripod remain important, but the number of dots we’re connecting expands with each rung.

.

6. The opportunity I didn’t fully recognise

There’s another personal experience that has made me think about the Value Ladder.

In the early 2000s, I was fortunate enough to have an opportunity to spend a year advising the board of a Tier-1 telecommunications operator on its very first, multi-year OSS transformation.

It was a fascinating engagement and gave me exposure to challenges and decisions at a scale well beyond most of the projects I’d been working on.

In Value Ladder terms, I was being exposed to problems around rung five and six. The work involved the bigger picture of how OSS could enable an organisation’s future direction, rather than simply delivering an individual technology solution.

But here’s the bit I slightly regret in hindsight.

When the engagement finished, I went back to the consulting company I was working for and returned to the more typical rung three and four projects that made up our normal pipeline.

They were still good projects. Interesting clients, clever people and plenty of technical challenges.

But perhaps I missed something. I hadn’t thought big enough!

I’d been given an opportunity to work on a much bigger problem and a different frame of reference. I’d already demonstrated that I could contribute at that level.

Why didn’t I use that as the launching pad to seek out the next challenge of similar or greater scale?

Why did I simply return to the familiar? (forehead slap!!)

I suspect many of us have done something similar. We get invited into a strategic initiative, a major transformation or a particularly interesting cross-functional project. For a while, we find ourselves exposed to decisions and problems we might otherwise never encounter.

Then the project finishes and we return to business as usual.

We might add the project to our CV, but do we actually use the experience to change the type of problems we seek out next?

In hindsight, I think I should’ve been more deliberate about ascending the ladder from that opportunity.

I’d missed an opportunity to expand the scope of problems I could help solve.

And that brings me to another important consideration.

.

7. Value creation, value capture and autonomy

So far we’ve talked about climbing the ladder to solve bigger problems and potentially create more value.

But creating more value doesn’t necessarily mean capturing more value for ourselves.

These are two different things.

An employee working on a major transformation might help their organisation create hundreds of millions of dollars in benefits.

Their remuneration might be quite modest relative to the value they’ve helped create.

Meanwhile, an entrepreneur could build a relatively small business that solves a narrower problem, but retain a significant proportion of the value generated because they own the business.

Neither pathway is automatically better.

One might provide financial security, career development, access to resources and the support of a large team.

The other might provide ownership, control and the possibility of financial upside, but with greater risk and additional responsibilities.

It comes down to what you’re trying to optimise.

This connects with another concept we’ve discussed previously, the three levels of personal autonomy (Was Working in Telco Always Boring? 5 Ways to Reignite Energy Across the Industry):

1. Autonomy over your body
2. Autonomy over your time and activities
3. Autonomy over your destiny or direction

The third level has become particularly important to me. I want to have greater autonomy over the problems I choose to solve.

That doesn’t necessarily mean I have to own a large business or employ hundreds of people.

In fact, owning a large business could introduce a whole new set of responsibilities that pull me away from the very things I want to spend my time doing.

It might make me better at capturing value, but worse at enjoying the process of creating it!

So perhaps we should consider three separate dimensions:

1. Value creation: What problems are we capable of solving and how much value do those solutions create?
2. Value capture: How much of the value we help create do we retain, whether through salary, consulting fees, equity, intellectual property or other mechanisms?
3. Autonomy: How much control do we have over the problems we choose to solve and the direction we want to take?

It’s quite possible to score highly on one dimension and relatively poorly on another.

• An employee may have considerable value creation capability but limited autonomy to choose which problems they work on.
• A business owner might have enormous autonomy but be spending most of their time on relatively small operational issues.
• A senior executive might have significant remuneration and authority but very little genuine freedom over their calendar.
• Or an independent adviser could be working on problems across multiple organisations, with relatively little organisational authority but considerable influence over the solutions being considered.

I don’t think there’s a universally correct combination.

But for me, creating PAOSS has been part of an attempt to increase all three dimensions.

It gives me a platform to share ideas, build relationships, create assets and hopefully contribute to solving bigger problems.

But more importantly, it gives me greater freedom to choose the direction I want to move.

.

8. Is AI about to break the bottom rungs of the ladder?

There’s a fascinating new dimension to all of this.

AI.

You may’ve heard of it.

Most engineering careers have traditionally been built from the bottom rungs upwards. From the grad roles at rung 1.

You spend years learning the details, making mistakes, resolving technical issues, working alongside experienced colleagues and gradually developing a deeper understanding of how everything fits together.

Over time, you start recognising patterns and connections across domains.

Eventually, you might begin to develop the broader perspectives that allow you to move into Solution Architecture, Enterprise Architecture and beyond.

But you’ve probably already heard the rhetoric (and reality) – AI is starting to change that process.

Many of the problems on the lower-rungs are becoming increasingly solvable by AI systems.

Coding, configuration, log analysis, troubleshooting, technical documentation, testing and even elements of architecture can now be supported by increasingly capable AI tools.

That raises an uncomfortable question:

What happens if the lower rungs of the ladder start disappearing?
Does it prevent ascension to the higher rungs?

If organisations need fewer junior Engineers to perform the routine technical work, how will the next generation build the experience required to become capable Architects and Valuable Tripods?

Will we end up with people who can produce impressive architecture diagrams, but have never had to deal with the messy realities of implementing them?

That’s a genuine concern.

But I think there’s another way of looking at this:

• What if AI actually makes the ladder easier to climb?
• What if someone at rung one can use AI to explore the sorts of problems that previously required years of exposure to several different technical domains?
• What if a Solution Architect can use AI to investigate enterprise-wide dependencies, model different architectural options and understand unfamiliar business processes far more quickly than before?
• What you can independently leverage a team of virtual researchers to help you solve bigger problems that previously required a large team of specialists?

The opportunity might not be to replace the experience required at the lower rungs, but to compress the time required to develop broader perspectives.

And perhaps more importantly, to give people the capacity to tackle bigger problems without necessarily needing to build bigger teams or organisations around them.

I find that a particularly exciting possibility.

Naturally, there are limits. AI doesn’t magically give someone the judgement that comes from years of real-world engineering experience. It can make it easier to produce plausible answers without necessarily understanding their limitations.

But I suspect the people who combine genuine technical foundations, a bigger vision (Valuable Tripod thinking) and the ability to use AI effectively could find themselves moving up the Value Ladder much faster than previous generations.

The challenge will be making sure they develop sufficient depth whilst expanding their breadth (ie collecting more dots to enable you to connect more dots).

For people entering the industry, I’d encourage you to think of AI as an opportunity to accelerate your climb rather than simply a threat to your first job.

And for those of us further along in our careers, perhaps AI provides an opportunity to attempt problems that were previously beyond our individual capacity.

.

9. How do we deliberately step up a rung?

A few years ago, I wrote an article called How to take in OSS/BSS’s Bigger Picture.

It introduced what I called the Think Bigger Pyramid, with different frames of reference ranging from the details of an individual project through to industry-wide challenges and ultimately the needs of communications users across society.

The Value Ladder is closely related, but there’s an important difference.

The Think Bigger Pyramid helps us consider problems from different frames of reference.

The Value Ladder is about developing the ability to contribute to solutions at those increasingly broader levels.

And that raises a practical question.

How do we actually move from one rung to the next?

I believe it starts with changing the questions we ask:

• Instead of asking how to make a particular OSS component work, ask what broader operational problem the component is helping to solve
• Instead of asking how to deliver a successful OSS implementation, ask what competitive advantage the organisation is trying to achieve through that implementation
• Instead of asking how to modernise the OSS/BSS of one operator, ask why so many operators keep encountering the same transformation challenges
• And instead of assuming that the problems we see in telecommunications are unique, ask how other industries might have already solved similar problems.

Each of those questions moves our frame of reference outwards and upwards.

It also changes the people we need to speak with.

• An Engineer might spend most of their time with other Engineers and technical specialists.
• A Solution Architect needs to connect with a broader range of technical and operational stakeholders.
• An Enterprise Architect needs to understand the priorities of business leaders.
• An Industry Architect needs to engage with people across different organisations, including people who might normally be considered competitors.
• And someone tackling problems across industries needs to understand perspectives that could be completely foreign to their own area of expertise.

Perhaps that’s another way to describe the Value Ladder.

Each rung expands the range of people, ideas, disciplines and problems we need to connect.

It also creates an interesting challenge.

At the lower rungs, we often receive clear problem statements from someone above us.

At the higher rungs, there may be nobody giving us a problem statement. We have to proactively identify the bigger problems ourselves.

And that’s a very different skill.

It requires us to look beyond the immediate tasks, question assumptions and recognise problems that perhaps nobody has yet articulated.

Maybe that’s where the greatest opportunities lie?

.

10. Where does PAOSS fit on the ladder?

I’m conscious that there’s a danger of making this whole model sound a little grandiose and self-congratulatory. Groan!

Especially when we get to rung nine and start talking about solving societal problems!

I certainly don’t claim to operate at those levels.

In fact, a big reason for putting this and previous articles together is to challenge myself to think bigger – to think more deliberately about the sorts of problems I want to help solve in the coming years.

PAOSS started as a way of documenting and sharing what I’d learned from working on OSS/BSS projects.

Over time, it has become a platform for connecting people, ideas, companies, technologies and opportunities across the industry.

It’s given me exposure to problems and perspectives I might never have encountered through consulting projects alone.

And with the increasing capabilities of AI, I can see opportunities for relatively small teams to have an impact that might previously have required much larger organisations.

But I also recognise that I need to keep focusing my own frame of reference upwards.

For years I’ve been fascinated by the recurring problems we encounter on OSS/BSS transformations.

• The same data integrity problems.
• The same integration challenges.
• The same difficulties reconciling network and service information.
• The same organisational boundaries that prevent information from flowing effectively.
• The same projects that deliver technology but struggle to achieve their intended business outcomes.

We’ve collectively spent enormous amounts of money solving variations of these problems. Yet we keep encountering them again and again.

Perhaps the bigger opportunity isn’t to help another operator solve its individual OSS/BSS problems.

Perhaps it’s to help the industry find ways to avoid creating those problems in the first place.

That’s the sort of question that starts pushing my thinking towards the higher rungs of the Value Ladder.

And perhaps the PAOSS community can help connect the people and ideas needed to make progress on some of them.

I don’t have all the answers. Not even close.

But that’s part of what makes the challenge (for you and me) interesting.

.

11. You don’t have to climb, but perhaps you should look up occasionally

I want to finish with an important clarification.

I’m not suggesting that everyone should aspire to the upper rungs of the Value Ladder or Corporate Pyramid.

Our industry needs people who love the details and love the C-suite skills.

We need brilliant Engineers who understand the intricate workings of network protocols, databases, software architectures and physical infrastructure. We need people who enjoy solving the hard technical problems that the rest of us might struggle with.

Some of the most important innovations come from deep specialists who have no desire whatsoever to become Architects, Executives or Entrepreneurs.

And that’s a good thing.

Nor does operating at a higher rung make someone smarter, more important or necessarily more valuable than those working at the lower rungs.

The ladder simply describes a progression in the breadth of problems we’re capable of helping solve.

But I do wonder how many people are working on smaller problems than they’re actually capable of tackling. Most of you I suspect!!

• Have you been given a glimpse of a bigger problem but returned to your usual work without recognising the opportunity?
• Do you believe you need to wait for a promotion or a more senior job title before you can start thinking about higher-level challenges?
• Would you find your work more energising if you could see how your expertise contributes to something much bigger?

For me, one of the great attractions of engineering has always been the ability to break complex problems down into manageable pieces.

But perhaps the next stage of our development is learning how to reverse that process.

To take the individual pieces we’re so familiar with, zoom out and recognise the larger problems they collectively represent.

To abstract some of the detail, but connect more of the dots.

And to become more deliberate about choosing which problems we want to help solve.

That’s what I think climbing the Value Ladder is really about.

Not becoming more senior. Becoming capable of making a bigger difference.

So I’m curious.

What rung of the Value Ladder do you feel you’re operating on today?

What rung would you like to operate on?

And perhaps most importantly, what’s stopping you from having a crack at the next one?

I’d love to hear your thoughts, particularly if you’ve found ways to climb the Value Ladder without needing to climb the corporate pyramid.