I am a believer in the truth of the “Peter Principle“, developed in the ’70s by Laurence J. Peter, which observes that managers tend to rise to their “level of incompetence”. I’ve seen this personally play out with many people with whom I’ve worked over the years. I’ve seen it happen to bright young superstars that rocketed up the ladder to ever more senior roles, and I’ve seen it happen to experienced and seasoned managers who grew their careers slowly and deliberately. In both cases, these managers found themselves in situations where they needed to be able to use skills, at a high level of proficiency, which they hadn’t yet developed. Trying to learn something new and put it to use simultaneously in a masterful way is incredibly hard, and takes a huge amount of extra time to pull it off. Imagine if you accepted a job where you were expected to write very complex C++ code, from day 1, but you had never written a line of it in your life. If you had some great foundation skills (understanding of OOP, lots of experience with other languages, etc.) you might be able to power through – but it would probably involve lots of time learning and writing code in your personal time to ramp up quickly. If you didn’t have those foundations (had never written any code before) you’d probably find yourself leaving that job pretty quickly.
But how do you know what skills you’ll need before you need them? And how do you go about acquiring them all and getting the 10,000 hours of practice you’ll need for mastery? I’ve tried in the past to build a complete list of specific skills needed to be great at a job. When I became a Director of Program Management, I wrote a list of all of the skills for which a person should be proficient in order to succeed as a Group Program Manager (the direct reports of a PM Director). My goals were to have some means of evaluating current GPMs (how well did they demonstrate each skill?) as well as to give aspiring GPMs a to-do list for skills to work on. Even leaving out dozens or hundreds of general purpose skills, the list was over 100 items. And that was just for one job, so how to translate that into a careers-worth of job movements?
I observed that many of the folks that I saw hitting their “Peter point” did so because there were sets of skills that they were missing, and that they often had some theme to them. For example, the person may have been put in charge of a turn-around project but had only ever worked on new Version 1 startup type projects. The skills required to do a successful turn-around are very different than those required to get a V1 off the ground. So it seemed that, at each job level change as people moved up the ladder, where they fell short had a lot to do with the kinds of projects that they had led or worked on earlier in their careers. This was very evident with the bright young superstar type people who hit their Peter point. They just hadn’t had many first hand leadership experiences to build on. But it was also true with the seasoned veterans, since it is entirely possible to work 20+ years and only experience a handful of business and product (or technology) problem types.
Framing
As I tried to wrap my mind around this I built a mental model around the different business and product problem types I could define. This emerged as a matrix, with one axis on the life-phase of the business (whether it was growing or declining), and one axis on how effectively the team was operating (whether they were low or high functioning).
Each specific point in this matrix represents some different situation for a team and business to manage. There are likely a massive number of variations that could be defined, as well as other dimensions to consider. But this gave me a reasonable model to think through, and a finite set of problem types – and therefore leadership experiences – which would be useful to grow the skills necessary to lead in any situation.
I mapped out 12 distinct business/product problem types which I thought represented significant learning opportunities, with the idea that a leader who gains first-hand experience in all 12 would be sufficiently well-rounded to be able to tackle just about any situation that they were thrown into.
Note that you can interpret the “business problem” here in multiple ways depending on your discipline or field. If you look at these from the standpoint of an MBA business leader, the “growth” or “decline” dimension might translate into total addressable market, profit margins, OpEx, etc. Tackling a problem type with a team that was in the “low-functioning/declining” quadrant might involve doing a business turnaround to gain financial efficiencies or divesting the business. If you look at these from the standpoint of an engineering leader, “growth” may be more about adoption of a technology or quantity/quality of contributions to your open source project rather than about dollars. A “high-functioning/growth” quadrant team might be one that is developing cutting edge AI/ML work and getting massive adoption of their algorithms or demand for their valuable training data.
In almost all of these cases the goal of the leader is to take the problem type they have and drive it up and to the right in the quadrants – to a team and business that is growing and high-functioning. In some cases though, the answer may also be to drive the decision to cut the team or business and refocus those people on something else.
Expanding on Each Problem Type
I’ll expand a bit on each of the problem types that I defined to explain them each a bit more, and why I think each one is an essential experience for a leader to learn from.
V1 STARTUP
Probably the most obvious must-have experience is about getting something totally new off the ground. This can be a startup business that begins in a garage, or it can be a significant new project that starts within a major corporation. The key aspects of this kind of project are learning how to generate excitement for the idea, secure funding, define and refine the vision, overcome the status-quo, and find the internal drive and grit to keep going when obstacles get in your way. V1 Startups very rarely have high-functioning teams, since high-function usually has a lot to do with mature processes, long-term relationships, and tools & systems which have the kinks worked out of them.
V2 STARTUP
An often overlooked experience is doing the next major rev on a new startup idea. The most valuable flavor of that is doing a V2 on your own startup idea. When I have done this I’ve learned a massive amount from it. When you ship your V1 it can be all celebration and excitement, and it feels amazing to see your idea come to life. But then reality sets in, and you learn so much from seeing how customers actually use it and where your assumptions or ideas were flawed. 10 years ago with boxed software “V2” literally meant doing a major new version, but with today’s faster paced services and apps it means “the next big change cycle” where you are making major changes based on some significant run rate of user data or feedback. V2 Startups usually have the characteristic that there is more clear growth and the team is becoming more high-functioning as it matures.
EXPLOSIVE GROWTH
When you land on a great idea, you can find yourself in a situation where adoption and growth take off explosively. This is a great problem to have. You learn a tremendous amount about how to focus your energy and resources, how to ensure that you don’t under-invest in your processes and tools (which will come back and kill you later if you do), how to scale up rapidly in how you do just about everything, and how you manage growing customer expectations.
STARTUP REBOOT
Explosive growth can also lead to big problems in how your team functions as well. It’s not uncommon for key people on a startup team to punch out after the initial success, parlaying that win into a new opportunity somewhere else (you also see the “serial V1 entrepreneurs” emerge here – people that only want to do the #newshinything.) In early startup phase, it’s pretty common for important things to not be well documented, or only covered by one person since you start with minimal funding, so a key person leaving at the wrong time can cause things to break down. Rapid growth can also put pressure on tools or systems which cannot handle the scale, resulting in livesite issues, frazzled engineers, and angry customers. This too though is a great learning opportunity, as you’ll learn how to build rapid-response systems, focus teams, engage with unhappy customers effectively, and learn how to bail out a ship and patch the hull at the same time.
CULTURE REBOOT
Mature teams and businesses which are past their initial growth surge can also find themselves in need of a significant reboot. Often this is due to the core business that the team was built upon needing to change, but the internal momentum and power of the status-quo preventing change from happening. This can feed on itself in a reinforcement loop – people becoming increasingly frustrated that things aren’t getting better while simultaneously resisting change. The result is that the team becomes low-functioning and unable to keep the business moving forward. In this case the team needs a Culture Reboot, focusing their energy on how to improve the way they work and connecting that improvement to the way they deliver for their customers. There is tremendous learning opportunity taking a team through a Culture Reboot. You’ll learn to be a change-management expert, how to motivate and inspire through storytelling, how to rebuild teams (including people and process aspects) and how to measure and communicate progress through the arc of the reboot.
STUCK IN THE MUD
A team/business that has flat growth but hasn’t degraded too badly (to the point of needing a Culture Reboot) can be said to be “Stuck in the Mud.” I’ve seen this occur frequently in cases where the team has low energy or desire to go shake things up, for instance on a team which is coasting on previous successes. Coming into a team like this offers the opportunity to learn some important change-management skills, vision and strategy building, and other turn-around skills. In fact, this is often the best type of team to start learning how to do a turn-around since the stakes are usually lower and often the problem is that the team just needs to be led out of the doldrums with an infusion of energy and new ideas.
TURN AROUND
There are many different definitions for exactly what constitutes a team in need of a “Turn-Around”. For this discussion, I use the term to describe a team which has declining growth and team effectiveness squarely in the low-functioning range. Basically this is a team and business which is in serious trouble and needs to make some significant changes to right the ship. Of all the experiences a leader can take on this is one of the most valuable, and I recommend doing several Turn-Arounds since each time you will learn more. I also recommend being very mindful of whether you have built the skills to pull it off. I like to think of a team as comprising of “The 3 P’s” of People, Process, and Product. So when looking at a turn-around case it’s helpful to use that lens: What part of the team is broken? Do they have great people but just cannot plan or execute well because of their processes? Do they have good product but cannot attract strong talent to the team? If a Turn-Around has 2 of the “3 P’s” in great shape and one needs fixing, it’s a good first one to take on. But if a Turn-Around project has poor talent, terrible process, and lousy product – only a real Turn-Around master should try to take it on. There are so many things to learn from doing a Turn-Around. Depending on which of the “3 P’s” needs fixing, you can learn about creating talent management plans, how to recruit and retain people, developing effective “rhythm of business” processes (without creating bureaucracy), defining product roadmaps, lift & shift of technology stacks, and much more. Of all of the experiences listed here, this is the type that even after doing a great many of them is a continuous source of learning for me.
LIFE OR DEATH TRIAGE
Arguably the most extreme case of a turn-around is when a team/business has reached the point where it is very low-functioning and the business is declining significantly. In these cases, the normal things that one might do to turn things around might have little to no effect. A team in this state might be losing people rapidly, have legal or regulatory challenges that are overwhelming them, or have significant structural issues that need to be addressed. The goal with a team like this is to get to a decision, as quickly and effectively as you can, about whether to shut it all down or to try to save it and move it up and to the right into a normal Turn-Around scenario. It can be very hard for the people who built a team or business to come to the conclusion to shut it down. I’ve done a few of these in my career, and each time it was something that got moved under me in a reorg because the original team just couldn’t make the call. I had to learn about the business/technology super quickly, understand what the fundamental issues were, and decide if it was worth saving. In a scenario like this you will learn how to rapidly analyze a problem space, construct plans to pivot away from the failing direction on on to a new one, create pitches for your stakeholders (or investors), and if it comes to shutting it down – how to do that in a way that is respectful to the people involved.
FOCUSED EFFICIENCY
On the more positive side of the spectrum, many teams/businesses will find themselves at a point where the team is still working pretty well together, but the business has moved from growing to declining. There are many variations to this, but one that I think every leader should manage through is the case where the team shifts from a growth-mode (characterized by expanding OpEx budgets, active hiring, and hyper-optimism on the team) to an efficiency-mode (characterized by belt-tightening, reduced hiring, and angst about the future on the team.) Learnings here for a leader include how to drive efficiency and use “scarcity as a resource” to focus on the most important work, how to keep the team inspired and energized, and how to reignite growth either by increasing the size or % ownership of the addressable market or pivoting the business. I think most people who have experienced both will say that it’s more fun to lead a team that is growing than one that is contracting, but it is a terrific learning experience to go through it and develop the skills to bring the team/business back to health.
CHASM CROSS
In the life cycle of a team there are usually two major points where the product & business have to navigate a huge transition. The first is when the product/business is young, and is a disruptive innovation which is trying to build its growth by convincing the mainstream to switch to it rather than the established solutions. GeoffreyA. Moore defined this as “Crossing the Chasm” in the early ’90s, and while his initial work was aimed primarily at marketers, the concepts and lessons are useful for engineers and technology leaders as well. If a team crosses the chasm successfully, it may find that its products in time become the established solutions, and now finds itself the target for competitors to disrupt. The only way to survive is to develop its own disruptive solution and beat competitors to the punch. Clayton M. Christensen coined the phrase “The Innovators Dilemma” to describe this, but essentially it is just “Crossing the Chasm” as seen from the point of view of the established solution vs. the disruptive innovator. At both of these inflection points, the job of the leader is to correctly identify the situation and then take action to lead the team through the chasm being crossed. In many ways, a Chasm Cross problem is kind of like a Turn-Around but with a more effective high-functioning team. In that way, it can be a great place to learn skills that will be useful when doing a Turn-Around.
LIGHTS OUT
A Lights Out scenario is like the mirror image of a Life or Death Triage. Instead of a dysfunctional team, a Lights Out team is usually one that is high-functioning but is stewarding an existing business through senescence. Usually the bulk of the team has already pivoted to something new but this particular business or technology is being kept alive in order to service customers that haven’t switched over yet. Many leaders will shy away from leading an end-of-life product, but again there are many great things to learn in doing so. This can include building and executing conversion plans to migrate customers, planning and managing reductions in hardware or services resources, and doing thoughtful talent transitions to help move people into new roles.
Healthy Mature
The final problem space to talk about is the Healthy Mature business. As I said earlier, this is typically the end goal for any of the other business & product problem types. Healthy Mature teams typically are high-functioning, and the business is still growing but not at the same rate as when it was new. This reflects again that it usually takes a team some time running a business in order to move up the axis on how well the team functions. I typically recommend that people work on a Healthy Mature team early in their careers. This is partially so that they can really learn what the “feel” of a good team is like (good people, effective process, strong product) so that they have a benchmark against which they can compare other teams as they experience them. But it is also because, as they grow and become more versatile leaders, they will frequently be pulled into a new project before the team they are leading reaches the Healthy Mature state. Once they’ve demonstrated they can move a team up and to the right in this matrix, they will be in high demand to do it elsewhere so they’ll get pulled away before getting to enjoy the fruits of their labor. Past success is a predictor of future success, and there increases demand.
Collecting Experiences
So, with the overall framework and 12 leadership experiences I’ve laid out, how exactly should one go about collecting them? And how to solve the problem that in order to not hit the “Peter point” one has to already have the skills they need when they need them? The answer will vary depending on the unique person involved, since everyone starts from a different place of life experiences, intuitions, and personal passions that can make them more or less inherently likely to do well and learn quickly from each of these 12 experiences. I do think there are 2 good rules of thumb to follow as you think about what your individual path looks like.
1. Be a co-pilot before you are a pilot
You can learn 80% of the skills you’ll need to be successful leading a team or business by being the person who is most directly helping the current leader. In other words, if your manager is trying to lead your team through one of these experiences, get as involved as you can. Find ways to assist key activities, and ask to take on things which can be delegated to you. Ask to sit in on any strategy or planning sessions where you can learn what techniques the leader is employing, why they are choosing those techniques, what other options they considered, what measures they are using to see if they are working, and what they will do if they find they aren’t. You can learn a tremendous amount by getting direct visibility into the thought process of a skilled leader, and taking on tasks which they can have you do. Clearly for this to be useful to you the leader with whom you are working needs to be someone you believe has the expertise for you to learn from. My advice is usually that if you don’t think your leader has anything to teach you, it’s time to move on.
2. Make adjacent moves
If you leap from a Healthy Mature team to a Life or Death Triage team, it will be a serious shock to you. Your whole way of working every day will be a major change, and your leadership skills will all be put under intense pressure immediately after you move. But going from a Healthy Mature team to a Chasm Cross or Explosive Growth team will be less of a shock. Both of those are closer on the team-function axis to a Healthy Mature team, so likely when you join those teams you won’t need to do a major overhaul of the team’s work processes while you also tackle the other problems. This is roughly true for all of the other problems which have adjacency – one hop away will be a sizable change, but probably not so big that it utterly resets how you are approaching leadership vs. your current problem space. There are times where you will need to make a bigger leap to gain an experience that you really want, or because you are being recruited (or “voluntold”) for something. In general I recommend taking really big leaps either early in your career where you’ll either be a co-pilot or working on a smaller scope problem space (with lower risk of failure), or later in your career after you have built a really solid repertoire of skills that you can further build upon when confronted with a big new challenge that stretches you.
I hope that this post has been useful or thought provoking. As I said at the beginning, I believe this approach will be applicable for most disciplines which involve a need for leadership, whether that happens to be business, marketing, engineering, design, etc. I would love to hear whether you agree or disagree in the comments, or whether I’ve missed a problem type that you feel is essential as well.
Great write up Gabe. The model was very helpful to identify the experiences that I have gained over my own career and the gaps that exist for me to become a well-rounded leader that is ready to take on any challenge. I just wish I had more explosive growth and fewer lights out experiences.
Truly detailed analysis of leadership situations to try to cover to know them all. I believe one lifetime won’t be enough for most of us, but great to know that there is always more to learn 😉 Thanks!
I really enjoyed reading this and specifically appreciated the diagram. Question for you – how do you define ‘early in career’? Understandably risk is smaller when in those roles, so wondering if you’re measurement is in terms of years working, years on a team, level (Microsoft speak), etc.
I think of “early” as when you are still either an individual contributor (not managing anyone) or when you are a 1st level manager. When you become a 2nd level manager (manager of managers) I think you need to have a pretty well developed portfolio of skills, so I would think of that as “mid” career. I think it is easy for people to get confused on “leader” vs. “manager”. While you must be a leader to manage (I believe), you needn’t necessarily be a manager to lead.
Hi Gabe, thanks for writing this article. As an individual contributor, I think the diagrams are great for thinking about where my own projects fall on the spectrum, and how I might need to adjust my approach accordingly.
One question I have: When thinking about a new project/business/team to take on, is it usually obvious what quadrant it would fall under? Growing versus Declining seems easy enough to quantify, but Low versus High Functioning seems more subjective, so I’m interested to hear any thoughts you may have on if there’s a way to quickly assess a new project/business opportunity without knowing too much about the inner workings of it.