Book summary: The Jazz Process (IV)

This is the fourth (and last) part of my summary of “The Jazz Process” by Adrian Cho. See also parts one, two and three in this blog. This part will cover the rest of “Executing” and “Innovating”.

Executing: stay healthy

It’s often necessary to build instability to enable high performance (e.g. talented people with troubled personalities). The trick is managing instability so it doesn’t turn into unrecoverable or damaging situations.

Poor health has an effect on people’s impression and can create a positive feedback loop. If someone was hurting you or another person, you would tell them to stop immediately. That’s the reaction people inside a team should have. To stop a positive loop, do everything you can to stop the actions causing the loop; to stop hunting, increase the speed of reaction or increase friction by slowing down and relaxing.

On measuring health: compromised team stability/integrity or poor performance as a result of mistakes or failures indicates problems. It should be possible to create a useful measure of general health for any activity or system. E.g.: number of unresolved defects, number of  incomplete features, performance test results, etc. The problem with those reports is that they can be misused or misinterpreted, esp. if reduced to a traffic light-style of health. It’s important to take a strategic view and ensure that problems, not symptoms, are addressed.

Innovating: exchange ideas

Joy Paul Guilford, American psychologist, defined two types of thinking: convergent (associated to math/science: find a single solution to a problem) and divergent (arts, generating many possible solutions to a problem). The latter, Guilford associated to four skills: fluency (quickly produce large number of solutions), flexibility (simultaneously consider many solutions to the same problem), originality (produce solutions others haven’t thought of), elaboration (adding to/developing existing solutions).

Diversity can improve the success of innovation, either by producing more initial good ideas or by rejecting the poor ones at the end. Collaboration improves the success of innovation by leveraging free exchange of ideas. This is not always easy to achieve: it’s not a free-for-all or selecting what’s the best idea, it’s creating a common pool by listening, respecting, suspending and voicing (see William Isaacs and p.244).

Innovation is enabled by risk-taking, collaboration, diversity and exchange of ideas. Now, how do you create a culture of innovation? First, people must feel there’s room for it (not have all time committed to things that absolutely must be done). People often feel they don’t have the time or freedom (Google’s 20% time and such). They also must feel there’s room for mistakes.

I'm so glad you made this mistake. Because I want to run a company where we are moving too quickly and doing too much, not being too cautious and doing too little. If we don't have any of these mistakes, we're just not taking enough risk. > > Larry Page > >

Also important is to allow/encourage people to form groups for those things and work in whatever they want: top-heavy approaches can stifle innovation, especially if execs aren’t tuned in or don’t have the time and become a bottleneck.

Innovating: take measured risks

Basic options for risk management: avoid, transfer, share, reduce/mitigate, accept, ignore, exploit. Perils of not enough diversity: one study found that across the entire universe of patients, the single largest indicator of treatment wasn’t symptoms or background, but the doctor’s background.

Specific risks of the jazz process principles:

• Use enough rules. Removing the wrong rules. Some rules guard against mistakes: in that case, compensate with skills or experience.

• Employ top talent. Excessive individualism. Also, depending on highly talented people can be a problem if they leave. Another problem is overconfidence (top talent doesn’t guarantee victory). Finally, not using them wisely (ie. using them for routine tasks).

• Putting the team first. Suffocating individualism, and amplifying bad behaviour/thinking (groupthink and polarisation).

• Build trust and respect. Trust must be measured and not be blind (the need is proportional to the risk of the trust being misplaced). Always exercise caution and don’t be afraid to question things.

• Leading on demand. Leadership should be granted to people who understand (and will keep) team stability. Also, define protocols for delegating, transferring and initiating leadership. Another risk is that no one will lead: have a default leader.

• Act transparently. Early designs might put people off if they’re too early, and they might not give it a second chance. Transparency can be damaging, annoying or boring if it’s about the wrong things.

• Make contributions count. The only real risk is being too reserved and contributing less.

• Reduce friction. It may restrict performance (e.g. you could minimise social friction by repressing all dissenting opinions). It may be tempting to remove things causing friction, but it might be a bad idea: those things might have benefits, so it might be possible to reduce friction without eliminating them.

• Stay healthy. The only risk is accepting too much outside help, or too quickly.

• Exchange ideas. Focus might be lost, innovation attempts should be directed. When they are directed, the primary concern is introducing instability.

Final comments

“The Jazz Process” is a very good book, recommended to anyone interested in how groups of people can achieve high performance in any activity. It also has many jazz references, which make the book even more interesting if you’re into jazz. If I had to say something bad about the book, I’d say that it could be easier to skim if you just want to get information from it (it’s written to be read from beginning to end, it seems). Of course, if you want to read it the “traditional way” it’s probably an advantage, because it’s fun reading about jazz and other fields and it makes the reading flow better.

• books
• jazz
• management
• project
• teams

Book summary: The Jazz Process (III)

This is the third part of my summary of the book “The Jazz Process” by Adrian Cho. You can read parts one and two on this blog. This part will cover the rest of “Collaborating” and part of “Executing”.

Collaborating: lead on demand

Two surprising things about leadership: no widespread agreement for the definition and we tend to think it’s the sole responsibility of a small group. The main point in leadership is taking initiative (within your roles or responsibilities). Successful leadership often has a domain, and it’s not valid in others.

Jazz musicians simply cannot let leadership roles remain statically assigned if they want to create interesting, innovative music > > Adrian Cho > >

Blitzkrieg was successful because of decentralised leadership. Strict, centralised leadership inhibits creativity and agility: the path to success lies in giving up control. [However, have a look at the “Controversy” section in Wikipedia—Esteban]

Issuing navigational commands is one of the most vital elements of leadership. Taking the first step along a different path is also critically important, and this duty must be shared. People should feel responsible for helping steer and maintain momentum. If any member of the team has ideas about how to improve performance, she should feel empowered to speak out.

Not everyone can lead at the same time, you have to balance individual creativity and team stability. Alternating between leader and follower helps broaden their perception, which results in better leaders and followers.

Collaborating: act transparently

Transparency in execution reduces the time for others to (1) observe your actions (and increases the likelihood of it happening), and (2) understand/interpret their impact (increasing accuracy of interpretations). Transparency potentially grows teams, communities and customer bases, as we appreciate honesty, openness and authenticity; we feel naturally curious to know what happens behind the scenes; and it can alleviate fears/concerns about the unknown.

Leaders sometimes assume employees will require only certain information. This is somewhat arrogant, and employees often feel they’re left in the dark. It also makes groupthink more likely. Openness makes people understand each other’s problems, important when failures or low performance strike.

A research on plane accidents showed that leaders are far more likely to make mistakes when rushing into action instead of waiting to obtain more information that often can be obtained from other team members. Further research on those results showed that pilots making the right choices routinely had open exchanges with other crew members. Besides, crew members who worked with leaders not promoting open culture were unwilling to intervene in potential accidents even if they had information about it.

Transparency in enabled by authenticity, openness, timeliness and clarity.

Collaborating: make contributions count

Recognising valuable contributions rewards and motivates. To make contributions more valuable, people should measure: (1) effort to make and integrating the contribution (not everyone requires the same effort for the value), (2) value of the contribution (the value of a contribution is a function of many things, including the other contributions), (3) impact of integrating the contribution (never underestimate the impact of integrating a contribution).

Making the most with available resources develops resilience in the team. Striving for perfection should not be above all else: mistakes in sports are common, but defeating your opponent is usually more important than an error-free game.

We have to contribute in a way that makes sense for us individually (examples in p.175). By focusing more on quality than quantity, we can spend more time in the observation phase of OODA. The most fundamental thing is that people listen to others and understand enough about the team’s collective efforts that they can identify and support important contributions. When individuals can measure effort, value and impact, they can time their contributions better.

Executing: reduce friction

Countless minor incidents combine to lower performance. Friction is the force that makes the apparently easy so difficult.

Reducing friction can take long. Instead, lubricants can be used: apologising/accepting blame for a mistake, acknowledging facts, making changes that demonstrate willingness to address a problem, giving credit where its due, downplaying mistakes others make.

Too much friction is bad, but too little is also a problem (can lead to hunting).

Executing: maintain momentum

Critical mass is enough momentum for an activity to be self-sustaining. To reach this state, considerable effort and resources must be placed, esp. if there’s resistance.

The most important element of momentum is regularity. People are drawn to the predictability of regular cycles (see “entrainment”, ie. two or more interacting oscillating systems falling into the same period). There are four elements that leverage people affinity to regular cycles:

• Form: Most activities that require commitment to a goal have a form or structure (examples in p.199). People use the predictability of the form to set goals, time deliveries and shape contributions. It helps coordinate efforts and increase synergy. It’s important to use a form appropriate for the situation (not too many/few checkpoints).

• Tempo: Overall pace. If there are three months to release a feature, but the estimation was six, the team’s ability to adapt depends on their freedom to set their goals (like dropping parts or reducing performance). When setting a tempo, take into account the goals, abilities of individual team members and the flexibility of their processes.

• Pulse: Like a heartbeat. It’s a constant event that drives and helps the team keep in sync with the tempo. It’s always a function of the tempo.

• Groove: A function of the pulse. Set of essential, fundamental activities that are repeated with respect to the pulse (examples in p.207-209). It invites people to participate and align their contributions with it. It’s most effective when simple and clear to everyone.

In software, a project manager may set all four (esp. the first two), and component team leaders define specific grooves inside their own teams.

Looking ahead for potential issues and addressing them before they become problems helps avoiding losing momentum, but strike a balance between planning and reacting. Other advice: (1) add weight to a contribution to give it greater significance, esp. in slower tempos; and (2) prepare an important contribution with a preceding smaller contribution.

And this is all for the third part. The next will be the last one, and will cover the rest of “Executing”, and “Innovating”.

• books
• jazz
• management
• project
• teams

Book summary: The Jazz Process (II)

This is the second part of my summary of the book “The Jazz Process” by Adrian Cho. You can read part one on this blog. This part will cover the rest of “Working” and half of “Collaborating”.

Working: build trust and respect

Trust and respect are binding agents that keep a team together and help it maintain strong and healthy relationships. The mutual dependence that binds a team together requires that each member trust the other members to do their parts. This trust gives them freedom to work, and this freedom is especially important if their approach to a task differs from that of others. When people make great efforts, deliver under bad conditions or excel, they generate respect, and feeling respected makes them correct mistakes and take extra steps for a stand-out work.

The book “The Speed of Trust” explores the idea that trust affects the speed and cost of operations: things move faster and costs are lower. In activities where time can be sacrificed, there are delays (and often increased costs). When time is fixed, quality may suffer.

One way to build trust is with transparency, indicating intentions and actions clearly. Trust and respect can only be built with genuine, uncompromised communication. People can’t trust if they don’t know the person or its contributions to the team, and they’re less likely to trust the team if they don’t know how it’s going. For the latter, collecting metrics is useful, but they aren’t enough for themselves for building trust and respect, so personal messages are needed too. And those have to be genuine: company-wide broadcasts are often ignored. Being straight and direct (Warren Buffet examples on p.64,65) is important. Don’t try to make the company look good or hide mistakes.

Building trust and respect is hard, but losing it is easy. To avoid losing it or to restore it, accept accountability for mistakes and make it a priority to correct them whenever possible. Failing to do so may make the problem bigger. When mistakes are unavoidable, communicate the circumstances clearly to all parties. Accepting responsibility is not just apologising, you must acknowledge your understanding of the problem and you role in it. The worst kind of mistake is when the person making it doesn’t realise or (even worse) pretends it didn’t happen.

Working: commit with passion

Companies wonder why their employees aren’t more committed, when they should wonder what they can do to achieve a higher level of commitment from their employees. Top-talented people often have strong motivation. One has to try not to undermine that motivation. Nobody likes to work for an underperforming team or a failing project. It’s easy to contribute when there’s high level of activity. If you make a mistake, you have the team to back you up (examples in p.73).

Often companies use artificial means to motivate employees: team-building and inspirational speeches. They may help in short-term but not solve underlying problems in a team. Actually they may frustrate people.

Essentials of execution (Intro to Collaborating)

Feedback loop is the process in which part of output is fed to the input. A positive feedback loop is self-reinforcing or synergistic. Another interesting phenomenon is “hunting” (oscillating indefinitely when trying to correct a mistake):

• Hunting case 1: trying too hard. Being nervous or overconcentrated in a goal causes us to fail, because of overzealous correction. Solution: back off, relax, avoiding trying too hard.

• Hunting case 2: reacting too slowly. When we take too long to react to feedback. When we react, the correction is not enough or valid.

The OODA loop was conceived by fighter pilot John Boyd: Observe (get data), Orient (analyse/synthesise it), Decide (determine course of action), Act (implement decision). He was convinced that success in dogfights came from superior decisions and executing them more quickly: the pilot that goes through OODA in the shortest time wins.

Blitzkrieg gave unit commanders more autonomy, improving agility. Instead of waiting for explicit orders, they knew the strategic intents and could use their creativity and initiative.

Collaborating: listen for change

The aim of observing is getting relevant data for decisions, and it begins with unimpeded field of view. We tend to limit ourselves (tunnel vision), must work on peripheral vision: beginning with the end in mind (example in p.105,106). To improve execution, expand your field of data, but learn how to filter the noise. Considerations for observing:

1. Cognitive biases. We see what we want to see (confirmation bias), avoid/discount information that contradicts our ideas (disconfirmation bias), pretend not to see things we rather not see (selection bias), interpret information to suit our needs (assimilation bias), take decisions based on previous experience that we don’t recall correctly (selective memory). These biases often result from cognitive dissonance, and aren’t only for individuals: groups can polarise (making more extreme decisions).

2. Thinking outside the box. We are encouraged to expect the unexpected: that is really about being agile enough to respond to unexpected problems.

One of the most important pieces of info in any situation is a score, a measure of how well you’re doing. Successful teams need to know how they’re doing, but beware of management by numbers (they should never be the only input for decision-making). The most important figures for management are unknown or unknowable. For a score to be useful, it must be consistent over time, everyone must agree that the score is useful and fair, limitations/caveats in it must be well documented, and the team must understand the relation between their efforts and the score.

Paths that lead to success change over time, keeping the same path is not good long-term.

And that’s it for now. Next part will cover the rest of “Collaborating” and part of “Executing”.

• books
• jazz
• management
• project
• teams

Book summary: The Jazz Process (I)

This is the first part of my summary of the book “The Jazz Process” by Adrian Cho (official website, Goodreads page), about high-performance teams. EDIT: see parts two, three and four. It has examples and stories from jazz, basketball, the military, and others. The book is divided into five sections: introduction, working, collaborating, executing and innovating. Each section except the introduction has a series of “rules” that comprise the Jazz process.

This first part of the summary will cover the introduction and the first half of “Working”. Also, as this book has so many interesting quotes, I’m going to use some of them in this summary. They’re not part of the summary strictly speaking, so you can just skip them if you want.

Introduction

I used to think that running an organisation was equivalent to conducting a symphony orchestra. But I don't think that's quite it; it's more like jazz. There is more improvisation. Someone once wrote that the sound of surprise is jazz, and if there's one thing that we must try to get used to in this world, it's surprise and the unexpected. In this world of chaos, there's no other way of doing things. Truly, we are living in a world where the only thing that's constant is change. > > Warren Bennis > >

The model of management that we have right now is the opera. The conductor of the opera has a very large number of different groups that he has to pull together. The soloists, the chorus, the ballet, the orchestra, all have to come together—but they have a common score. What we are increasingly talking about today are diversified groups that have to write the score while they perform. What you need now is a good jazz group. > > Peter Drucker > >

People miss two things about jazz improvisation: it’s based on years of training and experience (it’s not just “making things up”) and the greater goal is to create something unique (innovate). This quest for innovation is always balanced against their responsibilities, like supporting the other musicians. The skill of improvisation should be as highly prized in business as in jazz. More than ever, responding to the unexpected is important.

[Talking about basketball and jazz] the team's performance emerges from a chain reaction of individual acts. So much of what makes jazz great is the unique chemistry among individual players [...] > > R. Keith Sawyer > >

And if you want to have a really good jazz group, how large can it be? [...] You can use seven to nine people—maximum. If you get more, you have to score. > > Peter Drucker > >

Big groups make it hard to express yourself without appearing obviously non-conforming.

Working: use just enough rules

To maximise performance, you need just enough rules to afford autonomy, while avoiding chaos. Autonomy is the independence and freedom that enables people to act individually. It facilitates agility as it limits constraints. Individual expression is essential to improvisation and innovation. The goal when defining a process is allowing the team to be agile and innovative, while addressing the success factors of the team’s business.

Rarely a single set of rules apply equally to every situation and for every person. The exact set of rules or the importance of each one will vary over time (example in p.25). Thus, process improvement is critical to long-term success.

If there’s a strict rule,  people must have a very good reason to break it. But more important is understanding the implications of doing it: breaking the rule might not be a problem, but not knowing that you’re doing it or not being able to explain the need to do it, probably is. If a rule is consistently broken, maybe it should be a convention instead. If on top of that, breaking it doesn’t cause problems, maybe it should be removed.

Working: employ top talent

Experienced and skilled people can adapt to almost any situation, even in new teams. Established but fundamentally weak teams can be good in a given setting, but in front of the unexpected the weaknesses will be revealed.

Duke Ellington wrote his pieces for concrete players, not for “Trumpet 1” and “Trumpet 2”. Same with Shakespeare. They considered the unique strengths of the performers and wrote parts featuring their greatest talents. The individualism of the musicians, channelled through Duke Ellington is what give greatness and uniqueness to the composition.

Individuality is about self-expression and creativity, but also about playing a unique part without backup. The team is as strong as the weakest link.

One of the most important skills of highly effective people is their ability to allocate a good portion of their personal bandwidth to collaboration. Inventors rarely make discoveries in isolation. The more proficient we are at our routine tasks, the more aware we are of our surroundings.

When building a team, quality over quantity. In lean teams, the problem is that there’s no redundancy, each member is a more critical resource.

Working: put the team first

In jazz, the musicians are accountable not only to the leader of the group, but to every person in the group and to the ensemble as a whole > > Adrian Cho > >

When a team has many strong individuals, each with distinctly specialised skills and experience, cross-fertilisation among individuals can unify the team. Special forces team members usually have a core speciality, but everyone in the team knows something about everyone else’s expertise. It’s the job of each specialist to conduct the training. This approach can both generate respect between team members and build redundancy that increases the robustness of the team.

The ability of every individual in the team to put the team first is often tested in a time of crisis (examples in p.50). The ability to absorb mistakes is one of the most important capabilities of an effective team: it succeeds and takes credit together, or fails and takes the blame together. No group ever becomes a team until it can hold itself accountable as a team. Another way to demonstrate cohesiveness is through willingness to tackle a challenge or traverse a risky path.

One potential problem of putting the team first is groupthink: abandoning individual creativity and critical thinking. The team may thus fail to innovate. This may be exacerbated by the tendency to self-select like-minded people and get rid of those who don’t think like the team. Ensure that people always feel empowered to speak out.

It's the group sound that's important, even when you're playing a solo. You not only have to know your own instrument, you must know the others and how to back them up at all times. That's jazz. > > Oscar Peterson > >

Focusing on the team helps people recognise the value of everyone’s contributions. It’s important that leaders and stars that get the praise acknowledge the contributions of colleagues. Acknowledging everyday heroes builds trust and empowers every member of the team to achieve higher levels of performance.

When a high-performance team exists within larger teams or organisations that are less productive, there’s the danger of tension. Putting the team first is not just for the immediate team, but for the larger organisation.

Nobody in the SAS [Special Air Service] looks down on any other unit of the army as being less important; no regiment in the entire army is so well aware of the essential attributes of what are often dismissed contemptuously as "administrative" troops. The SAS man, the fighting soldier par excellence, suffers from no delusions about his own importance. He knows his role is vital but he knows that a cipher clerk, or a cartographer, or even the skill of the opposing general's cook, may in fact be more important to the success of the campaign than quite a number of daring soldiers. > > Philip Warner > >

• books
• jazz
• management
• project
• teams

Book review: "97 Things Every Project Manager Should Know"

In the last batch of books I ordered from The Book Depository I had “97 Things Every Project Manager Should Know”. It was a thin book and one of the first to arrive, so I figured it was a good one to start. The book is a collection of 2-page articles about project management. It has 198 pages, but I just read until around page 70, then “speed-read” the rest because I was so disappointed that I just wanted to get it over with. This has been the most disappointing book I’ve read in many years, and I rarely stop reading books even if I don’t like them that much (especially if they are as short as this one).

But I hate not trying to be constructive, and just saying that it was disappointing for me won’t tell you much about the possibility of it being disappointing for you, so here we go:

• The choice of articles seemed “random”: clearly some of the authors had very good things to share, but many others didn’t sound that experienced or having so much interesting to say. I could imagine myself writing some of those articles.

• Many articles read like they want to give “general” advice, but extrapolating from circumstances that I may never have (like making a rule out of a “this happened to me once” kind of experience).

• I didn’t find it “inspiring” at all, if I wasn’t a project manager already I would not want to become one. The idea of working as a project manager felt dry, boring, and too focused on processes.

• Many articles feel written for someone that doesn’t have any project management experience whatsoever. That’s cool, but it’s useless for me and should have been clearer in the book I think.

• Many other articles seem written for project managers from other industries (or even simply “managers”) that are going to start managing a software project. That is not only plain useless to me, it also bores me to death. Seriously, WTF is with the definitions of super basic concepts? If you don’t know what an “iteration” or a “hack” is and you won’t check yourself out of curiosity you shouldn’t be allowed to manage a software project. Period.

• Many articles felt too “corporate” to me, there was too much jargon and too many references to job titles, methodologies and contractors instead of really essential stuff based on experience.

• Reading some of the more or less interesting stuff, I couldn’t help thinking that those things would be obvious for someone who has been working as a software developer for years and wants to become a project manager because she finds it interesting.

• Other articles were interesting, but lacked depth to make them really useful.

Don’t get me wrong, there are useful articles, but the book as a whole doesn’t feel that useful. Certainly not worth the time reading the whole thing.

And finally, something that kept popping in my head, even if the comparison is unfair (it’s a different kind of book), is that this book is in many respects the opposite of the things I loved about Making Things Happen (an excellent book that you should read if you have any interest in project management). Oh well.

• book
• book depository
• books
• management
• project
• rants
• review

Playing around with jQuery

A couple of weeks ago I started a new pet project. Namely, making the ultimate todo list application. The idea was to:

• Make a TODO application that I actually like (I’ll post about it some other day).

• Learn Merb and DataMapper… and jQuery.

The experience have been roughly half frustrating, half rewarding. It’s fun learning new things, but the documentation for both Merb and DataMapper sucks big time so sometimes I spend much more time than I would like figuring out how to make things work. Don’t get me wrong, the reference documentation looks very complete… but there’s no single source of consistent documentation to learn how things are done. And that’s painful. Moreover, apparenly the API has changed several times (at least before 1.0.0, but it hasn’t been that long since), so a lot of recipes or solutions you find on the internet are simply not valid anymore, which just adds up to the confusion and frustration.

Anyway. The client-side piece of the puzzle, jQuery, has proven to be a very handy, clean, easy-to-use-even-for-non-Javascript-wizards, natural way of writing Javascript. I admit I’m a kind of Javascript-phobe, as I don’t really know more than the basics and never has had the need or inclination to actually learn the language (yeah, my bad, but whatever). And yet, I really like jQuery, so there has to be something there. My favourite feature is the selectors: they’re a very clean way to access elements in a page, and add event handlers or otherwise manipulate them. Also the jQuery Ajax features feel really natural and comfortable to use.

The only problem I have had was using the autocomplete jQuery UI feature. I read the documentation, downloaded the appropriate bits from the jQuery website, included everything in my application, but it just wouldn’t work. After a lot of trial and error (and more frustration), I finally could make it work… using the Javascript files from the demo page (js, css) instead of the latest version from the jQuery download page. I think the problem is that the API has changed (the API apparently documents the older version that they use in the demo page), but I couldn’t figure it out reading the source code, so I just used the older, known-to-work version.

• application
• datamapper
• jquery
• merb
• pet
• project
• todo