Engineering the Leadership
Leadership is not “bosses”. Leadership is influence. An organization or initiative needs leadership to be happening, in order to get people moving in the same direction—hopefully a good direction. So-called “good leadership” is leadership that is effective, moves things in a positive direction, and enables everyone to flourish.
Leadership style is the cornerstone of agility.
In order for your organization to be successful and increase its agility, it must address leadership style. Leadership style is the cornerstone of agility. We cannot emphasize that enough.
Therefore, it is paramount that the key decision-makers take steps to ensure that the right leadership styles are present throughout their organization, from the top down. It starts at the top. People take their cues from above.
Leadership is a large and complex topic, so we can only provide an overview here. People need leadership training and leadership coaching. Training provides a conceptual foundation of the different forms of leadership. Coaching helps one to internalize desired forms and convert them into tacit behavior.
We recommend that leadership training and coaching start with senior leadership. Agile 2 Academy can provide both of these, tailored to a focus on agility. Over time, everyone who is in any kind of leadership role should have leadership training, and some degree of leadership coaching. Agile 2 Academy can help you to design a leadership training and coaching program.
Leadership training should encompass established leadership models. Some of those are listed in the panel on the right. Leadership coaching should focus on,
Raising one’s EQ.
How to recognize others who have certain leadership styles and potential. (Hint: it is not always the people who “seem like” a leader)
How to mentor those who have leadership potential.
How to lead through Socratic inquiry and dialectic discussion. This is crucial when the work involves collaborating about complex issues.
Picking leaders is probably the most important step in filling out an organization. You must pick people whose leadership style is matched to the task. Leaders emerge as well, and you must become adept at recognizing positive and negative forms of leadership, and learning how to empower those who exhibit positive leadership styles.
Overview of Leadership In an Agile Organization
Leadership has two aspects:
The domain of issues over which one has leadership (influence or authority).
The style of leadership—that is, the manner in which one leads.
For example, a tech lead provides leadership over technical issues: that is their domain of leadership. Independent of that is their style of leadership, which may range from autocratic to a servant leadership style. (See “Other Leadership Styles” on the right panel.)
Timely Decision-Making Is Extremely Important
Organizations need to be effective at making high-quality decisions, in a timely manner. In the Constructive Agility Behavioral Model, we see that good decisions result from effective collaboration and from effective use of individuals, and those in turn result from people having the right knowledge and from cultural and behavioral norms. Still, a perfect decision is useless if it arrives too late. In business, time is extremely important.
If an issue goes unresolved, it means that work on that aspect of a product slows or stops until the issue is resolved. That delays the release of the product. Today, companies cannot afford to delay—competitors will use our delay to grab some of our market share. Therefore, it is extremely critical to rapidly (1) identify issues as soon as they arise, and (2) resolve them quickly.
That takes leadership. It does not mean that there is a “boss” who is watching for issues and then directing everyone to respond. It means that there is a system, culture, or individual who is watching, and will get the required discussions going with the right people, and push for rapid resolution. And that person or persons also need(s) to be listening, because issues are usually raised by others first; but they will not necessarily drive its resolution on their own unless it affects their work: that is normal, because people can only handle so much—having to deal with another issue increases their work-in-process. Therefore, a leader should take action by pushing to get the issue resolved.
Styles of Leadership
Leaders can use a diagnostic or a dialogic approach for orchestrating change.
A person’s leadership style is the way in which they lead. There is a wide range of leadership styles. The term “leadership style” is an informal one. Some commonly recognized styles are autocratic (aka “command and control”), Laissez-Faire (“hands-off”), servant leader, and transformational. (See the leadership styles that are explained in the right panel.) Leadership style has a huge impact on a team.
Leaders can also use a diagnostic or a dialogic approach for orchestrating change. We will discuss that at the end of this section.
The Role of Authority and Accountability in Leadership
Some leaders have explicit authority. Others do not. Authority is not a prerequisite for leadership. However, authority can be useful or even necessary if:
Someone who should be leading needs authority to get others to listen: sometimes the person who would be the best leader is not someone who others naturally pay attention to.
Accountability is needed: accountability without authority is a terrible situation to be in. Fiduciary accountability is important for many organizations (e.g., banks); managers are accountable for the money they spend; and accountability and authority are important when speaking to others on a group’s behalf.
Authority and accountability are two sides of a coin: authority is directed inward to a team’s members, and accountability is outward: one is accountable to stakeholders outside the team.
Accountability says nothing about how those outside a team behave towards someone who is accountable. Accountability means that you “speak for” the team. Interaction with those outside the team towards an accountable person can be helpful (a healthy partnership) or antagonistic (an oppositional purchaser/supplier relationship). Obviously, we prefer the former.
Caution is warranted when giving authority: authority is dangerous. It can be misused and destroy an initiative or organization. Leaders who give authority to others need to practice Gemba walking or its virtual equivalent and watch closely. Culture surveys can also be a way to reveal if there are problems with the misuse of authority.
The Core of Agility: Expediting Cross-Cutting Issues
Issues often span multiple domains. For example, an issue that arises might be technical, but it might also have cost implications, or manufacturability implications, or affect usability. It is also often the case that an issue affects multiple products, perhaps even in different business areas. In those cases, the issue domain is not clear-cut: it straddles multiple domains—technical, manufacturing, and product feature, and possibly business area.
The traditional hierarchical approach to dealing with cross-cutting issues is to allow them to “bubble up” to a review board or an executive committee that meets on a calendar basis. That is too slow today: we need issues to be resolved right away. The only way to achieve that is to make sure that there is a culture of proactive leadership that is always watching for issues and bringing together “the right people” as soon as possible to get the issue resolved—bypassing process and hierarchy.
The way to have a culture that behaves that way is to create a Constructive Culture, and establish the pro-active behavior by demonstrating it. The culture needs to be Constructive, so that people are willing to take the risks inherent in deciding who to include and making a quick decision. And they need to be confident that such an approach is approved of, by seeing their own leaders demonstrate it. That is a core Agile 2 behavior and our Agile 2 leadership training and coaching have a strong focus on it.
A Participative Leader Is Not a Micromanager
In an article in CIO magazine, CIO Dave Mangot points out that leaders need to focus on the value stream to identify bottlenecks and remove dependencies. But to remove dependencies, one must understand the dependencies: how can you decouple two things if you don’t understand them? And granted, you could challenge your teams to do the decoupling, but what if they say they don’t know how to? Do you give up? If you understand the work, you can start to ask hard questions that probe the issue. So you do need to understand the work.
Asking people about their status is not micromanaging or intrusive if you do it in an inquisitive way. If they feel they can be honest, then they are happy to share. And if they have experienced dialectic discussion with you, then they welcome your questions: they can expect an nonthreatening intellectual dialog about the situation.
In fact, practicing Gemba walking requires that you ask questions. And to know what is really happening in your teams you have to ask about the work. Simply watching for flow bottlenecks is no better than a manager sitting in their office reading status reports.
Good leaders want to know what the status is, and why, and how the work is being done; but they ask in a helpful way, and they don’t impose their solution unless they feel it is very important to do so, and even then they explain themselves and they own their decision.
A Key Role for a Leader Is to Orchestrate Collaboration
A key element of transformational leadership is stimulating collaboration on issues. This is extremely important for teams that deal with complex issues.
Deciding how to orchestrate collaboration is crucial. Bringing everyone into a large meeting right off the bat is usually not effective if people have not yet had time to mentally process the issue. In face-to-face meetings, people who think deeply before responding are at a disadvantage. Everyone needs a voice—a chance to be heard—but not all at the same time. We discuss the hard problem of how to orchestrate effective collaboration in the article Orchestrating Collaboration. That is also an Agile 2 core leadership behavior and is taught in our training and coaching.
We are talking about leadership in the context of collaboration. There usually needs to be someone who “owns” an issue, to drive to toward resolution. Otherwise, it suffers from the “tragedy of the commons”. It is not on anyone’s personal to-do list, and so it goes to the bottom of everyone’s.
That’s why an important element of leadership is shepherding an issue toward expeditious resolution, perhaps even making a decision autocratically when time is paramount or if doing so relieves others so that they can focus on their work. Again, what matters is how you do it: if a leader makes a decision, people want to feel that their input was valued and that they will not be held responsible for a decision that they did not make.
Diagnostic versus Dialogic Leadership
Leaders can use a diagnostic or a dialogic approach for transformation. A diagnostic approach consists of diagnosing the cause of a problem, determining the remedy, and then prescribing the implementation of the remedy. This can be done in a collaborative way.
In contrast, a dialogic approach consists of describing the problem to the organization’s members and challenging them to solve it. This is done by setting the stage for people to share stories about how the problem manifests, and supporting emergent efforts to collaborate about solutions.
The diagnostic approach appears to be deterministic: the solution path is defined and then “rolled out”. In actuality, however, such roll-outs often fail, and so the determinism can be an illusion.
The dialogic approach is entirely non-deterministic: it relies on the emergent initiative and conversations that occur among the organization’s members, and so there is no telling where it will lead. However, by participating in those conversations, leaders can make sure that people stay focused on the organization’s objectives.
Combining diagnostic and dialogic approaches is very effective. For example, one can use traditional information gathering and analysis to diagnose issues, and then use dialogic methods to help people to conceptualize solutions, and also refine the solutions, mixing in diagnostic tools and techniques along the way. That is the approach that we recommend.
Create Systems that Naturally Select the Right Leaders
Some leaders emerge organically from a group. However, there is no evidence that good leaders emerge. Some of the worst leaders in history emerged “organically”. Emergent leadership also tends to be a filter, selecting the most outspoken and politically astute people, rather than those who have the most positive leadership style. So emergent leadership is not a solution to the problem of how to have good leadership.
When creating a new initiative, the challenge is how to create a system in which the right people will end up leading. We call creating such a system “engineering the leadership”. Below we provide some guidance on achieving this.
Kicking Off an Initiative
Whenever a team is formed, the people forming the team must take responsibility for ensuring that the team has good leadership. Consider the case of the IBM PC project, cited in the 1986 paper, The New New Product Development Game, often cited as the seminal paper that mentioned “Scrum” in the context of product development. The paper references the IBM PC project:
“Except for quarterly corporate reviews, headquarters in Armonk, New York allowed the Boca Raton group to operate on its own.”
But what the paper leaves out is that Bill Lowe, the lab director in IBM's Boca Raton, Fla., facilities,
“picked a group of 12 strategists who worked around the clock to hammer out a plan for hardware, software, manufacturing setup and sales strategy. It was so well-conceived that the basic strategy remained unaltered throughout the product cycle.
“Don Estridge, acting lab director at the time, volunteered to head the project. Joe Bauman, plant manager for the Boca Raton site, offered manufacturing help. Mel Hallerman, who was working on the IBM Series/1, stepped forward with his software knowledge and was brought in as chief programmer. And so it went. As word spread about what was going on, talent and expertise were drawn in.” [ref]
It is clear that Bill Lowe put a lot of thought into the leadership of the team. He hand-picked seasoned people and they worked together to define a set of strategies at the outset, and there was clear intention about what kinds of expertise and leadership was needed.
Identify the Domains of Leadership
In any initiative, there are a range of different issues that arise. The various categories of issues that you expect will arise are the domains in which leadership will be needed. A discussion of common leadership domains for digital development are discussed in “Common Leadership Domains” in the panel on the right.
Identify the kinds of issues are likely to arise. Will there be technical issues? Product feature and usability issues? Manufacturing issues? Marketability issues? Compatibility issues?
The most common domains of issues often benefit from having designated leaders who oversee resolution of those kinds of issues, hopefully using positive leadership styles.
Deciding on the optimal domains of leadership is not always obvious. For digital development, some common domains are the product’s technology, development methods (e.g., “DevOps”), data architecture, the team’s work priorities, staff professional development, and often others.
Deciding which domains to establish as permanent is an aspect of Organization Design.
Identify the Styles of Leadership Needed
A separate issue is the styles of leadership that are needed. People who are domain experts are not always good leaders. A good leader is someone who enables everyone to contribute their best work. That usually means that everyone feels empowered, heard, and enthusiastic. Many leadership styles are needed to achieve that in a team. Please read about Path-Goal Theory and the other leadership models and styles in the right panel.
In product development initiatives, it is important to tap people’s creative energy. Product development is not task work: it is creative work. As Daniel Pink has pointed out, people need to feel a sense of autonomy about how they do their work, they need to feel that they are good at their job and recognized as such—in other words, respected—and they need to feel a sense of purpose. The purpose can be internal or external: that is, it can be about their own career goals or it can be about a larger vision to help others or achieve something bigger than them.
Leaders usually can create an environment in which people experience these motivators are the ones who you want to empower. But such people might not be enough: for product development, you also want people who ask hard questions: “How is all this going to work? What are the things that might go wrong? How will all these things fit together?”
Designing a team requires making sure that these kinds of leadership are occurring. You can pick individuals, or you can observe and see if the needed leadership styles emerge. Or you can bring in people from the outside who have known leadership styles. However you do it, these leadership styles need to be present.
A challenge is that in a self-organizing group, leaders will emerge, but they might not be leaders with the desired traits. It is essential that the people who end up leading be people who have positive leadership traits and not negative ones. There is a strong tendency for an inner circle to form, and that can kill the enthusiasm that some people have for their work, and also lead to them feeling that they are not heard.
Picking Decision-Makers
A team that collaborates well will usually be able to make its own decisions. But sometimes an issue arises that affects other teams, or the issue might have a broader impact. A team might reach out to other teams, but there is a risk that they do not appreciate the full picture, and so they need to know who has responsibility for the overall capability that they are working on. That person or persons might need to have the final say about the issue.
Another situation is when a team is blocked because there is an existing decision that is in their way. The team believes that the decision should be changed. Perhaps it is a resourcing decision—the team merely needs some more resources. Regardless, they need to know who can hear their concerns, and then advocate for them.
This is why accountability and authority are important: authority is healthy when it is not used to bully or micromanage people, but rather when it is used to represent or advocate for people. Authority lends standing: you are the point person for an initiative or team. You can negotiate on their behalf. And you make the final decision if an issue cannot be decided quickly through consensus.
Having a point person who has final say is important for quickly resolving issues as they arise. Imagine that a team designing a part discovers that the part will not work well when the system is used in a certain way. The team believes that they need to change the part, but to change it, they require another part to change. That other part is used by several other assemblies, maintained by several other teams.
The team reaches out to two of those other teams and they agree that the change will likely work, but they are not sure. Do they make the change? The change will impact many teams.
Left to themselves, they are unsure what to do. Debates might continue for days—a decision is needed. This is a situation in which a manager can quickly resolve this by making a decision. It requires reaching out to other managers to get their agreement to share the risk, and them making a decision to try the change, or not. In a healthy environment the risk is accepted and is not used later against people. A timely decision enables everyone to move on and do the experiment to see if it works.
This approach is highly agile because reaction was quick. No one was blocked. A fully risk-free choice was not asked for: people were willing to try something that was uncertain. Work moved forward. Everyone contributed. Learning occurred.
What makes it agile and healthy is not the structure, but the behavior of people. That is why leadership style and organizational culture are so essential for agility.
Learn More About Leadership:
Path-Goal Theory
Proposes that a manager’s job consists of guiding team members to choose the best paths to reach their goals, as well as the organizational goals. Argues that leaders will have to engage in different types of leadership behavior depending on the nature and the demands of a particular situation. The four behavior types defined are achievement-oriented, directive, participative, and supportive.
Leader-Member Exchange (LMX) Theory
Proposes that in a group, an “inner circle” forms around an emergent leader. Proposes ways to expand the inner circle to increase everyone’s participation.
The Transformational Leadership Style
Defined by James MacGregor Burns, this model describes leaders who give team members autonomy over specific jobs, as well as the authority to make decisions once they have been trained. Transformational leaders typically perform four distinct behaviors, also known as the four I's. These behaviors are inspirational motivation, idealized influence, intellectual stimulation, individualized consideration.
Theory X, Theory Y
Defined by Douglas McGregor, “Theory X” describes a management approach in which workers are assumed to be mercenary in their approach to their work, and can be motivated only through transactional methods such as incentives and punishment.
“Theory Y” describes an opposite approach in which workers are assumed to be internally motivated, and that the best way to improve performance is by supporting them.
McGregor’s goal was not to advocate for strictly one approach over the other, but rather to contrast them by providing a model for thinking about leadership behavior. On the other hand, McGregor believed that people are most fulfilled and therefore most motivated when they are most self-actualized; that is, when they are able to reach their full potential.
The Socratic Leadership Style
When a leader engages in Socratic questioning, in order to help a team to learn or discuss a complex issue.
Hersey-Blanchard Situational Model
Defines four leadership styles appropriate for situations characterized by two dimensions: a person’s professional maturity, and their “performance readiness” (commitment to the work).
Other Leadership Styles
Some other important leadership models and styles are briefly examined, including authentic leadership, adaptive leadership, and servant leadership.
Leadership Direction
A leader can be inwardly focused on a team (or organization), or outwardly focused on how others in the environment perceive or interact with a team (or organization). Peter Drucker referred to these as an “inside person” and an “outside person” respectively. (See this Sloan article)
Autonomy, Self-Management, and Leadership
Common Leadership Domains
Tech leadership - The stuff a product is made of
Delivery leadership - How we make the product or deliver the service
Business model leadership - How we derive value from doing this
Product design leadership - When B2C, need product exploration - how we figure out what users need
Security or risk-related leadership - Expertise related to high-risk aspects of the work
Some Ways to Reduce Competition Among Leaders
Shared initiatives, and shared credit, and situations in which no one wins unless everyone wins.
Remuneration is mostly based on collective performance, and somewhat based on individual learning and improvement - but never on “one’s numbers”.
Promoting people who are innately not power-seeking or credit-seeking. (Leaders need to know how to discern that, and be in a position to observe.)
Training and awareness of behavior and leadership styles, so that leaders have expertise in observing real behavior versus performance behavior.
Move people around.
Dashboard culture. Deep discussions.
Give initiatives budget—not functions—and each initiative has shared leadership.
Some Examples
[Coming soon]
A cutting edge biotech product
A core microservices team
A financial services product
Quick Links
Identify the optimal sequence of capabilities to demonstrate or release
Identify key intersection points, critical paths, and integration strategies
Decompose each capability into a set of features to be concurrently developed
Start test marketing them as MVPs are produced, and feed results back to adjust visions