Archives

1st Conference 2015 – Evoking Excellence Through Agile Coaching

The presentation I delivered last year at  1st Conference 2015 titled “Evoking Excellence Through Agile Coaching” is available on Slideshare.

 

Do you have a real deadline?

Do not cross the lineThe first written record on the use of the word “deadline” was in 1864.  It was a the term to describe the line over which prisoners were forbidden to go –
Along the interior of the stockade, 19 feet from the stockade wall, was a line of small wooden posts with a wood rail on top. This was the “deadline”. Any prisoner who crossed the deadline could be shot by guards stationed in the sentry boxes. [1]
The words are quite literal – a line where it will make you dead.
Not all deadlines are bad.  But we must be careful on how often we impose them and for what purpose.  Many deadlines are largely unwarranted and generally harmful.
Deadlines can provide a sense of urgency and focus.  Goals without deadlines are dreams, so deadlines can reduce the amount of procrastination and avoid Parkinson’s Law.  And when deadlines are self-imposed, it can challenge us to get stuff done – there is a sense of achievement on getting a job done in record time.  Deadlines used with the right mindset can help teams really focus on what is important and what isn’t.  With the right mindset, it facilitates bias towards action and help us prioritise so we are doing the important things for the customer and help identify wasteful (corporate) activities so we can improve and eliminate.
When used judiciously, deadlines can get an important piece of work over the line as it focus teams on production.  However, if this is forcing the pace of work that causes burnout, bad things start to happen.  Agile processes promote sustainable development
“The sponsors, developers, and users should be able to maintain a constant pace indefinitely” – Agile Manifesto.
Deadlines used as an extrinsic motivator and holding a threat for unclear purposes is dangerous to our modern way of working as it imposes fear.
In a complex environment we do not know and cannot predict what will happen when we do action ‘ABC’ and there are many possible actions that we could do.  So when promises of dates are made early on, it causes a ripple effect as people will start setting deadlines off your deadline and it becomes self-reinforcing.  As a result of this you remove a lot of options for adaptation and unexpected events.
There are deadlines that have a “real” business impact or have an actual business consequence for failing to meet the deadline.  For instance, meeting an regulatory reporting requirement (eg APRA in the Australian Financial Industry, or Sarbanes-Oxley)  or studying for an exam.  There is little value in finishing something for an event (eg trade show) or holiday special (Mother’s Day) after the event.  The “Y2K Bug” is also another example of a real deadline.  Anything where the value of completing the work drops significantly or disappears altogether is a real deadline.  If the work is still mostly valuable if you get it done after the deadline, you probably have an arbitrary or “perceived” deadline pretending to be a “real” deadline.
A genuine deadline tells you “If we don’t get done by the deadline, there’s not much reason to get it done at all and we should stop”.  These type of deadlines, whilst are valid, they are actually not that common.
“Perceived” deadlines are actually the most common. There is a very significant difference between real deadlines and perceived deadlines.  Perceived deadlines tend to arise from questions like “How long do you think this will take?” or “Do you think we could have this by [date]?”.  They exist to keep work (eg a project) from going on indefinitely and create an arbitrary line in the sand where people can expect delivery.
Often these deadlines are a result of setting expectations, often very early on based on long-term or coarse grained estimates, and estimates of that sort are never accurate.  We are bad estimating – experience and scientifically it has been repeatedly shown that getting accurate estimates is extremely difficult, if not impossible.
The real problem with deadlines, is that any deadline longer than a day or two you are asking people to fail.  What you are really measuring with deadlines is the ability to estimate. If you are trying to convince people to get something by a deadline, the only way they could get something done by a deadline is by getting better and better at estimating.  This is something you cannot do, even with experience.  [2]
In a complex world where you can’t predict the future of doing ‘ABC’ you are constantly punishing people for something they can’t get better at.
Deadlines based on annual budgeting and financial cycles is also a type of perceived deadline.  Teams working towards nominal end date (or start date) that aligns with the financial year is also nonsensical as customers do not operate (and don’t really care) when you make your investments and how you fund and capitalise work.
The best way to determine if you have a perceived deadline is to ask the question, “What will happen if we miss this deadline?”  If the answer is mainly, “people will be disappointed”, “someone promised that date to the market” or “we already announced that date” then you probably have an arbitrary deadline with no actual business impact on it.  Many of these deadlines are actually wishful thinking or commitments made on behalf of others doing the work based on theoretical plans and no evidence of actual production work.  There is little surprise why we have missed expectations and the ensuing conflict and confusion on why things never get done “on time”, why the quality of the product isn’t better and why we don’t have time to improve.
These perceived deadlines tend to cause undue stress on teams for no particularly good reason.  This creates short-term thinking and approaches aimed at getting across a finish line with little sense of what comes afterwards.  Heroics are often required to get things done and the product is sub-optimised as quality is sacrificed as hidden technical debt is accumulated which are rarely quantified or explained.
Jim Benson, author of Personal Kanban, has been credited with the diagram attached – deadlines as influencers of ‘crap’.  Simply put – as your deadline approaches your options are reduced and you choose options to fit the deadline rather than satisfy your customer.
DeadlinesAndCrap
In the novel, The Phoenix Project this common situation was aptly portrayed –
I’ve seen this movie before.  The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers.  Them you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment.  And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.
A much better way to get a predictable timeline is to make projections based off the team’s actual metrics of progress and constantly adapt based on new information.  That’s why agile promote working solution/product (ie shippable state) as a measure of progress.  We need to act our way to the future, rather than plan or guess our way to the future.  We should only commit at the last responsible moment.  Never commit early unless you know why (ie have you got a real deadline such as an “AFL Grand Final moment”).
Not all deadlines are bad but next time before setting a deadline please consider why you are imposing the deadline and what is the real need for that deadline.  Be on the look out for a perceived deadline acting as a real deadline as these will undermine teams with a constant push towards an illusory goal resulting in sub-optimal results, poor customer and business outcomes.  And along the way, hopefully we will reduce the number of times people crossing the deadline being shot.
[1] Reading 1: Andersonville Prison, https://www.nps.gov/nr/twhp/wwwlps/lessons/11andersonville/11facts1.htm
[2] Jabe Bloom, Beyond Deadlines, https://vimeo.com/52255565

Leaders need to focus on providing Clarity and Competence, not control

Self-organising teams is the antithesis to hierarchical structures that exist in many organisations.  Traditional leadership required a strong leader to take control, attract followers and make it happen.  Modern leadership is about leaders giving control and creating leaders.

Self-organisation requires autonomy and control to be given to teams.   This includes trusting individuals to figure out how to solve problems, make decisions and how to best get work done.  With knowledge work the best decisions are those in teams who are closest to the information and customers.  However, structure, policies, processes and hierarchy often take the decision making away from these teams.

clarity and competenceIn his book, Turn The Ship Around!, nuclear submarine Commander David Marquet describes how control was given to the ship’s crew.  It required each member of the team to improve his or her technical competence and have a clear understanding and clarity of the organisation’s driving purpose:

Competence:   Provide teams with the tools and technical competence to get the job done; create the environment for thinking.

Clarity:  Define and communicate the organisational intent so everyone is clear on the vision, goals & objectives.  Everyone understands what is the right thing to do.
As a leader you trust the teams are competent and have clarity of vision.  Individuals have the freedom to adjust actions and make decisions in line with the vision and intent.

So what does this mean for a leader in today’s ever fast changing world?

If leaders do not believe individuals are competent and have clarity of vision, the leaders should fix THAT rather than remove power by putting in more controls or structure.
As a leader your job is to ensure people have clarity of vision and the competency needed to succeed.

If leaders don’t believe individuals can understand the vision or pick up the skills, why did the leader bring them in the first place?  And if there is a competency gap, why did the leaders not mentor or provide training?  We all have the extraordinary meta-skill to learn and acquire new skills.   If people do not have the competence, the role of leaders is to mentor, give people training and provide the environment for learning.

We’re here to change the world – Reflections on Agile Australia 2015

agileaus“You are not here to build software. You are here to change the world” were the words used by Linda Rising at her Keynote that was attended by 1100 attendees at the 7th Agile Australia Conference in Sydney last month.  In today’s world, you can’t stay still.  Nigel Dalton cited Charles Darwin when he said
It is not the strongest species [organisation] that survives, not the most intelligent, but the one most responsive to change.
Things are evolving fast and we live in an unpredictable, complex business environment.  We need to change the world!
There were a number of great topics presented and this year found it harder to prioritise what to attend.  This was my 7th Agile Australia Conference and looking back at the very first Agile Australia conference, the industry has evolved and changed a lot over the years.  The first conference was dominated by a few players (the early adopters in Australia) and consisted of 29 sessions hosted in 2 parallel streams with 350 attendees.  In 2015 there were 56 sessions, 5 parallel streams and with 1100 attendees.  It was a pleasure to be a Chair at the conference again this year with the stream ‘Build Measure, Learn’ with my co-chair Paula Ngov and help contribute to the program.
Agile Australia Attendees

Agile Australia Conference Attendees 2009 to 2015

Over two jam packed days, there were a lot of new ideas to experiment with but there were also some basics to cater for those just starting out on their agile journey. The vibe at the conference is that Agile is no longer a fad and is transforming across the wider organisation – we have crossed the chasm from IT agility to business agility. However, speaking with people from the trenches there are still many struggling to get the benefits of agile with existing hierarchical management style at odds with the horizontal product delivery focus of agile. James Shore summaries this well when he said

agile is about how you think and that organisation thinking overrides team thinking. Therefore success with agile depends primarily on organisational culture and investments.

Here’s some highlights from the conference:

David Marquet (@ldavidmarquet) – Intent-based leadership

David Marquet is a former nuclear submarine commander and author of the book ‘Turn the ship around‘. His opening Keynote looked at the future of Leadership.

  • In the future leaders will get people to think (not do)
  • In the future Leaders will help people feel safe (not scared)
  • In the future leaders will push authority to information (not information to authority)
  • People doing the work can make better decisions because they have the information. You will get better speed of execution because you don’t have a delay.
  • In the future leaders will focus on getting better (not being good)
  • In the future leaders will fix the environment (not the people)
  • In the future, leaders will give control & take leadership
    • The only thing hard about this is you, we have been genetically and culturally to take control and attract followers. What you want to do is give control and create leaders.

During his keynote, David did a live poll of the audience on what it would like to work in an environment where the leadership style meant controlling people . I hope the managers and leaders in your organisation are not creating a work environment like this….

davidmarquet

What working under a leadership style that meant controlling people, David Marquet

 

Jeremie Benazra (@jemben) – How forgotten knowledge will help you avoid regrettable decisions

Jeremie’s presentation took a interesting look at turning some common questions we may face into reality checks using some common principles that we know today. Whenever we make decisions we need to be grounded (and often reminded) that there are certain principles that may challenge our biases.

Principle Question you want to ask Question you should be asking
Moore’s Law: Information systems doubles capacity for the same price every two years “Which technology is the best to invest in now?” “How long do we want to maintain the product using this technology?”
Allen’s Curve: The communication efficiency decreases exponentially with the physical distance between the persons “How much could I outsource?”Or what I come across a lot is a statement that “outsourcing is cheaper”. “How much effort are you ready to dedicate to make outsourcing work?”
Parkinson’s Law: Work expands so as to fill the time available for its completion “How long do you need to get this done?” “Do you have any time constrain? What is your deadline?”
Little’s Law: The lead time is proportional to the number of items in the system and their time in the system. “Tell me when I could expect to get this done as well?” “How urgent is it compare to what is currently in progress?”
Meskimen’s Law: There is enough time to do it right, but there is always enough time to do it over. “How complete are you?  How far along are you?” “Could you help me clarify what we consider complete?”
Brooke’s Law – The Mythical Man Month: Adding manpower to a late software project makes it later. “How many people do you need to get this Done? Faster! “What are you ready to trade off, scope?”
Conway’s Law: Organisations are constrained to produce designs which are copies of their communication structures “How could you improve our customer experience?” “How could we remove some organisational silos to work better together?

Bernd Schiffer (@berndschiffer) – Concrete experimentation in Agile environments

Bernd talked about a problem that many organisations face today, struggling turning change ideas into tangible outcomes so they get better at being Agile. What we need is a way to use experiments to drive change throughout the organisation and Bernd introduced a nice mnemonic to help us remember how to perform an experiment to drive change and improvement – CAT SHOE, SIC! It’s really simple of course:

cat shoe sic

CAT SHOE, SIC!, Bernd Schiffer

  • Clear goal – what are the outcomes you want to achieve
  • Arranged – A plan how you will approach the experiment
  • Trackable through metrics – measure the improvement/change. did it have an impact?
  • Small – make small incremental experiements, short timeframe, small/one team.
  • Has due date – do I need to say more? timebox the experiment
  • Out in the open – make the experiment visible eg use ganban boards
  • Evaluated through hypothesis – leveraging the lean startup approach, what hypothesis are you trying to prove? what does success look like? what does failure look like?
  • Safe-To-Fail – it is an experiment after all so we need to take some risks, but balance risk taking with impact if it fails. You need to be able to recover (and learn) from failure
  • Impelled by champions – need people (1 or 2) to sponsor and champion the experiment – they will own the outcome and be impelled to make it happen
  • Communicated before start – be transparent and make sure everyone understands and is comfortable with the experiment before starting

Stuart Bargon (@StuartBargon) – Don’t scale Agile. Descale your organisation.

With many talks about scaling agile and lots of conversations in the industry about applying agile in the large enterprises, its easy to forget what makes agile successful. Enterprises often scale by watering down agile.  So it was refreshing to see a talk about descaling the organisation.   Stuart described how Fairfax Media, one of Australia’s oldest public companies transformed its Domain Group business to be a focused, nimble, growing and Agile company.
domain

Descale your organisation, Stuart Bargon

Of note, when Fairfax Media formed Domain Group, they moved PMO across but then moved it back into Fairfax Media.  From the image, you can see from the new structure the PMO were no longer needed as the decisions that was traditionally done by the PMO is now taken on internally by the Product Development Teams (circled in green) as they are closer to the information.  Not only did they descale the organisation, the descaled the need for coordination/projects by making teams responsible for a product area and are largely independent of each other.  To enable teams have this autonomy, they made some investments to descale their technology and introduced microservices.  The decoupled technology removed the tight coupling/dependencies between teams so they can be autonomous and release independently.

Anders Ivarsson (@anders_ivarsson) – Autonomy and Leadership at Spotify

Whilst Anders said that the “the Spotify model” never intended as a model, many teams and organisations are trying to adopt their way of organising into squads, chapters, tribes and guilds.  The “model” is a snapshot of how they work at a given time and is constantly evolving.  Details of the model (as of 2012) can be found in the document Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds, and in the videos Spotify Engineering Culture (as of 2014) Part 1 and Part 2 .
Anders reinforced some earlier messages in the conference that success is all about the team and leadership is all about supporting the team – it is the leadership behaviours that is important – not a role.  “POTLAC” is the leadership at Spotify – Product Owner, Chapter (Team) Lead, Agile Coach.
Although many will see “the Spotify model” as a poster child for how to be agile and therefore don’t need any coaching, one notable importance is that Spoitfy values the role of the Agile Coach.  Every team has an coach.  There is no end to the Agile Journey and Spotify is alway improving – “Improve Everything”.   The role of the Agile Coach is important to support the squad and teams on their journey towards high performance and continuous improvement.
Anders emphasised the importance of having a mindset of not letting stupid things get in the way and paramount is having a kickass engineering discipline.
spotify

Spotify Agile Coach, Anders Ivarsson

Linda Rising (@RisingLinda) – Myths and patterns of organisational change

Linda is the author of several books, the most notable being Fearless Change – Patterns for Introducing New Ideas.  Just like Design Patterns from the Gang of Four, Linda has introduced some patterns as way to address recurring problems with organisational change.  There are some cognitive biases that prevent us from introducing new ideas and she tackled these through demystifying these myths and their pattern for change and influence:
Myth Pattern for Change
Myth #1: Smart People are rational

  • Most people make decisions that are not rational or for logical reasons.  In reality rational arguments with reasons, benefits and decision tables do not convince people. No matter how well you explain things to people, people don’t buy-in.
  • None of our decisions are rational, but we are good at explaining decisions once a decision has been made – a process called rationalisation.
Take on a role of a Evangelist.You need to believe and have a passion for the change.  What you have is your belief that your idea is a good one and that it will work.Create short term goals – build on your successes and learn from your failures – do small experiments, just do it, time for reflection, baby steps.
Myth #2: Good always triumphs over evil. (Just World Fallacy, one of our many cognitive biases.)

  • My idea is so good, that should be enough.
  • There is a belief that truth, justice and good should win.
Do Food.
Data clearly shows, that when we are eating we are more open to influence.All languages speak to this connection.  When we eat together, there’s a feeling these are the people we trust – its a great influencer even if its a bad idea.
Myth #3: If I just had enough power I could make people change.

  • People believe that they can tell people what to do, and if they don’t they can just fire them.
  • This is an illusion, this does not make real change.  Forcing people to change, you may get compliance (or appearance of compliance).  What you want is real change.  We want people who are passionate about and care about it.  We want people to have real commitment, and you can’t get this with an edict.
Personal Touch.You must address a genuine user need.  Data does not equal empathy.  You need to reach out and try to understand the viewpoint of people who you want to change and give them a reason (sell your idea as a way for them to be better).Different people accept new ideas differently, so you will need to address people differently and answer the “What’s in it for me?” and bring them along the journey.
Myth #4: Skeptics, cynics, resistors—THOSE people, well, they must be BAD or STUPID or BOTH!! Ignore them!!

  • We label people as THOSE people.  This ends up dividing the world up.
Fear LessUse resistance to your advantage.
Listen, really listen and learn all you can, even from the cynics.  Respect and build on the resistance.Find a Champion Skeptic: Encourage a resistor to play the important role of “Devil’s Advocate.”  Treat the person as valued partner in the change effort.  Get them to help get better.
Myth #5:You’re a smart person, so you don’t need help from others. After all, it’s your idea! Ask For HelpThe idea is yours and you believe in it, but the change must NOT be “all about you”.You need other people’s help.  And when others help you, recognise their contribution with Sincere Appreciation – this is a powerful influencer!  The thanks must be sincere, timely, contain details of what they did and the impact of their help.
What pattern will you use to change?
Linda was very generous with her busy travel schedule and joined us at the Agile Coaching Circles Meetup the following day in Melbourne.

Final words…

There were some good talks about DevOps to reduce time to market, improve quality and improve resilience to enable business agility and enablers of the digital disruption.
Embracing failure and having an experimentation mindset was a common theme with several speakers advocating “fail and learn early”.  In a complex situation you need to create environments and experiments that allow patterns to emerge.
A popular session was a talk on how Daniel Pink’s Drive was used to create an amazing culture where autonomy, mastery and purpose was used to drive happiness and productivity.  It’s not about motivating people, it’s about leaders creating an environment where people just want to do it – turn work into play.
Many talks focused on working in a lean fashion and being totally focused on delivering value to customers using concepts such as A/B testing, lean startup and customer driven development.  Irene Au who was Yahoo’s VP User Experience and Google’s Head of User Experience talked about the importance of design and encouraged everyone to be a designer.
It was pleasant to catchup with old friends but to meet new ones as well whilst at the conference.  The heart of agile is always about improvement & change – it’s a journey that never ends.  Organisations are insanely complex that there is not one solution that works – you need to target the change to your organisation.  You need to bring the agile principles into your work environment and make them what you need them to be.
Overall, there was a great buzz about the conference, with lots of conversations and I think many walked away being inspired to change the world.

Leadership styles

Donald Gray has written a great and interesting article on Three Leadership Styles, based observations on managing traffic at an intersection.  In the article the most successful leader is the one that sees people as “adults that most of the time they can take care of themselves, and that the role of a manager is to support these competent adults”.  To be effective, the leader should not place themselves at the center of the management task so that they can be much more flexible and effective at the key management activities.   A must read.

As Work Changes, So Must Managers

Here is an article published in The Wall Street Journal earlier this year which is very relevant to today’s rapidly changing environment and the role of managers on Agile Projects.
(Mark Hurd who was my former CEO at HP is mentioned in the article)

What is a manager?

In simplest terms, a manager is someone who organizes a group of people to accomplish a goal. It is a job as old as the human race.

As an academic discipline, management is much younger. Frederick Winslow Taylor is often cited as the founder of management studies. His 1911 book “The Principles of Scientific Management” portrays managers as organizers: they arranged cogs in the industrial machine. Their job was about increasing efficiency and productivity. For Taylor, management “studies” meant standing in a workplace with a stopwatch, measuring workers’ actions, and devising ways to eliminate “all false movements, slow movements and useless movements.”

But in the years since World War II, the nature of work has changed. Peter Drucker was the first to clearly capture the difference.

In 1959, Drucker used the phrase “knowledge worker” – referring to people whose work primarily involves the manipulation of information and knowledge, rather than manual labor. The knowledge worker’s contribution to an enterprise couldn’t be measured with a stopwatch or a punch card. It couldn’t be forced or controlled by any amount of oversight. And it couldn’t be encouraged by simple pay schemes tied to hourly output.

Carlos Ghosn, CEO of Nissan Motor Corp., explains how he got buy-in for major layoffs in Nissan’s turnaround. From an interview 11/17/09.

Drucker broke the manager’s job down into five pieces. A manager, he wrote:

Sets objectives. He or she is responsible for determining what the overall objective of the group is, sets goals for each member of the group, and decides what needs to be done to reach those goals and objectives.

Organizes. He or she divides the work into achievable chunks, and decides who must do what.

Motivates and communicates. The manager creates a team out of the workers, so that they can work together smoothly toward a common goal.

Measures. The manager creates yardsticks and targets and determines whether they are achieved.

Finally, a manager develops people. In Drucker’s world, people aren’t interchangeable cogs; they are individuals who must be trained and developed to achieve the full power of the organization.

To be a good manager in today’s world, you must also be a good leader. It is not enough to give employees directions. Managers must also give them purpose.

What exactly does that mean? In his 1989 book, author Warren Bennis listed differences between managers and leaders. Among them:

  • The manager administers; the leader innovates.
  • The manager focuses on systems and structure; the leader focuses on people.
  • The manager relies on control; the leader inspires trust.
  • The manager has a short-range view; the leader has a long-range perspective.
  • The manager asks how and when; the leader asks what and why.
  • The manager imitates; the leader originates.
  • The manager accepts the status quo; the leader challenges it.
  • The manager does things right; the leader does the right thing.
  • The modern manager’s challenge is that you must do all of the above. It’s an awesome but essential task. Managing without leading is a recipe for failure.

Attempting to lead without actually managing is disastrous as well. Many managers have met their downfall by setting an ambitious vision for their organization, and then assuming someone else would execute it.

“One characteristic of the successful dreamers I think of – Francis Ford Coppola, Steve Jobs – is that they also have remarkably deep understanding of the industry they work in and the people they lead, and they often are willing to get very deep in the weeds,” writes Stanford Professor Robert Sutton. “This ability to go back and forth between the little details and the big picture is also evident in the behavior of some of the leaders I admire most,” he says, mentioning Anne Mulcahy, chairman of Xerox; Bill George, former CEO of Medtronic, and Mark Hurd, the CEO of Hewlett-Packard.

These truths don’t just apply to CEOs. They also apply to the millions of middle managers who make up the core of any large organization.

Middle managers, of course, are not masters of their own fate. Unlike a Mulcahy or a Hurd or a Jobs, they must carry out an agenda that someone else has set for them. They may bear a heavy load of responsibility, but they have limited room for freedom of action.

A decade ago, the Journal’s Jonathan Kaufman captured the challenges of modern middle management by shadowing the manager of an Au Bon Pain bakery caf named Richard Thibeault. The 46-year-old Mr. Thibeault, a former factory worker, had always thought becoming a “manager” would mean he had arrived in the world. He would sit behind a desk, work 9 to 5, and be a pillar of the community.

Instead, he found he had to rise each day at 3 a.m. to bake muffins, prepare soups and fret over his store’s falling sales. Instead of the steady hours he enjoyed in the factory, he often put in as much as 70 hours a week. His job was an odd mix of broad responsibility and limited authority. He trimmed staff in order to meet corporate cost-cutting targets, but was not allowed to cut prices in order to attract needed customers.

“Some days I think maybe I should go back to factory work,” he told Kaufman. “It was easier.”

Yet for all their frustrations, middle managers in today’s well-run organizations often find they are given surprising responsibilities. They may find themselves heading up a team whose tasks involve not just following orders, but solving a knotty problem or developing a new product. They will be asked to innovate, to challenge the status quo.

Middle managers often find themselves heading projects that involve others who don’t directly report to them. Giving orders won’t cut it. Middle managers, even more than CEOs, must exercise influence without clear authority.

They must learn, in other words, to be leaders – the topic of our next column.

%d bloggers like this: