A leader is someone who leads, someone who guides. Technically it means the leader knows what to do, and gets others to help scale up. In physical terms, it means the leader has almost literally grown to direct more arms, more legs, more heads, and can tackle larger tasks.
But what does this mean exactly? How does a leader get to this point of growth and scale? Ideally, it means the leader has been doing precisely what needs to be done already. As they practice the task repeatedly, they build up the expertise necessary to consolidate and explain the goal, the particulars, and the process of becoming an expert. They know what to do. As for the second part, they need to get others to help them in this task.
Therein is the tricky part.
How exactly does a leader attract, train, retain, motivate, and coordinate entire thinking, behaving beings into a team? Every workplace with employees deals with this question everyday. Most struggle with this very issue. It is with this in mind we that use Scrum as a jump-on-in management example to explore the challenges.
Scrum (Takeuchi and Nonaka, 1986) is a form of decentralized management filed under agile development and work processes. Other related examples include Kanban and lean development. While these agile development approaches had their origins in computer programming development and engineering, they have since rightly come to potentially signify management structures in general.
The basic premise of Scrum, as stated by one of the co-founders (Sutherland, 2014) who refined it to today's standard is to improve labor efficiency by removing bottlenecks, or obstacles, that may be present in inefficient management structures. The classic case of inefficiency is one in which the business division (i.e. the leader) dictates a task, the development and engineering team (i.e. the other helpers) start to plan and build the technology, whereupon the business seemingly changes the task, which causes the development and engineering team to need to either corrupt the technology through re-work or to restart entirely. This leads to an end product that is over-budget, delayed, and fails to match the business task entirely. The isolated cause: poor leadership and the inability for helpers to convince leadership of their ability to help.
Scrum is developer-team-oriented, with small units of 7-9 programmers quickly and iteratively producing working prototypes within 2-4 week cycles called sprints. This provides a series of signed-off check points with the business leaders with full feedback external to the developer team. Internally to the developer team, all members are equal, consensus driven, and with ritualized communications. The inspiration appears to come from a sports Rugby scrum, whereby all players coordinate by calling out, "I got this ball here" or "I am open, pass to me!" The end result is that the helpers are decentralized, connected, and self-organizing. Like a Rugby scrum, the team almost literally has 7-9 sets of arms and legs. And the business leaders cannot blame the helpers since they have fair warning with high speed, iterative and cyclic "sprint" prototypes. The prototypes speak for themselves. This should assist with developer morale, retention, robustness through less dependence on top-down guidance, and above all, speed and agility to accomplish specific short term business milestones before they can change.
Cho, Kim, and Olsen (2006) performed a case study and analysis on the workings of Scrum. The theory behind its efficiencies of team-driven decentralization include social facilitation (team members combine to speed up simple, straightforward tasks) and group motivation (team members are happy to share and help other members). The theoretical risks in team-driven decentralization include social loafing (members may underperform and blame the team). Their empirical findings include that development error rates initially increased upon adopting Scrum, then later returned to baseline. Development time and costs increased initially, then reduced to below baseline. Their conclusions indicate that Scrum can assist overall on simple projects. However, the cyclic sprints may emphasize quick-fix "good enough" solutions that make strategic depth more difficult to achieve. Also, the distribution of developers into smaller, more agile teams increases the risk of team overlaps and redundancies since there is less overall coordination between teams on a larger scale.
In addition, the physical manifestation of Scrum where employees are mobile and share communal spaces could lead to employees being "...constantly distracted by cubicle partners who are often having conversations with other coworkers. An interesting field study shows that teams are more productive when their members work independently (Parrish, Smith, Hale, and Hale, 2004). Further, it may not be a good idea to have developers run the team without having a team leader (Marrington at el, 2005) to make a right decision in a timely manner when team members do not know which way to take among several alternatives." (Cho, Kim, and Olsen, 2006).
In other words, there is no single best - and by extension, no single worst - development or management technique. Each company hoping to scale up leaders with helpers may need to find specific solutions tailored to their particular needs and resources. There is no one size fits all. Scrum delivers as expected. But so can additional management approaches.
The question remains: what does this mean? Is there any answer at all that sheds some light as to how a leader can get helpers to scale up? And why does Scrum seem so promising?
To answer the first, Scrum and its Agile compatriots, including Kanban and lean development systems, originate in the 1970s-1980s and predominantly appear to have Japanese roots. Sutherland (2014) repeatedly points to Toyota manufacturing practices from the same time period. For those old enough to recall, the 1970s-1980s was the time of the Japanese economic miracle, where Japan showed double digit sustained growth and was on track to out-produce and buy out US firms and properties wholesale. Sushi became popular and business schools were restructuring to understand and teach the Japanese way of business. Hollywood movies even portrayed a future or present driven by Japanese corporations (e.g. Bladerunner, Die Hard). Scrum, Agile, Kanban, and others added a "coolness" factor back to development with a touch of the mysterious and exotic. The consensus-driven, group behavioral, swarming, hive mind-like process is as different from the standard rigid, requirements-gathering and analysis-driven process as it gets.
But this answer also sheds light on a framework answer to how leaders can attract and connect to motivated helpers. Namely, and obvious in hindsight, interpersonal cultural factors affect interpersonal group and team relations. In short, if Scrum, Agile, Kanban, and lean manufacturing appear to originate from Japan, then it may fit personnel with traits similar to those appearing in Japan very well. For those employee pools with different cultural backgrounds, perhaps other management approaches may fit better.
Martinsons and Davidson (2007) study management practice across different cultures, including US and Japan. Highlights include PowerDistance score differentials. PowerDistance indicates relative levels of expected top-down authority. Higher scores imply that subordinates do not actively take part in decision processes. Lower scores imply a more democratic approach. Unsurprisingly, Japan showed higher levels than did US. Individualism scores indicate levels of self-interest and the extent to which employees are driven by objective analysis, even at the cost of group harmony. US showed by far the highest levels, with Japan showing much lower scores. The conclusion is that Japan is more collective, consensus, and institutional collectivism driven (i.e. company first). Japan uses more people in decision making, which is slower at first. But once reaching consensus, it is smoother and faster to implement. This aptly describes the target Scrum process and its effects above re: Cho, Kim, and Olsen (2006). US by contrast encourages individual performance, ongoing objective analysis, and the need to conceptualize solutions. This requires a structured and formalized decision process. Again, there is no one size fits all. There is only connecting leaders with helpers in whichever manner the leaders and helpers are comfortable.
Taking it further, finding and getting the right mix of helpers to connect with the leader may require not only high level regional awareness, but also drilled down individual personality awareness. Sutherland talks several times about NASA and its engineering helpers. This brings to mind a story related by Christopher Steiner in his book, Automate This. NASA needed to pack three people into a space capsule the size of a closet. This is the extreme case of team management. Everyone works together or they fail. There is no division between leaders and the developers/helpers. A mutiny in an enclosed space capsule does not mean someone resigns, or the project gets an obstacle or delays. The stakes are high. Steiner relates the story:
"On one particular [Soviet] mission, it became clear that the two men were not getting along. The men's daily space tasks included taking blood samples from their partner. Halfway into the trip, one of the [Cosmonauts] purposefully drove the needle so hard into the other's hand that it pierced the bone..." To prevent the first ever space homicide, the controllers aborted the mission. According to Terry McGuire, NASA's chief psychiatrist, NASA had similar close calls with poor management and teamwork in space.
Working with Taibi Kahler, NASA adopted personality screening and matching. The work divides people into 6 broad categories:
Emotions-based people
Thoughts-based people
Actions-based people
Reflections-based people
Opinions-based people
Reactions-based people
Reading people correctly and placing them in teams of complementary categories helps greatly in allowing them to connect and to play to each others' strengths.
Management is a nuanced art. That is the tricky part. At its core, it is simply having an expert (the leader) connect with helpers (the team) to achieve growth and scale. But the dividing boundaries of what can and cannot be "chunked" into smaller, iterative bites is fluid and dynamic. Setting the team against the leader, or setting the team against itself, or setting Scrum vs lean vs Kanban vs [insert choice of management style here] may or may not be appropriate. That would be as fruitful as stating that the Japanese teams are so efficient, and they eat sushi, so we should get some of that sushi too.
A better approach may include a holistic approach that at least considers multiple scales, from the small picture to the big picture. From the individual, to the group, to the culture, and not least - the overall goal. At the end of the day, everyone from leader to helper has the same goal in mind. The goal's descriptions may shift and it may be implied rather than immutably stated. In a nutshell, the secret to good management is the same as the secret to good parenting. At the end of the day, whatever the path, we are developing tomorrow's leaders by showing them what we did to become a leader.