“No organisation needs a corporate values statement on the wall. You can tell what the company values by how people behave.”

However, values on their own are not enough. According to Kent Beck

“Values are too abstract to guide behaviour”.

That is why values are often complemented with principles – “a rule or belief governing one’s behaviour”.

Well written, clear and commonly accepted principles can be very effective at guiding behaviour and creating a homogenous and effective team or organisation.

For example, this is how Herb Kelleher (CEO of Southwest airlines) demonstrates the usefulness of clear and actionable principles (quoted after Made To Stick by Chip and Dan Heath)

“Here’s an example,” he said. “Tracy from marketing comes into your office. She says her surveys indicate that the passengers might enjoy a light entree on the Houston to Las Vegas flight. All we offer is peanuts, and she thinks a nice chicken Caesar salad would be popular. What do you say?” The person stammered for a moment, so Kelleher responded: “You say, ‘Tracy, will adding that chicken Caesar salad make us THE low-fare airline from Houston to Las Vegas? Because if it doesn’t help us become the unchallenged low-fare airline, we’re not serving any damn chicken salad.’” Kelleher’s Commander’s Intent is “We are THE low-fare airline.” This is a simple idea, but it is sufficiently useful that it has guided the actions of Southwest’s employees for more than thirty years.

Few organisations go far enough, or care enough, to achieve such clarity and consistency. It’s a pity. But while you might not be able to tackle this at the global level, there is no reason you can’t make it work for the team you’re on.

Diana Larsen and Ainsley Nies in their new book “Liftoff: Launching Agile Teams & Projects” make writing team values and principles part of the chartering exercise in the chartering alignment part.

The process of collaboratively identifying values and principles gives you team a chance to share and explore views about what’s important, and to define the work environment you will create. And when difficult decisions need to be made, you’ll use the principles as guides.

If you decide to give it a go, and I encourage you to so, there is one aspect to consider.

May times I have participated in meetings where we get together, deliberate, discuss and come up with a list of values and principles we display prominently. This often left one issue outstanding – we didn’t really know if they would work or not. The feedback cycle is too long and often gets neglected. We don’t re-visit the list, we don’t check if it all works, we don’t know if it guides our behaviour as we expected.

Instead, you may want to try a different approach. 

Organise a workshop to create your principles together. To make it more effective also prepare a set of realistic scenarios of what may happen in your team or on your project. Things that have happened in the past, things you know may surprise you, situations that require a bold decision to be taken, difficult situations.

For example:

• “a senior manager comes to one member of the team to ask them to work on something very important for a few days”
• “one of the developers keeps breaking the builds although others have already tried to help and explain what he can do to avoid it”
• “you suddenly discover the feature you have promised to deliver to your customer in this iteration is not going to make it”
• “a tester comes to you with some back news – there is a high priority defect she just discovered in the live environment”

With your scenarios in hand you can start thinking of and drafting your values and principles, as you would otherwise have. Once an initial list is ready you can then turn the feedback mechanism on, right there, in a safe environment of your workshop, to see how useful what you came up with might be. Take each scenario and try to play it out. You may do it all together or in pairs of smaller groups. As you enact each scenario reach the decision point and see if your principles help you agree on an expected outcome. If the principle helps, you’re on track. More likely though, some will not; clarity will be missing, perhaps a pinch of context, perhaps you’ll find out you have had different expectations amongst you. Go back to the drawing board, adjust and rewrite the principles and give them a go with the previous or new set of scenarios. Iterate a few times.

To continue the previous example, if you decide to pick “courage” as on of your values and write it out as a principle along the lines of “we have the courage to always speak openly and directly about problems that we encounter during our development processes” you could try and test it with scenario 2. The principle will tell you that you should now confront the situation and have a conversation with the developer who is having problems. But how should you do it and who should do it – the whole team, a manager, one of the colleagues (and you know this already failed once in your imaginary scenario)? Maybe in the course of role-playing the scene you realise that the way you address each other creates more defensiveness than problem-solving. This could lead you on to adding another principle around the value of “trust” or “mutual respect“.

Let’s recap; in order to take charge of your principles use the following process to create them:

• Write a few scenarios
• Brainstorm and sketch an initial list of principles
• Test each principle against the prepared scenarios
• Improve and adjust the values and principles
• Iterate

Looking through the The PDMA Toolbook for New Product Development I found this little nice snippet about how the ubiquitous 3M Post-it note come about.

Seems like it’s sometimes worth sticking to an idea (pun intended) in case you find a good use for it.

An example of looping back and iteration took place when Spence Silver at 3M first identified the strange adhesive that was more tacky than sticky and which later enabled the development of the 3M Post-it notepads. Initially there were no product ideas for this concept—though Silver visited most of the divisions at 3M in order to find one. The initial idea was to develop a bulletin board coated with the tacky adhesive, to which people would attach plain-paper notices. This concept was never realized, and a new concept, which eventually became 3M Post-its, was later proposed by looping back into opportunity identification and opportunity analysis from idea generation and enrichment.

The engine for the 3M Post-it notepads was a culture that allowed the inventor of this unusual adhesive to champion his new technology for many years in spite of the fact that no recognized application or customer need existed.

I don’t have a clear answer is my head yet, so I welcome your input on the few thoughts that follow.

I have always been told that managers and senior managers and directors in organisations earn more money than “regular” employees because they have more responsibility. I suspect this is a fairly common point of view. Those who are paid more have a larger share of the money, more skin in the game so they should also have a larger share of responsibility – they approve decisions and they should be held to account. Sounds like a sensible justification (or should I call this a rationalisation perhaps).

Looking at it in a systemic way: more responsibility means more money and more money means more responsibility… can you see it yet? A reinforcing feedback loop; A small factor perhaps to explain why in some businesses pay of the top staff spiral out of proportion.

Responsibility seems to be something people are not very comfortable with. It is often easier to have someone else to fall back on than to face all the consequences yourself. For some, it provides sufficient justification for not progressing with their “careers” – they don’t want the extra responsibility. For others, who are willing to take the extra burden, it’s the expectation of an additional remuneration. The pigs and chickens story comes to mind too.

Yet for some reason this logic always seemed flawed to me.

I have rarely seen the most senior people in organisations take the most responsibility. The very thing they are allegedly paid to do, they seem to, somehow, escape. Instead, when things go wrong, they look downwards to find someone to lay the blame on. Imagine the CEO of a supermarket issuing a personal apology when you’ve been sold and out-of-date product? No? Me neither.

It would appear more logical for the level of pay to be related to your contribution (success mode) rather than your assumed responsibility (failure mode). Alas, people are not entirely rational; psychological experiments demonstrate we focus more on avoiding losses than increasing gains, even if the loss is only a perceived one.

So far I only know of a handful examples where this common status quo is challenged, where pay is influenced or even decided by the employees, where contribution is more important than responsibility. Semco comes to mind, perhaps Netflix or Fogcreek to some extend and companies turned into partnerships like John Lewis.

What do you think?

Should a senior manager veto decision of one of their team leads if they don't agree with it? Or should they do nothing and see results?

20/04/2012 9:38 am via TweetDeckReplyRetweetFavorite

@pawelbrodzinski

Pawel Brodzinski

I’m going to treat is slightly broader, speaking of a team rather then just a team lead.

This is not only an interesting question but also one which, I bet, often gets asked, especially as teams gain autonomy in organisations. Let’s leave out, for the time being, the more fundamental issue, whether we need managers at all, and Bob has some tasty thoughts about this.

Let’s consider the two possible solutions to this conundrum.

Veto the decision.

This is most likely the default answer in traditional, command and control organisations. When seniority and position in the hierarchy is confused with experience and knowledge senior managers fell obliged to make their stamp and protect their subordinates from doing the wrong thing. I hope this approach immediately raises your concern, at least a bit. First of all, the higher up you are in the chain-of-command the more removed you usually become from where the real work is done and your understanding of the context and specific challenges diminishes. More importantly however, to blindly veto your team’s decision is a stark demonstration that you don’t trust their judgment or their knowledge. It undermines their autonomy (assuming they had some to begin with) and demotivates them from taking responsibility for their own actions in the future.

Let the team fail.

If you care about your team accepting responsibility, about their autonomy and motivation you may think that the best outcome then is to do nothing and wait for the result. After all, you might accept that you are wrong in your opinion or you may want to give the team an opportunity to learn and fail. The team will continue with their own, independent decisions towards some outcome. They may succeed, or they may fail. If the latter outcome realises don’t be tempted to go and say “well, I always knew this was a bad idea but I wanted you to learn for yourselves”. Regardless, by not sharing your concerns you are withholding information from the team which can potentially harm the team and thus the organisation.

There is a third way.

When Paweł initially asked this question my immediate reaction was that it is irresponsible to do either. It felt very similar to the problem of delegation. “To delegate or not” appears to be a puzzle for many managers. Jurgen gives a good solution to this one reminding us that there are in fact perhaps as many as seven different levels of delegation between the two extremes.

I believe it’s better to aim for the middle in this particular situation too. My preferred choice would be for the manager to honestly and openly approach the team. They should share their concerns in a neutral manner giving the team the information and the context they might be missing. Seeking to learn their position on the problem, exploring the different potential outcomes, exposing any implicit assumptions that either side might be holding and then allowing the team to take an independent, but hopefully better informed, decision. And even though it sounds like a long-winded process it can all be done in a 15 minute chat at a cafeteria.

However, remember what Senge repeats after Argyris

If there is disagreement, it’s usually expressed in a manner that lays blame, polarises opinion, and fails to reveal the underlying assumptions and experience in a way that the team as a whole could learn from.

If that were the case, perhaps the question we begun with is not even the right question to be asking.

Flow is not a natural term we are necessarily used to though, unless we talk about water. In the early days it’s intuitive to equate flow and speed. It’s the easy conclusion to make when adopting our fluvial experience. So it often comes as a surprise that we are also advised to slow down in order to improve flow.

It certainly felt counter-intuitive when I first come across the idea. Even after having read more on the subject, while cognitively it became clearer, my intuition was still in denial. Until I could experience it first hand in reality.

Few years ago I used to drive from Newark to Nottingham. The journey was pretty straightforward, took about 45 minutes and run something like this: drive a single carriageway A46 for few miles, turn right at the Saxondale roundabout, through Radcliffe with a 40 mph limit and then a dual carriageway to the Nottingham ring road.

After a few years elsewhere, I found myself driving to Nottingham again. I was more worried this time though, as serious roadworks already begun to upgrade A46 to a dual carriageway and with them a 40 mph limit where you could previously drive 60 mph.

I fully expected for my journey to take longer. On the first day, I left home early to add some extra contingency and found myself arriving way too early. I thought I have simply avoided the morning peak. On day two similar thing happened. I started setting off slightly later and still arrived on time. I checked my timing, it turned out I was doing the journey in under 40 minutes.

How could this have been if there certainly weren’t fewer cars and I had to drive more slowly for most of my journey? It turned out a lower speed limit helped improve the flow. Remember the Saxondale roundabout and a limit on the road right after it? It was a bottleneck on that road. As cars now approached the bottleneck more slowly it didn’t clog up so much. The queues on the approach visibly shortened, reduced waiting time and thus my total journey time.

Today the A46 upgrade is almost completed. I no longer drive to Nottingham. The surprise, the experience and the realisation that slowing down really does help go faster is still here and has now become part of my intuition. I have seen it work in IT many times since.