As software engineers, we are used to designing large system architectures by defining the roles and responsibilities of each component. We assess whether some components have overlapping responsibilities, are overburdened with too many responsibilities, or if there is a gap that must be filled with a new component. Defining, maintaining, and evolving the exact set of responsibilities of each component is one of the key ways to make sure that our architecture serves its purpose today and can scale to the requirements of tomorrow. We also make sure that as our systems grow, we have enough telemetry in place to know when our components need to evolve or to be replaced to support the growth. Sometimes it feels almost magical to see some complicated software system, consisting of dozens or hundreds of components & services working together, producing the intended end-to-end user experience.

About 17 years ago I started my professional life in a software company with 2 people. As the world and technology landscape around us changed, so did the company. We started from Mac desktop applications and various web-based platforms, moved to iOS development & consulting services, then moved to offer our own platform covering iOS, Android, Web, and ever-growing backend infrastructure. At the same time, the number of our employees has grown somewhat, but our organizational structure hasn't changed much - we were and are a company with relatively informal, flat, and small organizational structure.

During some of my software development consulting gigs in other companies, I was always personally interested in how those larger companies are organized and how that organization is reflected in the day-to-day work and responsibilities of people working in those organizations. It was so different from my "home company". Seeing the work of hundreds of people and teams working together – from software development to marketing, from hardware engineering to procurement and work in factories – all working in sync to produce the intended product, service, and business outcomes felt just as magical as seeing the large software architecture in action. I could see the official org chart, but unlike software architectures, there was usually less talk about roles & responsibilities, far less exact definitions of responsibilities and expectations, and far less telemetry in the daily work to notice when things needed extra attention.

That's why I was pretty excited when I opened the book called "The Leadership Pipeline: How to Build the Leadership Powered Company" by Ram Charan, Stephen Drotter, and James Noel. The book constructs a pipeline model for defining the natural hierarchy of managerial/people leadership work that exists in organizations. Here it should be noted that in many software organizations there is often a parallel pipeline for technical leadership work - this book is focused on the people leadership track, although it recommends using a similar pipeline model for the technical track. For a technical leadership -focused resource, I couldn't recommend Will Larson's blog highly enough.

Leadership Pipeline is written around six leadership passages:

• Managing Self -> Managing Others
• Managing Others -> Managing Managers
• Managing Managers -> Functional Manager
• Functional Manager -> Business Manager
• Business Manager -> Group Manager
• Group Manager -> Enterprise Manager

A passage represents a change in organizational position, where there's a major change in skill requirements, time applications, and work values. Authors note that the exact number of passages varies by company, some might have four, some seven, and the pipeline & rules should be adopted to the organization. The main contribution of the book is the model where each level is evenly spaced, with proper differentiation, and passage is described in terms of these 3 changes:

• Skills: the new capabilities required to execute new responsibilities
• Time applications: new time frames that govern how one works
• Work values: what people believe is important and should be focused on

For example, from the Managing Self -> Managing Others passage:

Skills

• Planning: projects, budget, workforce
• Job design
• Performance measurement & monitoring
• Rewards & motivation
• Acquisition of resources

Time application

• Annual planning - budgets, projects
• Setting priorities for unit & team
• Communication with other units, customers, suppliers

Work values

• Getting results through others
• Managerial work and disciplines
• Success of direct reports

One recurring theme in most of the passages is the difficulty of letting go of time applications and work values of the previous level, and unwillingness to accept changed time application requirements of the new level. We all know how psychologically difficult it is to let go of the work which has helped us become who we are today. When faced with a vague "now be a leader" requirement, that IDE and debugger feel so cozy and familiar. What happens is that the leadership work isn't getting done by the person who's paid to do it. The work is either left undone completely, or it's being done by the person from the next leadership level, preventing the person below to develop properly, and shifting the time application from the person above to the incorrect level.

The Leadership Pipeline model attempts to address this by making the model explicit, by making sure that people are informed about the expectations of different level, and by keeping people accountable by integrating the leadership framework into performance improvement programs.

Overall, this book was a worthwhile read and provided a practical model for clarifying expectations around various levels on the people management/leadership track. Also, while not directly applicable to small company context, reading the requirements for skills, values, and time applications of various corporate leadership levels were quite an eye-opening experience - like reading a good adventure book about a world so different than your own.