The Planning Fallacy

Blame the Book Club at work - one of the books we were to read was "Thinking Fast and Slow". It's hard going and I am still ploughing through it !

Then someone posted, somewhere, a link to an article about Hofstdter's Law

"any task you're planning to complete will always take longer than expected - even when Hofstadter's law is taken into account. "

and just after that, I got to the section of the book that covers the planning fallacy. The author tells a tale of a group of people (including him) who were working on developing a new course. After a period of work during which they had defined what they wanted to do and completed two chapters of the associated supporting text, they had a conversation about how long they thought it would take them to complete the work. There was a range of answers, from 18 months to 2.5 years.

Among the group was someone who regularly did this sort of work and - after having given his estimate (which also fell within the range of answers), he got asked "how long do other people take to do this kind of work ?" and "as a group how do we compare to the average ?"

It turns out that a signficant number of groups NEVER complete the work, but for those who do - it takes around 8 years on average.

And the group doing this particular piece of work were all fairly new to it, so were probably below average.

Hmmmm.... so their own estimate not only assumes they will finish, when there is a fairly high likelihood they won't, but it also assumes they will work three times faster than the norm when they are an inexperienced group !

In the end they did complete, and in around 7 years.

I carried on reading the book, and came across another concept that struck me as potentially useful. The premortem basically uses "prospective hindsight" to look at what might make the project/activity fail, and then look for solutions. That may sound familiar as it is the same kind of thing that we are trying to do when we run Risk Workshops. What I thought might help us is the way of framing the work i.e. to brief people to "imagine one year in the future, we implemented the plan and it was a disaster" and then work through every reason why it did fail.

While this may seem like a negative mindset, it is purely an exercise and intended to prevent that disaster from happening.

And while I'm on the subject (well sort of), here is a link someone shared on cognitive bias and this one too - The Flaw of Expected Values

Doom Loop: restructure blues

or alternatively "I'm a human, get me out of here !"

I was at a conference recently and they showed a video of a previous conference speaker - that speaker made reference to a book "Good to Great" which I gather talks about Kimberley Clark. I got home and decided to check the reference out as it sounded interesting (<cough> geek <cough>)

And it led me to a book by Jim Collins, and the following article about that book ( Good to Great ) where he talks about the "Flywheel Effect"

"Now picture a huge, heavy flywheel. It’s a massive, metal disk mounted horizontally on an axle. It's about 100 feet in diameter, 10 feet thick, and it weighs about 25 tons. That flywheel is your company. Your job is to get that flywheel to move as fast as possible, because momentum—mass times velocity—is what will generate superior economic results over time.

Right now, the flywheel is at a standstill. To get it moving, you make a tremendous effort. You push with all your might, and finally you get the flywheel to inch forward. After two or three days of sustained effort, you get the flywheel to complete one entire turn. You keep pushing, and the flywheel begins to move a bit faster. It takes a lot of work, but at last the flywheel makes a second rotation. You keep pushing steadily. It makes three turns, four turns, five, six. With each turn, it moves faster, and then—at some point, you can’'t say exactly when—you break through. The momentum of the heavy wheel kicks in your favor. It spins faster and faster, with its own weight propelling it. You aren't pushing any harder, but the flywheel is accelerating, its momentum building, its speed increasing.

This is the Flywheel Effect. It's what it feels like when you’re inside a company that makes the transition from good to great."

and it's opposite - the "Doom Loop"

"Companies that fall into the Doom Loop genuinely want to effect change—but they lack the quiet discipline that produces the Flywheel Effect. Instead, they launch change programs with huge fanfare, hoping to “enlist the troops.” They start down one path, only to change direction. After years of lurching back and forth, these companies discover that they’ve failed to build any sustained momentum. Instead of turning the flywheel, they've fallen into a Doom Loop: Disappointing results lead to reaction without understanding, which leads to a new direction—a new leader, a new program—which leads to no momentum, which leads to disappointing results. It’s a steady, downward spiral. Those who have experienced a Doom Loop know how it drains the spirit right out of a company."

Hmmm. If you are in the middle of that change, how do you know if you are part of the "Flywheel Effect" (virtuous circle) or the "Doom Loop" (vicious circle) ?

No one is going to propose a change intending it to be part of a Doom Loop are they ? And probably within change you will get people who see it both ways.

Is this like the Emperor's New Clothes ? Are there always going to be some people within any change who see it as a Flywheel, and some who see it as a Doom Loop... and only time will tell ?

Or are the telltale signs that you are in one or the other ? Are there differences between the two. Isn't that why we have lessons learnt exercises, best practice for change management and so on ? You know, the process that starts with "share the vision"...

Can a good process produce a bad outcome and vice versa ? Is that gut feel and instinct that all is (or is not) well enough or do you need cold hard facts in the bright light of day ?

MOSCOW - are we there yet ?

A work-related post:

Moscow - but as prioritisation rather than destination. As time is a constraint, and we all know there is always more work we could do, somehow we need to prioritise what we are doing....

Must Should Could Won't (now)

How we prioritise things consists of two elements - how important something is, and how urgent it is - MoSCoW gives us the "how important" part of this. It doesn't mean that only the "Musts" get done. But there are only a certain number of "Musts" that can be done at any time, and not everything can be a Must.

So the other part of the equation is how urgent an item is - urgency alone is not a reason to do something (see the urgent/important matrix for more on this). But if we only ever have time to do the urgent things, over time everything becomes urgent.

In reality we end up with a mix of things, like the story about how you fill a jar. You can see the "stones" as being the larger things you need to do, or as the "Must" items that go in first. And then you fill in with the pebbles, sand, water in turn.

It is often difficult to get a clear decision on what is a Must. For things like help desk calls we can define a set of criteria - for example that a "priority 1" is when a complete service is unavailable. This doesn't necessarily mean it is a "big" thing - in a previous job we had a printer down. It was initially treated as a low priority as hey, its just a single printer. But it quickly emerged that the failed printer was located in the factory and was used for printing the despatch notes as things went out of the factory. No despatch notes meant nothing leaving the factory !! That's a priority one. Having a set of clear criteria in terms of the impact something has allows the priority decision to be consistent rather than "who yells loudest". After all, as the saying goes

"A lack of planning on your part does not constitute an emergency on my part"

(I can't find a reference for that quote as it is so often repeated)

When we do hit a crisis the focus is always on resolving that crisis first, and sometimes the step of working out why the crisis came about never gets done. Without that root cause analysis, how do we prevent the crisis happening again ? Another quote, which may be from Pat Parelli but he does have a habit of quoting other people

"what happened before what happened happened ?"

In my day to day work there are often deadlines that we are working to - dates for submission of papers, dates when a project task needs to be done. As that date approaches, there is a need to know "are we there yet ?". Fairly often it is only as we reach the wire that the message comes across "no, net yet". But like any journey, if we know the route and the expected timings along that route, often we have an idea we are at risk of not being there on time well before hand.

A few times recently I've had reason to say "in reality didn't you know this situation 3 weeks ago ?" because there was something due to happen at that point that didn't. And the subsequent leadtimes and steps after that mean that if things were late 3 weeks ago, it was extremely unlikely that the end point could be achieved on time. If they hadn't caught up two weeks ago, then you start to be asking for heroics. And if they hadn't caught up by a week ago, we're talking miracles.

What stops people saying "I'm not sure we're going to make it ?" Is it a triumph of hope over experience ? Is it that we really don't like to admit we can't do something ? Is our work culture unsupportive of saying "it's not going to happen" ?

Hw do we fix that so that if we have something that is urgent and important, the right questions are asked to get it back on track ? And if it is not so urgent, so an open and honest conversation can happen to work out and agree a new and realistic plan

A collection of things (risk, leadership, Deming, multitasking)

Again based on some work posts, a collection of bits and pieces

1) Risk

I was just checking I was using the right language when I talked about risk strategies when I came across this article

The Six Ways of Dealing With Risk

I like the fact that they make the "Ignore" option visible

There is another article referred to, which in turn references a book (in German) - and as part of that they say

Note that avoiding and reducing are aimed at the causes of risks (Ursachenbezogen), while reducing, limiting, insuring and retaining are aimed at the effects of risks (Wirkungsbezogen). The two latter are seen as passive risk management (Passiv), while the three former are seen as active risk management (Aktiv).

It's kind of commonsense, but still a nice reminder to see in writing

2) Management is not Leadership

As this is a blog I should probably be preparing some well considered words of wisdom. But instead I am just going to share someone else's

a recent article from HBR: Management Is (Still) Not Leadership

3) Deming's 14 points

There had been a series of  "employee engagement" meetings, and I was in a reflective mood when I came across this blog post....

Deming's 14 points

and it seems to me that a number of these contribute significantly to employee engagement. Where they don't (e.g. End lowest tender contracts), do they still have a lesson for us ?

4) the impact of multitasking

It was interesting to come across the following piece on the impact of multitasking because basically it means that the more small projects any one Project Manager has, the less effectively they are able to work.

It's all about the journey

Change is everywhere, it is the only thing that is certain (other than tax and death !)

So often we are on TV these days we hear people talking about the "journey". It's all about the journey. So if you had the choice between

a driver you knew and trusted who had a clear and current road map, in a well maintained vehicle, on a well maintained road with clear signposts to the required destination, with good visibility

vs

a driver you don't know who doesn't have a map, on a narrow windy road on the side of a steep mountain, in a poorly maintained vehicle.... and on top of that you had to wear a blindfold

which journey would you want to take ?

It's a bit of a leading question I know, although your appetite for risk may affect the answer !

I've come across a couple of articles in change management recently. In all likelihood such articles are always out there but I noticed them because it is a hot topic for me right now.

10 key principles of change management

and this you tube video 1 minute guide to Change Management

One of the key aspects of the first part of change management is setting out the vision. Now this may be done in many different ways. For example you could paint the picture of the future in terms of the positive destination you are aiming for. Or you could describe the "armageddon view" of what will happen if there is no change. Either way you are setting out the journey, providing a roadmap, maybe even describing some of the route. And in doing so you are establishing what kind of a driver (or leader) you are.

If you don't take this step, the journey planned may be no different - but the people you are taking on that journey have no idea of where they are going, what they may encounter on the journey, or how to prepare for that journey. And all of those fellow passengers will have their own personal appetite/tolerance for risk.

It becomes kind of obvious why this is the first step in change management, assuming you want your fellow travelers to make the journey with you.... doesn't it ?

Decision Gates in a staged project process

(More work/project related content that was written at work. I'm not sure the final quote is the best - but basically what I was wanted to say was "do the right thing at the right time") I first came across a stage and gate project approach many years ago in a private sector context. Basically the idea is that every project has clear and obvious decision points along its journey. Between those decision points, the team does its work. While the overall vision is still what guides the journey, between gates the tasks and work that are done relate to getting you to the next decision "gate". At each "gate" there are a series of checks that will be done to allow the project to get a clean bill of health to start the next leg of its journey. There is an implication here that a project is never guaranteed a "pass" at the gate. It may fail the test. In which case it may either take corrective action and represent, or the project may be closed. The resulting profile of projects was referred to as a funnel - because there would be more projects in the early parts of the journey than the later. At each decision gate, the project would effectively be given delegated authority to progress and would only need to refer back to the decision group if the project went outside its approval (time, cost, scope, etc) and hence was in exception. As I have worked for other companies since then, it has become clear that many organisations use a similar approach even if they call it something else, and their project pipeline has a different profile and shape. In my (humble) opinion, one of the key factors in a successful stage and gate approach is being clear what decision is being made and what authority being delegated at each stage. For example, an early decision gate might simply be "Is this a good idea ? Does it align with agreed strategy ?". Such a decision would only require an outline of the idea and would only be granting approval/authority to take the investigation to the next stage - which in this case would be to explore feasibility and, inherent in that, options for delivery. And to make that decision (to explore Feasibility) does not require a high level of detail or fully explored Cost Benefit Analysis. Even after Feasbility has been explored, it may only be possible to give a range of figures for time, cost, scope. But the decision at the end of the feasbility work is merely to progress to refine the solution, and confirm design etc. At this stage the decision may be to exclude certain option - for example "it needs to cost less than...." or "it needs to be complete by....". But again the information behind the decision only needs to be appropriate for that decision. If you skip stages, then you are effectively also slipping decision points. So you might go straight from "Is it a good idea ?" to "Can the build/development work start ?". But if you do that, you need the information to inform the "start" decision rather than the information you would use to agree feasibility work. This may be absolutely the case where the feasbility and solution are already well defined - but if it is already that well defined, the information for a fully detailed business case should also be available with relatively little effort. If the decision makers require additional detail and information at the earlier stages, there are a number of risks. For example that the figures and detail provided are by their nature much more liable to error and will have a much lower confidence level. Relying on that detail to inform a decision that does not require it could mislead the decision making process. There is also a risk that assessing, for example, financial fitness at an early stage could provide a false sense of security and lead to less rigorous scrutiny at a later date - i.e. that there is an implicit "pass" at all future gates if the information has been seen once (despite its low confidence level). As Robert H Schuller said Never cut down a tree in wintertime

The Domino Effect and Traffic Management

(A combination of two work posts - about throughput and constraints)

1) the Domino effect of project failure

“Given the rule of thumb that one in ten projects will go badly wrong, and given a program of 20-25 projects, you will most likely have at least two that overrun seriously and will be canned. But the damage won't stop there. Those two projects will then cause the two below them in priority to be canned. Now there are four projects out of two dozen that won't happen.” The domino effect can be taken even further: “In certain instances those projects that have gone wrong are on the critical path for other projects - and they push those back as well.”

from Best Practices for Small Projects

Interesting.... and of course this doesn't apply only to small projects.

Wherever you have a constraint... time, resource, money... one project going over (or under) will impact others. In most cases a project being "under" time, resource, or cost represents an opportunity. And that opportunity will also have a ripple effect.

But where the project goes over on a constraint, then the impact is like throwing a stone in a pond... the ripples spread a very long way.

It is human nature to try and carry on with all the existing commitments as if there is no issue. But the result is that resources get spread more and more thinly, so more

2) which led me on to: Traffic Management

I've been trying to work out how to illustrate that there is a point where more projects just mean you reduce what you are delivering. Here is my first attempt.

Let's assume you have a 4 lane motorway - this represents your total capacity for work and change.

Now I have 3 convoys of vehicles. For ease of identification let's make each vehicle in a particular convoy the same colour - so I have a blue convoy, a red convoy, and a green convoy.

Because I have a 4 lane road, all 3 convoys can be en route at the same time. All my convoys can move at their maximum speed without interfering with each other. And in fact there is an empty lane so I could get one or more convoys to their destination even sooner. If a vehicle in a lane breaksdown, it does not interfere with any of the other convoys. And I could use the extra lane to make up some of the lost time. My arrival simply depends on the slowest speed in each convoy and the length of the convoy. As the last vehicle in a lane clears the start point, I can start another convoy on the road.

Now I add an extra convoy (white). This is still fine as each convoy can use a lane of their own. If there is a breakdown, there will be less chance to make up time as I will need to wait for one of the other convoys to clear the road.

Add a further convoy (black). Hmmm - now I start having to interleave vehicles on the 4 lanes as there are fewer lanes than convoys. This is going to slow up the last vehicle in each convoy getting to the end point. The planning is much more complex as I need to understand the speed of each vehicle in order to work out how best to schedule things into the lanes. There is limited room for manouvre and a breakdown is going to impact multiple convoys. It becomes much harder to tell you when any single convoy is going to reach the end point because it depends so much on what other traffic is in its lane.

If I keep adding in convoys to my road, there will come a point where the smallest slowing down in a single vehicle will trigger gridlock.

Of course for projects it is a more complicated situation in that the size of my "motorway" is not simply a number of lanes, the vehicles are all different sizes and may also require different types of road to run on.

But there is a still a point at which adding more projects in results in delivering less not more.

Liberating Disciple

(Another of the work posts I wrote)

A multinational organisation I have inside knowledge of used to have a concept called "Liberating Discipline". Although on searching to check this, I discover some of the countries knew the same concept as "Liberating Rigour". Call it what you will, the intent was the same.

"the term “liberating rigour” is used to stress the importance of standardising and simplifying where it is possible. This releases the creative energy to those areas where it really brings value to consumers."

or perhaps you could say "Don't sweat the small stuff...... it's all small stuff"

Basically the idea here is that the things that can and should be standard, common, and simple really should be. By making them so, you remove the need to continually ask "how" everytime you need to do a particular thing as it is standard, simple, and there are templates and guidance that you just follow.

The real seller in this concept is that in standarising the "boring" stuff, the bread and butter, the tasks that are effectively a commodity and need doing but do not, in themselves, require a bespoke approach....

by doing that, you free up a whole shed load of time to do the interesting things, the things that make a difference. And sometimes that is a virtuous circle where the time you free up allows you to improve, simplify and/or standardise other areas.... which frees up more time

It is such a no brainer that you have to wonder that they needed to include it in a change campaign and articulate what it meant, to convince people it was the right path.

To quote someone else's blog on this concept:

It meant that we need rigor to perform, but we have to ensure we use rigor TO liberate. That means the right type of rigor, in the right dosage, applied in the right way.

Habits require discipline. But once built, they free us, as we don’t have to fight ourselves to do the right thing. Our energy, physical and moral and even mental and emotional, can then go to performing, not trying to talk ourselves into doing what we need to.

If you want to be ‘free’ to speak a language, dance, run a marathon, understand Goethe’s Faust, you have to first engage in the ‘rigor’ of practicing the fundamentals of the language, building up aerobic capacity and muscles, cultivating a sense of rhythm and movement, deeply reading critical commentary as well as Goethe’s monumental play. Only such rigor frees us to be able to engage these aspirations.

(the other concepts were "Passion for winning" and "Connected Creativity"

The 3-30-3-30 rule

(This is one of a series of posts I wrote in work so have less of the equestrian side in them.)

I was trying to find a reference to the concept of the "30 second" rule as a test for vision and strategy concepts. The idea is that if you can't express it clearly and concisely in 30 seconds, then you need to do more work to refine the concept.

And in checking references for that, I came across an extended version -the 3-30-3-30 rule

Translating that into more local terms:

Three seconds: a headline that grabs the audience attention. Not the ordinary title people use for their site documents, but instead actually thinking clearly about what’s in it for the audience. In other words, how you would quickly describe the document to someone if you were in the lift between floors.

Thirty seconds: A very simple overview of the issue, its background and the position of your organization. Very short, if possible keep to 3 or 4 paragraphs.

Three minutes: A one-page policy brief that overviews the issue in slightly more detail. Think of this as the one-pager the author will print and hand to the stakeholders and/or decision makers.

Thirty minutes: The deeper detail providing everything the team need to be fully informed on the issue. This includes providing document referneces and links to additional resources to help provide a full picture of the issue.

Plagiarism is just another word for sharing best practice

good better best....

My formative years in work were subject to many days of training, all aimed at making me better at what I was doing and would do in the future. The organisation I worked for adopted "Total Quality" and later used the EFQM model. They talked about the target of having an excellent workforce. The ongoing performance management echoed that. There was a continuous improvement ethos that was built in and embedded to everything we did.

In my horsemanship it has never been much different. And a certain natural horseman has a string of sayings all aimed at improvement, excellence, quality. One of which I remember my father quoting when I was a young girl:

Good, better, best
Never let it rest
Til your good is better
And your better best.

Recently a project management discussion forum posed a question "what would make you leave project management ?"

My initial answer was that it would be working for an organisation that knowingly asked me to do something second rate.

Today I had an interesting conversation when someone from HR suggested that he thought maybe I set my standards too high. While I suspect he was trying to say I was being too tough on myself, wasn't he effectively saying "don't be the best you can be" ?!

Here's a quote to sum up how I feel about that: 

It's not about changing who you are, it's about being the best you can be. 

Eileen J Roden

Asking the right questions at the right time

So this is much more about work than horse, but it may lead me there as it is equally important to ask the right question at the right time in either context.

I first came across a stage and gate project approach many years ago in a private sector context. Basically the idea is that every project has clear and obvious decision points along its journey. Between those decision points, the team does its work. While the overall vision is still what guides the journey, between gates the tasks and work that are done relate to getting you to the next decision "gate".

At each "gate" there are a series of checks that will be done to allow the project to get a clean bill of health to start the next leg of its journey.

There is an implication here that a project is never guaranteed a "pass" at the gate. It may fail the test. In which case it may either take corrective action and represent, or the project may be closed. The resulting profile of projects was referred to as a funnel - because there would be more projects in the early parts of the journey than the later.

At each decision gate, the project would effectively be given delegated authority to progress and would only need to refer back to the decision group if the project went outside its approval (time, cost, scope, etc) and hence was in exception. The approval was to the next gate, but with the long term vision still as the ultimate end point.

As I have worked for other companies since then, it has become clear that many organisations use a similar approach even if they call it something else, and their project pipeline has a different profile and shape.

In my (humble) opinion, one of the key factors in a successful stage and gate approach is being clear what decision is being made and what authority being delegated at each stage.

For example, an early decision gate might simply be "Is this a good idea ? Does it align with agreed strategy ?". Such a decision would only require an outline of the idea and would only be granting approval/authority to take the investigation to the next stage - which in this case would be to explore feasibility and, inherent in that, options for delivery. And to make that decision (to explore Feasibility) does not require a high level of detail or fully explored Cost Benefit Analysis.

Even after Feasibility has been explored, it may only be possible to give a range of figures for time, cost, scope. But the decision at the end of the feasibility work is merely to progress to refine the solution, and confirm design etc. At this stage the decision may be to exclude certain option - for example "it needs to cost less than...." or "it needs to be complete by....". But again the information behind the decision only needs to be appropriate for that decision.

If you skip stages, then you are effectively also slipping decision points. So you might go straight from "Is it a good idea ?" to "Can the build/development work start ?". But if you do that, you need the information to inform the "start" decision rather than the information you would use to agree feasibility work. This may be absolutely the case where the feasibility and solution are already well defined - but if it is already that well defined, the information for a fully detailed business case should also be available with relatively little effort.

If the decision makers require additional detail and information at the earlier stages, there are a number of risks. For example that the figures and detail provided are by their nature much more liable to error and will have a much lower confidence level. Relying on that detail to inform a decision that does not require it could mislead the decision making process. There is also a risk that assessing, for example, financial fitness at an early stage could provide a false sense of security and lead to less rigorous scrutiny at a later date - i.e. that there is an implicit "pass" at all future gates if the information has been seen once (despite its low confidence level).

You get what you accept

I confess I have found myself quoting this at work a number of times over the past few months. But it was only recently that I stopped to think about what I really meant. Well not so much stopped as mildly ranted at a friendly colleague when discussing the latest work frustrations.

So here is my first "compare and contrast"

You get what you accept.... with a horse

In the horse world, this is normally about a rider/handler and the horse they are working with. There will be rare situations where a handler is working with multiple horses - driving a pair or four for example. But for most of us it is a one to one situation.

In the interaction with a horse we have to decide what our boundaries are, what is "ok" and what is "not ok". Anything we accept becomes, by accepting it, "Ok".

What is the difference between accepting and not accepting ? It's interesting how we humans tend to think of these things in terms of a BIG reaction. A BIG reward for getting it right, an equally BIG reaction of some form for getting it wrong. The reaction for the "wrong" result depends very much on your personal philosophy.

But for a horse it can be something much smaller than that. A release can be a reward, and can be as small as an exhale. My second pony had a rough time in his youth - when we first got him he would *shake* if you raised your voice. When asking for something, Parelli talks about four phases - and uses the idea of "air, skin, muscle, bone" to give you the idea of how those phases progress. (I doubt many of us ever use a true phase 4. But in the same way, I suspect we tend to go in somewhere more than phase 1)

I think that makes the cue a negative reinforcer - as the required behaviour terminates the reinforcer. Initially they (Parelli) weren't into treats and thinking about it, even "rub to a stop" is a negative reinforcer (the rub stops when the horse stops). More recently the horsenality concept has meant treats are used with appropriate types of horses.

But that is straying into another subject, about rewarding wanted behaviour. "Accepting" can simply be that - no reaction, no reward, just accepting. Not accepting doesn't have to be a negative reaction but could simply be asking for the same thing again.


You get what you accept... at work

In a work situation, by contrast, we are rarely in a one to one situation and more often in a one to many or many to many context. Added to that, you aren't always in the leader role and may instead be in peer groups, or working across different levels of hierarchy within the organisation.

So in work, how does "you get what you accept" work ? While almost by definition there is an implication that if you don't want a particular behaviour to persist - you have to "not accept" it. But how acceptable is it to "not accept" something in work, especially if the unacceptable behaviour is from above you in the organisation hierarchy ?!

Is there a greater need for diplomacy in a work environment ? My initial reaction is yes, but I dislike the implication that I can somehow be undiplomatic with my horse. A horse tends to expect a much more straightforward or honest reaction, whereas at work people come to expect a certain amount of dissembling.

The reality of needing to keep your job, to pay the bills, simply does not form part of the interaction with a horse, but can not be escaped in the work situation. How much is it ok to compromise your integrity in the work place ? If the presiding culture simply does not support active challenge, where do you draw the line in terms of speaking your mind versus biting your tongue ? And if there is no option to "unaccept" within the work environment, is the only option to reject the entire work environment and change job ?