Why innovation needs to be continuous

/in , /door

Innovation is a hot topic nowadays. Many organisations are investing in some form of innovation lab or internal accelerator program. Or they separate new business ventures from the main organisation by starting a startup-like small company. Or acquire one for that matter. Many are experimenting with concepts like lean startup, business model innovation, or design thinking to give their innovation powers a boost. What these companies have in common is they realize their business models won’t last for ever. What they also seem to have in common most often is the idea that you can successfully externalize innovation from the rest of your organisation. This seems to tag along with the idea that you only need to innovate once (successfully) to be safe for a while again. But is this true?

Most decision makers agree their business models are or will be under pressure. They need some form of innovation. Yet there are plenty of examples that illustrate how hard it is to innovate in time. Upon the introduction of the iPhone, RIM’s CEO Jim Balsillie, told a Reuters reporter that the launch of Apple’s iPhone wasn’t a major threat, simply the entry of yet another competitor into the smartphone market. We all know how that ended.  Toys ‘R US always seemed like a rock solid name to me. I didn’t even realize the company dated back to the fifties. Yet, the company filed for bankruptcy in September 2017. RadioShack was a household name for decades in the US after it filed for bankruptcy for the second time in 2017. What these companies have in common is that they were once highly successful, but didn’t manage to turn the ship around fast enough to survive or stay relevant.

Another faded name is Palm. What is interesting about Palm was that they did not start out as a hardware company. They first provided software for other brands devices. Devices that largely failed commercially. But somehow Palm reinvented themselves in-time and popularized the PDA. They actually tried to reinvent themselves a couple of times during their period of existence with the rise of smartphones, and with the introduction of their WebOS platform. But none of those attempts rivaled the success of their first reincarnation. The history of Palm seems to suggest that in order to survive in the long run a company must reinvent itself in time. But one time is not enough as the new business model will eventually fade as well. This would mean that the key to long term success is not so much the ability to innovate but the ability to do it continuously. So it is not the innovation itself that counts, but the ability to continuously test new waters; grow and nurture successful business models, and pull out in time in favor of new more promising opportunities.

Continuous innovation makes sense when the life-cycle of a business model is either short, or unpredictable. Or both.

Continuous innovation only makes sense if the life-cycle of a business model is either short, or unpredictable. Or both. We argue this is the case in most industries nowadays. Let’s investigate why. One of the major reasons is that barriers of entry for newcomers are dramatically lowered:

  • The access to information and knowledge is now almost equal for anyone. Protecting a market by superior knowledge once was a standard way to protect your competitive advantage.
  • Access to talent is easier. People can work everywhere nowadays, we don’t necessarily have to gather in the same office building everyday anymore.
  • Capital is more easily obtainable. Although investment funds seem to have raised the bar lately, there are still many accelerator programs, startup boot camps, and corporate incubator programs. Angel investors are a valid option for many, and crowd-funding platforms are still growing.
  • Access to capital is not only easier, companies typically also need less of it to start. Launching a product or service, especially online, has never been faster and cheaper.
  • According to Ash Maurya you can launch and grow a business from anywhere these days. Geographic borders are down. Even more, you can be a global player too. As Hal Varian, Chief Economist at Google, puts it:

If the late 20th Century was the age of the multinational company, the early 21st will be the age of the micro-multinationals: small companies that operate globally.

The competitive landscape has been majorly disrupted because of this. However, most companies are designed to defend their business models over a long period of time. They are designed to squeeze the last bit of efficiency out of a business model before giving up. As a consequence they are ill equipped for fast and repeatedly innovation. This explains the popularity of organizing innovation away from the core of the organization, shielding it from the slow bureaucracy of the organisation.  There is an even more profound and important consequence that business leaders need to understand and accept in order to have a decent chance to lead their organizations to long-term success:

A sustainable competitive advantage no longer exists.

Let that sink in for a minute… Competitive Advantage is mostly described as the ability of an organization to outperform its competitors. It is also the title of the 1985 book from Michael Porter, undeniably the textbook on this subject. The biggest problem of Porter’s model lies in the assumption that a competitive advantage can be sustainable, that is: you can successfully defend your competitive advantage over long periods of time. In today’s world of fast change and high complexity, that is a dangerous assumption to bet on. The business graveyard lies full of once well-known and relevant names of companies who held on to that belief for too long. Rita Gunther McGrath, a renowned expert in this field, puts it this way:

When competitive advantages don’t last, or last for a much shorter time than they used to, the strategy playbook needs to change.

The pace of change is just too high for a strategy based on sustainable competitive advantage to keep up. The lowered barriers of entry make it very hard to successfully defend a competitive advantage, and besides, who wants to be on the defense forever? Therefore, innovation needs to be continuous. But that brings us back to the question whether it is a good idea to externalize innovation. I think you can guess my answer by now. It is not. While an accelerator program can come up with some promising new business ideas, and a startup like separate company can prove some viability in a new opportunity, nothing has fundamentally changed to the core of the organisation. While a small nimble part of the organisation comes up with new ideas, the rest of the organisation is still aimed at defending a competitive advantage, at maximizing efficiency, and gaining economies of scale. It is still a slow bureaucratic oil tanker. What happens if the new business models eventually are absorbed into the mother organisation? In the end you have gained little. What’s needed it what we call an adaptive organisation:

The Adaptive Organization has the core ability to continuously reinvent itself.

Although it is applaudable that companies take initiative in innovation programs, I am afraid that the current prevailing strategy of externalizing it, will bring disappointing results in the long run. It also feels like senior management is not all in: they still bank on the current main organisation, and innovation is still a separate show that can easily be canceled once its popularity starts fading. Let’s finish with a quote of the famous Peter Drucker:

Because the purpose of business is to create a customer, the business enterprise has two–and only two–basic functions: marketing and innovation

If would want to learn more about continuous innovation, you can attend one of our Continuous Innovation workshops. Or contact us for a talk.

 

Sources:

[Dabrowski, W. (2007). “Update 1-RIM Co-CEO doesn’t see threat from Apple’s iPhone”. Reuters.]

[Hal Varian (2011). Micro-multinationals will run the world. http://foreignpolicy.com/2011/08/15/micromultinationals-will-run-the-world/]

[McGrath, Rita Gunther. (2013). The end of competitive advantage. Harvard Business Review Press. p. 4.]

Shifting the Burden – Using Systems Thinking to build high-performing teams

/in , , /door

Systems Thinking provides us with useful insights how organizational systems work. The insights are often surprising in the way they help explain common dysfunctions in organizations. It is a pitty that beyond the field of organizational scientists it doesn’t seem to be very well known. Systems Thinking is part of the foundation of Agile: Agile scaling frameworks like LeSS and SAFe both explicitly mention Systems Thinking in their underlying principles. Yet, rarely do I come across agile coaches that even have a mediocre understanding of ST. Most have even never heard of it. If you really want to understand the barriers of agile in organizations, both Systems Thinking and Complexity Theory, also not that well-known, are crucial. Because even agile coaches or should I say especially agile coaches, fall into the traps of local optima and symptomatic solutions. So let’s explore how Systems Thinking can help in building high-performing teams.

If you have a headache and you take an aspirin and the headache goes away, then you might just be happy with that and not worry about why you had a headache in the first place. Next time you get a headache, you just take another aspirin, because it worked the first time. Pretty soon you will get used to it and always keep aspirin around and never look for a more fundamental solution to headaches. Taking aspirin will make it less and less likely that you actually adjust your health so that your body works right in the first place.

Systems Thinkers discovered patterns of cause-effect relationships in organizations that are called archetypes. Shifting the Burden is one such archetype, and the headache story above is an example of it. Here’s how it works: We have a problem symptom. There is a fundamental solution to the problem, although it usually works at a delay. The fundamental solution gets overlooked very often because of short-term thinking, pressure within the organization to come up with a quick fix, and a poor understanding of the relationship between cause and effect. Instead we ‘shift the burden’ to other solutions, easy fixes that seem to work well. Unfortunately we only deal with the symptom and not the underlying problem. Covered up by the symptomatic solution, the underlying problem grows worse unnoticed. We use more and more of the quick fix solution because that seemed to work, further reducing the pressure to seek a fundamental solution. Eventually the organization’s ability to solve the underlying problem gets undermined.

Another common example in the agile world is a manager that is trying to empower teams by delegation. But as the team struggles he steps in to help them, with all good intentions. Over time this reduces the ability of the team to solve issues themselves. Instead they increasingly get more dependent on the manager. The overprotective scrum master is another well-known phenomenon in this category. Although often praised for the good relationship he or she has with the team and the great atmosphere in the team, the scrum master unintentionally effectively has become the leader of the team, with everyone depending on him or her.


The picture above is a causal loop diagram that explains the generic Shifting the Burden archetype. The diagram depicts the quick fix solution that temporally lowers the problem symptom, and the fundamental solution that would lower the symptom as well, although usually at a delay. There’s a side effect loop that shows we get more dependent on the quick fixes as we use them undermining our ability to address the actual underlying problem.

Now let’s get back to our team. I have seen many teams like this where the team itself insists they are a strong team: they tell each other lots of stories about their private life, they have drinks together and organize the occasional team event. But if you observe the team a little closer you will notice most conversations are quite shallow, everybody’s playing nice to each other. The teams reaction to conflict is to cover it up. As a result the team does not learn how to deal with conflict. The more they revert to the symptomatic solution of smoothing things over, the less the team will be capable of working on a fundamental solution, which could be working on team cohesiveness by creating trust, coaching the team in conflict resolution and a shared sense of accountability for results. This is described in the first part of the diagram: causal loops B12 and B13.

In a complex system however all parts of the system are interconnected and a change in one part can inadvertently lead to a problem elsewhere. We often find series of interconnected shifting-the-burden structures where one fundamental solution is another problem’s symptomatic solution.

So how does the fundamental solutions become the symptomatic solution of another problem? While team cohesiveness grows a team identity starts getting developed.  They slowly develop a ‘them-against-us’ mentality towards other teams or the surrounding organization. People outside of the team start perceiving the team as inward-thinking, taking care of only themselves, even if not in the interest of the larger organization. Conflict with the rest of the organization starts to grow.

The fundamental solution of building team coherence to the conflicts-within-the-team-problem has now become a symptomatic solution of a new problem: conflict between the team and it’s environment (causal loop B15). The team tries to deal with the new conflict by closing their ranks, sticking together, which in the ends only decreases their ability to fundamentally deal with the rest of the organisation in a constructive manner.

So now we need to look at a fundamental solution to his problem, like helping the team to build a better understanding of the part they play in the larger organization (causal loop B16). You could encourage the team to explicitly define some of their team goals as contributions to higher organisational goals. This is actually a very powerful way to deal with the issues we inherit from today’s silo organisations: give teams or departments a goal they cannot achieve by themselves, but only by collaborating with others.

This practice is in contrast with the popular agile practice of giving teams their own domain to focus on. We are strongly apposed to this. The logic behind it is to encourage teams to take ownership of their own area. But teams don’t work in isolation. They are part of a bigger whole, and this practice will unavoidably lead to local optimization and inward-focusing teams. Systems Thinking can help you understand and predict that.

Note that we covered only one Systems Thinking archetype in this article and only a fraction of the concepts behind Systems Thinking. Nevertheless there are valuable lessons for agile coaches or anybody working on high performing teams:

  • Always focus on the fundamental solution vs a symptomatic solution. Withstand organizational pressure for quick solutions. There are no quick fixes to complex problems.
  • Note that a fundamental solution often needs to be discovered. In many cases it is not a matter of analyzing, but of discovery through experiments.
  • Be aware that the more one applies a symptomatic solution the less one becomes able to come up with a fundamental solution.
  • Realize that a fundamental solution can at the same time be a symptomatic solution for another problem.

Do you want to know more on what Systems Thinking can do for your team and organization? Attend one of our Management 3.0 workshops.

Notes:
[Martin Knapovsky. Shifting the burden archetype. https://www.knapovsky.com/shifting-the-burden-archetype/]
[Daniel Kim. Shifting the burden revisited: Turtles all the way down. https://thesystemsthinker.com/shifting-the-burden-revisited-turtles-all-the-way-down/]
When your only tool is a hammer

If your only tool is a hammer…

/in , , , , /door

The environment of organizations changes at an increasingly fast pace. Complexity and uncertainty are on the rise. But the set of tools that management uses to manage and design their organizations, is changing very slowly. There is an increasing mismatch between the applicability of tools used and the problem domains of modern organizations. How can we assess which domain we’re in and if we are using the appropriate tools?

There’s no denial that organizations operate in a world of fast change, uncertainty, and constant flux. Windows of opportunity open and close faster and faster. Maintaining a sustainable competitive advantage is pretty hard these days. It also seems apparent that most organizations are ill equipped for dealing with rapid change. One indicator is the life expectancy of organizations. It seems to be shrinking at an alarming rate. Professor Richard Foster of Yale University led a Innosight study that shows that a 61-year tenure for the average firm in the S&P 500 index in 1958 narrowed to 25 years in 1980, to only 18 years now. Even more, at this rate by 2027, over 75% of the S&P 500 will be companies you have never heard of. That’s pretty alarming, isn’t it?

There’s obviously work to do for the management of any organization. Complacency is your biggest enemy in this world, it is a one-way street to irrelevance. The business graveyard is full of companies that either reacted too slow or not at all to change. We don’t pretend to have a silver bullet that transforms any organization into a resilient adaptive organization that can deal with anything. But a first step is to be able to asses which problem domain were in and if the tools we use match the domain. Unfortunately, many organizations stick to tools they know like hierarchy, centralization, focus on efficiency, strict rules and processes, linear planning, etc. There’s nothing wrong with these tools per se, it is just that they were designed for organizations that existed about 100 years ago. Many management tools are, more or less, still the legacy of Frederick Taylor’s Scientific Management and Henri Fayol’s functions and principles of management. The world has changed dramatically since then. In the Western economies there aren’t that many industries anymore where these tools work well.

Every organization, department, team, or process is situated in a specific problem domain, each with its own appropriate tools. So how can we tell which one we’re in. A very useful tool here is a sense-making framework called Cynefin. The Cynefin framework has four main domains, and a fifth one called disorder, that each describe the context in terms of the relationship between cause and effect. The four main domains are called obvious (I still prefer the old term ‘simple’), complicated, complex, and chaotic. The disorder domain is used in case it is not clear in which domain we are.

For a detailed description of the Cynefin framework, you can read the excellent Harvard Business Review article by the framework’s founder Dave Snowden. For the purpose of this article we keep the explanation short: In the Obvious domain, we can easily categorize the problem we face and pick the appropriate checklist or process description to solve it. Because the environment here is pretty stable and predictable we can focus on optimizing best practice processes. A simple loan approval process is a good example.

In the Complicated domain things are not as simple and predictable. We need experts to analyze the situation before we can respond. Most of the time there is still a noticeable relationship between cause and effect but it can be separated in space and time making it hard to spot. This is reinforced by management structures like silo’s and KPI’s. We make a decision in one silo, let’s say sales, which has an undesirable effect on another silo, let’s say operations. We don’t see the relationship between cause and effect here because it occurs somewhere else (place) and maybe with a delay (time). Our focus on sales, reinforced by a KPI that just measures sales output, causes us to miss the unintended consequences for the operations department.

The Obvious and Complicated domains together are called the ordered domains. Many organizations think they are in the ordered domains, whereas an increasing number or situations in organizations, teams and processes actually fall in the complex domain, which requires a completely different approach. Because in the Complex domain, good or best practices won’t work. The environment is not stable or predictable, we therefore cannot simply repeat what worked in the past. Nor can we plan the future. We can only discover it by experimenting. The relationship between cause and effect might be there but in most cases can only be seen in retrospect. This is counterintuitive for many managers and therefore hard to accept. There is a dominant tendency to wanting to be able to control and predict the future, even in situations where we can’t, and even if we experience time after time that our carefully crafted plans quickly fall apart.

Now take an invoicing process for example. Most organizations sell something, so invoicing is a common process. You might think invoicing is a predictable stable static process that can easily be handled and optimized by an automated process, and therefore falls into the obvious domain. You are right. The danger is that this makes management rely on processes and rules only. It is not the 95% of correct invoices that matter, but the 5% that are incorrect or exceptional. These are the ones that take up most of the time, and are a danger to the organization’s reputation if not handled well. You cannot handle the exceptional cases the same way as you do predictable ones. But most organizations do. If an exception is found, we create another rule for it. If a customer complains about a wrong invoice we adapt the process. Until the next exception. And the next one. Our system slowly becomes hard to understand and maintain, slow to adapt to new situations, and very costly. And we still find ourselves constantly surprised by new exceptions we haven’t covered yet. What makes matters worse, the way we handle customer complaints on wrong invoices suffers from the same problem: Customers Service reps tend to use strict scripts that handle standard situations well. But the frustration of customers comes from the non-standard mistakes in the first place, and the inability of customer service the solve the issue only adds to the frustration.

Sounds familiar? It is a constant source of airtime for television consumer shows: telco’s, energy companies, and insurance companies getting scrutinized for their inability to properly deal with non-standard situations that appear so obvious for the customer and viewer. It is a classic example of using the wrong tool for the wrong domain. Yet these companies never seem to learn. What’s the standard reply of every spokesperson or executive brave enough to appear before the camera, when asked how they are going to prevent these issues in the future? “We will analyze the process and improve it”. Sigh…

And that brings us to the key takeaway of this article: if you don’t know which domain your situation is in, your will probably treat it as the domain of your preference and the one you are used to. And in many cases that turn out to be the wrong one. You will then be using tools that are not wrong per se, but they are inappropriate for the problem at hand. After all, if your only tool is a hammer, then every problem looks like a nail…

 

Employee Empowerment demystified Part 2

/in , , /door

Empowerment and delegation are management practices that are gaining popularity. However they proof to be hard to implement. In part 1 of this article we explored some of the principles behind delegation and empowerment that help you explain what can go wrong and why it takes time. Next we are going to look at a practical tool from the Management 3.0 toolkit that helps implementing delegation.

Management 3.0 defines seven levels of delegation. The delegation levels and a delegation board help implementing empowerment following the principles we discussed in the first part of this article. Having multiple levels of delegation makes sense. When setting constraints you will find that for some decision areas different levels of delegation are appropriate. The seven levels are:

  1. Tell: You as manager make the decision and you inform others of the decision made. This is obviously the lowest level of delegation. Actually it not delegation at all, but there will be areas where you just cannot delegate decision making.
  2. Sell: You make the decision but you do try to convince others it is the right decision.
  3. Consult: You ask for input, and then make a decision taking the input into account.
  4. Agree: You try to reach consensus as a group on the right decision.
  5. Advise: You offer your opinion but it is their decision to make.
  6. Inquire: They make the decision but you do want to be informed.
  7. Delegate: They make the decision and you don’t even have to know what it is.

The first step is to identify areas of decision making. Be as specific as possible. Don’t do this on your own, do it together with the people you are delegating decisions to. It is ok to prepare a preliminary list of course but don’t fall into the trap of unconsciously choosing the lowest level of delegation for… implementing delegation.

The second step is to go by each decision area and agree on the appropriate delegation level. It is ok to be clear that some topics will have a lower level of delegation for now, after all you are setting constraints. People understand you won’t be leaving everything up to them. Don’t forget the reflexive principle: team members might not feel comfortable with a high delegation level at some areas, even if you feel confident they can do it.

Management 3.0 has nice sets of cards available that represent the delegation levels. You can use these just to make things more visual: it has more impact to point to a card than to say ‘level 4’. You can also use the cards to play Delegation Poker, a derivative of the Agile estimation technique Planning Poker.

The Delegation Board is the final step: it is the visual result of the agreements made. The Delegation Board is a grid that displays all decision areas as rows and the 7 delegation levels as columns. It marks the delegation level for each decision area. Being transparent on the agreed delegation levels is crucial.

An example of the use of the delegation board is a manager who had two goals: the first was to increase the level of responsibility of the team leaders in her group. The second one was a very practical one: to reduce her workload caused by the company policies requiring her to approve everything. She was involved in a lot of processes and decisions of which she felt her added value was limited. The team leaders could very well decide themselves.

You can use the delegation levels the other way around as well. The same manager was in a new role. The boundaries of her authority were blurred. She sometimes felt a lack of authority in areas she would have expected otherwise. Clearly the organization still needed to get used to the new role. In such a situation you can also use the delegation levels to clarify constraints upwards: discuss delegation levels on key decision areas with your manager.

Do you want to learn more about modern management? Attend one of our Management 3.0: Modern Leadership Practices classes.

Employee Empowerment demystified Part 1

/in , /door

Most organizations are aware that these times of high complexity and fast paced change are a challenge to cope with, especially for management. It’s not that traditional management techniques are wrong per se, but they are no longer the most appropriate way to face today’s complexity. So organizations are struggling to implement alternative ways of managing: Employee empowerment; servant leadership; decentralized decision making; delegation; self-organizing teams, these are all terms for the same concept: put the authority where the information is. The concept proofs to be pretty hard to implement however. This article is going to demystify empowerment and delegation as well as provide a simple yet powerful Management 3.0 tool that you can start using today.

The reason why empowerment is important is that it enables faster and better decision making. Today’s organizations operate in a complex environment. You cannot rely on following proven optimized processes because the work is not that predictable anymore. We often find ourselves doing things we haven’t done before. We need experts that can analyze complicated situations, and creative workers that know how to quickly create and validate ideas using experiments. These workers most often know the work better than their managers. So let them decide: decisions will be better because they know better. And they will be faster because the hierarchal chain of authority is short circuited.

Exploring principles of empowerment

So let’s assume we have an old school command and control type of manager, called Sam. Don’t blame Sam by the way, because it’s organizations and the education system that create and maintain Sams. Sam participates in a new management program in his company with the purpose of turning managers into servant leaders. Sam gets the reason why. He is enthusiastic about the change, a little anxious perhaps, but his guts tell him this is a more effective way. So he is going for it.

On Monday morning Sam gathers his team members telling them he is going to be a different manager. He will be facilitating and coaching the members from now on, and not be telling them what to do anymore. “I want you guys to be empowered”, he tells them. “You are a self-organizing team from now on”. While the team’s reaction was not as enthusiastic as he had expected, Sam is still confident and excited.

A few weeks go by and Sam is feeling increasingly frustrated. Things are not changing as fast as he had expected. He feels people could be more proactive. Why aren’t they taking initiative?! After all he has given them every room to do so. Why do they not seem to feel accountable for results? He has just told them what results he expects leaving the ‘how’ up to them, just as he was taught in the servant leadership workshop he attended. But it hasn’t led to better results yet. As a matter of fact, he was forced to step in a couple of times to correct mistakes that were made. He begins to feel that at least some team members cannot handle responsibility. Or maybe they just prefer to be controlled.

This is not an uncommon scenario. Agile coaches and Servant Leadership aficionados will tell you people want to have control over their own work. So why does it proof to be so cumbersome and slow to implement empowerment and delegation? Let’s unravel the principles of empowerment and delegation.

The first principle seems to be contradicting at first: Empowerment cannot be successful without clear constraints. “Wait a minute, empowerment was about giving people more control. So what are you talking about when you say you need to set constraints?” Delegation is never absolute, so unless you are very transparent which decisions people can make themselves and which they cannot, they will be reluctant to make any decision. People will feel insecure on making a decision not sure if it is really ok. They might take a backseat waiting for others to go first. They might be conspicuous whether the company really means it and will not blame them for the very first mistake they make as a result of a decision. Although it might sound contradicting, if you set clear boundaries and are very transparent on them, you create a safe environment for taking initiative.

Empowerment is reflexive. Delegation is not a one way street. It goes both ways. Employees have expectations of what they can leave up to the manager too. A team might not feel comfortable with a certain level of delegation for some area (yet), even if you do. As a manager you need to respect that. Delegation does not only go downwards. It goes up too.

Empowerment requires trust. And patience. When you say you are going to leave certain decisions to the employees, you better mean it. Don’t come rushing in with good advice the moment you see some hesitation. Trust them to get it sorted out. Even worse is blaming them for a mistake they are inevitably going to make. Instead of “What were you thinking?!” say “What can we do better next time?”. Your choice of words, no matter how subtle, is crucial. Your mental model might unconsciously lure you into choosing words that have a backwards effect. It will feel frustrating at times, it will test your patience, you will have to stop yourself from stepping in. Don’t get me wrong, I don’t mean just let them sink. You are there to help if they want it. But don’t take over. Trust goes both ways too: you need to trust the workers, but you need to live up to their trust as well. If you don’t the momentum is gone and they will not dare to take initiative anytime soon anymore.

Empowerment is an investment, it may take a while before you get your return on investment. Remember, people are wired for compliance. Not by nature, but by organizations and the education system. It starts as soon as children go to school: Suddenly you are required, both litterally and figurally speaking to color within the lines. Mistakes are structurally corrected. “Making a mistake is wrong” is the unconcious message. All day you are supposed to do what you are told. It gets even clearer when you start your first job. Others tell you what to do and how. All employee engagement programs set aside, people feel they are expected to comply. So when you are genuinely trying to change this in your organization, know it will take a while for people to change.

Understanding these principles is one thing, using them is another. In part 2 of this blog we provide a simple yet effective tool for delegation that honours the principles just discussed.

Do you want to learn more about modern management? Attend one of our Management 3.0: Modern Leadership Practices classes.