Transforming enterprise IT from a cost center to a strategic asset delivering critical business value.
Thursday, April 26, 2012
Executive Guide to Peer Coaching
You have decided to
go agile. You have delegated the responsibility to your staff. What should you
do now?
A peer (fellow executive) approaches you from the business. They are upset. They have been told the team is doing their development is pairs. Your peer says, “Do I have to pay for pairing”?
Your organization has been doing agile for 6 months. Teams are functioning well and software is releasing quickly with high quality. Your peer says, “Your quality is too high, I would like to pay less and am willing to lower quality”.
Another peer approaches you and says, “Your teams are too ridged, they insist on using the agile practices, I need teams that are willing to compromise”.
How do you respond to these comments? More importantly, why are your peers making these statements to begin with?
Some companies subscribe to the myth that anyone can be a good executive if they know how to manage relationships, have executive presence and shape perceptions. Knowledge of your domain, practices, skills or technology isn’t necessary. Such organizations have a difficult time with excellence. Projects and transformations are frequently started but many stall and fail. Such companies are littered with projects that never completed successfully. It can be very difficult to lead what you don’t understand.
In the previous post, I identified a number of reason’s executives don’t coach their peers. In this post we will focus on what will happen if you don’t coach and more importantly, what sort of coaching you should provide to your peers.
Looking at the first comment, the misperception is that it will take a pair just as long to complete a card as one person. Having two developers complete a card means they have to pay more for development. The person who made the comment is revealing his or her lack of knowledge of pairing. It is also an indication that the person making the comment has received insufficient, if any coaching.
A properly coached peer will know that a pair will complete a card in nearly half the time. That is because the bottleneck to development isn’t the number of keyboards or the typing speed of developers, it is problem solving. Two heads will solve a problem faster than one. The solution will be cleaner and require less lines of code. Given that two eyes have reviewed the code in real-time, the code will have significantly less defects. Thus, the pair is more likely to work on a new feature tomorrow instead of fixing what they broke today.
In addition, the knowledge transfer between team members will spread like a virus. This relates to the product, business domain, source code, practices and use of the tools. A new person in a pair can be effective nearly immediately instead of the six months it takes a person sitting in a cube.
Thus, an informed peer instead of expressing fear over additional costs should be pleased with the money and time saved because the team is effectively pairing. This is a much more enjoyable conversation to have.
As you can see, there is sufficient coaching that needs to take place to prepare your peers for the transformation to agile. If this is not done, the misunderstanding will lead to significant waste. It may also make your staff gun-shy. No one wants to make enemies in the executive ranks.
The second comment is amusing. We have learned that defects add to cost. The later you find defects, the more it costs to fix them. To lower cost you find and fix defects sooner or prevent them to begin with. The practices that are used to bring about a reduction in defects reduce cost and ensure that the team can spend all of its capacity delivering new features and not fixing yesterday’s mistakes. I am unaware of any test methodology that allows one to filter on defects by severity or impact when developing software. Mistaking proofing development is an effective way to reduce cost and increase a team’s productivity.
The person making the comment has revealed his or her lack of understanding of quality. They visualize and extended period of time to do additional testing. It is visualized that every defect on the list found late in the process much be fixed. For this reason, it is determined that it cost more to have high quality.
Such a person has never been coached with regards to the impact of pairing, test driven development, acceptance criteria and acceptance test drive development. It is unlikely your peer is aware of the automation of regression test thus regression tests are run daily. These practices enable software to be delivered with quality, faster and at a lower cost. But how are they to know if you did not provide coaching?
Are you prepared to coach your peer past these misconceptions? Better yet, are you able to anticipate this type of confusion and provide the coaching needed prior to the transformation?
The last comment is code for, “I don’t want to have to change the way we work. Can’t your agile team follow our process”?
Such a request is rooted in ignorance. Understanding agile and the benefits it brings has never been presented to your peer. If executives don’t understand agile, they will take such a comment at face value. They will decide that compromise is good and that the agile teams are being ridged. Such feedback can bring an agile transformation to a halt or destroy the effectiveness of teams that are already highly functioning.
Why would you want to compromise on cost, schedule, scope and quality? All should be motivated to bring the most value to the business at the lowest coast, shortest time, with the most features and highest quality. It is not about compromise, it is about continuous improvement. It has to be led by effective coaching.
Perhaps the most important coach in an agile and lean transformation is the executive coach. An enterprise agile and lean transformation needs a champion that has the clout to bring his or her peers up to speed to ensure the transformation occurs and is sustainable. Such coaching must come from at least one executive champion. Organizations are dynamic. Leaders come and go. Until the transformation becomes part of the organizations DNA, it requires an executive coach. An executive coach’s job is finished when his or her coaching is no longer needed. It is no longer needed when the system is in place and staffed by an organization where everyone coaches.
A peer (fellow executive) approaches you from the business. They are upset. They have been told the team is doing their development is pairs. Your peer says, “Do I have to pay for pairing”?
Your organization has been doing agile for 6 months. Teams are functioning well and software is releasing quickly with high quality. Your peer says, “Your quality is too high, I would like to pay less and am willing to lower quality”.
Another peer approaches you and says, “Your teams are too ridged, they insist on using the agile practices, I need teams that are willing to compromise”.
How do you respond to these comments? More importantly, why are your peers making these statements to begin with?
Some companies subscribe to the myth that anyone can be a good executive if they know how to manage relationships, have executive presence and shape perceptions. Knowledge of your domain, practices, skills or technology isn’t necessary. Such organizations have a difficult time with excellence. Projects and transformations are frequently started but many stall and fail. Such companies are littered with projects that never completed successfully. It can be very difficult to lead what you don’t understand.
In the previous post, I identified a number of reason’s executives don’t coach their peers. In this post we will focus on what will happen if you don’t coach and more importantly, what sort of coaching you should provide to your peers.
Looking at the first comment, the misperception is that it will take a pair just as long to complete a card as one person. Having two developers complete a card means they have to pay more for development. The person who made the comment is revealing his or her lack of knowledge of pairing. It is also an indication that the person making the comment has received insufficient, if any coaching.
A properly coached peer will know that a pair will complete a card in nearly half the time. That is because the bottleneck to development isn’t the number of keyboards or the typing speed of developers, it is problem solving. Two heads will solve a problem faster than one. The solution will be cleaner and require less lines of code. Given that two eyes have reviewed the code in real-time, the code will have significantly less defects. Thus, the pair is more likely to work on a new feature tomorrow instead of fixing what they broke today.
In addition, the knowledge transfer between team members will spread like a virus. This relates to the product, business domain, source code, practices and use of the tools. A new person in a pair can be effective nearly immediately instead of the six months it takes a person sitting in a cube.
Thus, an informed peer instead of expressing fear over additional costs should be pleased with the money and time saved because the team is effectively pairing. This is a much more enjoyable conversation to have.
As you can see, there is sufficient coaching that needs to take place to prepare your peers for the transformation to agile. If this is not done, the misunderstanding will lead to significant waste. It may also make your staff gun-shy. No one wants to make enemies in the executive ranks.
The second comment is amusing. We have learned that defects add to cost. The later you find defects, the more it costs to fix them. To lower cost you find and fix defects sooner or prevent them to begin with. The practices that are used to bring about a reduction in defects reduce cost and ensure that the team can spend all of its capacity delivering new features and not fixing yesterday’s mistakes. I am unaware of any test methodology that allows one to filter on defects by severity or impact when developing software. Mistaking proofing development is an effective way to reduce cost and increase a team’s productivity.
The person making the comment has revealed his or her lack of understanding of quality. They visualize and extended period of time to do additional testing. It is visualized that every defect on the list found late in the process much be fixed. For this reason, it is determined that it cost more to have high quality.
Such a person has never been coached with regards to the impact of pairing, test driven development, acceptance criteria and acceptance test drive development. It is unlikely your peer is aware of the automation of regression test thus regression tests are run daily. These practices enable software to be delivered with quality, faster and at a lower cost. But how are they to know if you did not provide coaching?
Are you prepared to coach your peer past these misconceptions? Better yet, are you able to anticipate this type of confusion and provide the coaching needed prior to the transformation?
The last comment is code for, “I don’t want to have to change the way we work. Can’t your agile team follow our process”?
Such a request is rooted in ignorance. Understanding agile and the benefits it brings has never been presented to your peer. If executives don’t understand agile, they will take such a comment at face value. They will decide that compromise is good and that the agile teams are being ridged. Such feedback can bring an agile transformation to a halt or destroy the effectiveness of teams that are already highly functioning.
Why would you want to compromise on cost, schedule, scope and quality? All should be motivated to bring the most value to the business at the lowest coast, shortest time, with the most features and highest quality. It is not about compromise, it is about continuous improvement. It has to be led by effective coaching.
Perhaps the most important coach in an agile and lean transformation is the executive coach. An enterprise agile and lean transformation needs a champion that has the clout to bring his or her peers up to speed to ensure the transformation occurs and is sustainable. Such coaching must come from at least one executive champion. Organizations are dynamic. Leaders come and go. Until the transformation becomes part of the organizations DNA, it requires an executive coach. An executive coach’s job is finished when his or her coaching is no longer needed. It is no longer needed when the system is in place and staffed by an organization where everyone coaches.
Friday, April 20, 2012
Executive Guide to Transformation Coaching
Coaching
is one of the hardest skills for an executive to learn.
Why?
The answer I
believe is revealing. Most executives are convinced they know what they are
doing. In his or her mind, it is the rest of organization that needs to change.
Given that
executives excel at building relationships and managing perceptions perhaps
most executives believe their own spin.
This state of
denial is a blind spot that blocks many an agile and lean transformation. Isn’t
the first step to change, recognition of the problems?
By believing it is
“their” problem, the executive overlooks an important part of the
transformation, the transformation of oneself.
Think of the
discontinuity that will arise. You are asking your staff to change their
behavior. Not only will this impact your organization, it will impact
neighboring organizations.
Remember, the
culture that is in place, the one you are trying to transform, was put in place
by the leaders (i.e., you or your predecessors). The current system (i.e., the way work is
done) is primarily responsible for the organizations struggles. It is the
leaders that are primarily responsible for the state of the current system.
Understanding agile
and lean leads one to understand the importance continuous improvement via root
cause analysis. Too many organizations are driven by a culture of blame. If
something goes wrong, someone is to blame. An executive must recognize it is
the current system that is the root cause of most of the current dysfunction. To
move from a culture of blame to a culture of continuous improvement requires
the elimination of fear. Removing the fear from ones organization does not
happen overnight and will not happen at all if the executive does not change.
OK, so you are an
executive and you have come to understand that the current system is the main
contributor to poor productivity and or quality. What next? You need to coach
your peers!
Too many executives
attempt transformation and look to their subordinates to drive the change. When
their staff hits against the existing corporate system, the executive is
nowhere to be found. When an executive from a neighboring organization complains
or blames any person attempting to drive transformation the executive’s backing
is critical. Backing your people as they execute the transformation shows you
have skin in the game. Not to support your people is to bring the
transformation to a screeching halt.
Your role as coach
is to first coach your peers. This is essential if the transformation is to succeed.
Your peers need to be educated about the transformation. They need to know what
to expect, why the change is necessary and the results and benefits the
transformation will bring. Collectively, you can determine the impact to the neighboring
organizations and what if any coaching is required. When things go wrong, the
leadership needs to bring an end to blame. Instead the leadership needs to
coach how to drive continuous improvement via root cause analysis.
As you can see the
best transformation starts from the head. The executive educates oneself then
learns to coach one’s peers. Collectively, the leaders of the organization can
then begin to coach their organizations.
It is a rare
executive that has the insight and courage to first transform oneself then
become an agent of change by coaching one’s peers. Transformation is hard.
Transformation without support from the top is impossible. It will have limited
success at best and any progress made is likely to be short lived.
Transformation from
the top brings about sustainable transformation. What kind of executive are
you?
Why?
The answer I
believe is revealing. Most executives are convinced they know what they are
doing. In his or her mind, it is the rest of organization that needs to change.
Given that
executives excel at building relationships and managing perceptions perhaps
most executives believe their own spin.
This state of
denial is a blind spot that blocks many an agile and lean transformation. Isn’t
the first step to change, recognition of the problems?
By believing it is
“their” problem, the executive overlooks an important part of the
transformation, the transformation of oneself.
Subsequently, such an executive also ignores
the transformation of one’s peers.
Think of the
discontinuity that will arise. You are asking your staff to change their
behavior. Not only will this impact your organization, it will impact
neighboring organizations.
Remember, the
culture that is in place, the one you are trying to transform, was put in place
by the leaders (i.e., you or your predecessors). The current system (i.e., the way work is
done) is primarily responsible for the organizations struggles. It is the
leaders that are primarily responsible for the state of the current system.
Understanding agile
and lean leads one to understand the importance continuous improvement via root
cause analysis. Too many organizations are driven by a culture of blame. If
something goes wrong, someone is to blame. An executive must recognize it is
the current system that is the root cause of most of the current dysfunction. To
move from a culture of blame to a culture of continuous improvement requires
the elimination of fear. Removing the fear from ones organization does not
happen overnight and will not happen at all if the executive does not change.
OK, so you are an
executive and you have come to understand that the current system is the main
contributor to poor productivity and or quality. What next? You need to coach
your peers!
Too many executives
attempt transformation and look to their subordinates to drive the change. When
their staff hits against the existing corporate system, the executive is
nowhere to be found. When an executive from a neighboring organization complains
or blames any person attempting to drive transformation the executive’s backing
is critical. Backing your people as they execute the transformation shows you
have skin in the game. Not to support your people is to bring the
transformation to a screeching halt.
Your role as coach
is to first coach your peers. This is essential if the transformation is to succeed.
Your peers need to be educated about the transformation. They need to know what
to expect, why the change is necessary and the results and benefits the
transformation will bring. Collectively, you can determine the impact to the neighboring
organizations and what if any coaching is required. When things go wrong, the
leadership needs to bring an end to blame. Instead the leadership needs to
coach how to drive continuous improvement via root cause analysis.
As you can see the
best transformation starts from the head. The executive educates oneself then
learns to coach one’s peers. Collectively, the leaders of the organization can
then begin to coach their organizations.
It is a rare
executive that has the insight and courage to first transform oneself then
become an agent of change by coaching one’s peers. Transformation is hard.
Transformation without support from the top is impossible. It will have limited
success at best and any progress made is likely to be short lived.
Transformation from
the top brings about sustainable transformation. What kind of executive are
you?
Tuesday, April 17, 2012
Executive Guide to Removing Blockers
With all the success and benefits demonstrated by companies with
effective agile and lean teams, why do executives understand so very little
about either? The question has puzzled me.
In an earlier post, I reviewed how Toyota had great success
at General Motors. With Toyota’s help, what was GM’s poorest performing plant
became GM’s highest performing plant inside of a year. Did the GM leadership
race to implement the Toyota Product System at other plants? No! Why?
In the mid twentieth century, Deming attempted to convince American
executives of the benefits of what became the foundation of lean. Frustrated by
the lack of traction in the US, he took his message to Japan. Deming’s teaching
became the foundation of the Toyota Product System otherwise known as lean. Are
Japan executives smarter than American executives? No! Why then the difference
in response?
Agile was born by software development engineers who gathered
to find a better way. Many of the defined agile values and principles moved
away from centralized control to collaboration and self-empowered teams. Agile
gathered the best management and engineer practices and packaged them in such a
way that the benefits of the whole were greater than the sum of the individual practices.
While well executed agile has brought great benefit to many businesses and customers,
it is still thought of by some executive and middle managers as a “developer
thing”. There appears to be so little motivation by management to understand
and leverage the practices that have transformed numerous organizations. Is it
a question of motivation? Perhaps!
Who are the leaders of our corporations? What is the mindset
of the canonical executive? What drives their behavior?
I have never been good at mindreading. However, perhaps if
we contrast the values between agile and lean principles and executive incentives
we will gain some insight into behavior.
Executives are often incented by results tied to the
performance of the company. Measure tied closely to customer and business benefits
are essential. Effective measures are hard to game and take the whole value
stream into account. Good metrics drive good behavior.
The inverse is also true. Arbitrary measures have large disconnects
between the measures and the benefits to the customer and business. Metrics
that are easy to fudge and tied to financial rewards are likely to be gamed.
Poor metrics also drive local optimization. Local optimization occurs when a
metric incents one organization to complete their work at the expense of
another organization within the enterprise.
The more arbitrary a measure becomes and the greater the
financial reward, the more likely bad behavior results. Human nature being
what it is, tying financial gain to arbitrary metrics drives the organization to
focus on the wrong behavior, invites the gaming of metrics and to practice local
optimization
Earlier I contrasted Japan companies with American companies.
To summarize, “Short term thinking companies are in business to make money
while long term thinking companies make money to remain in business”. Who is more
focused on long term and short term thinking? Which companies are likely to
sustain profitability?
Why are executives so short term focused? To answer the
question, we have to look to how we incentivize our leaders. Incentives are tied to what is valued. Are
values the core reason for the gulf between executives and agile and lean
teams? Let’s compare.
Agile and lean principles value the following
- Deliver working software – measure what matters to the customer and the business vs. an arbitrary metrics
- Sustainable pace – sustained performance vs. meeting a short term goal
- Test first development and pairing – system thinking (understand the whole) by eliminating problems at the source vs. local optimization (don’t care what happens down the value stream)
- Self-directed teams – accountability vs. avoiding blame
- Transparency – providing a clear pictures of the issues vs. manipulating perceptions
- Collaboration – team work and shared goals vs. making one look better at the expense of another
- Courage – do what is needed to make things better vs. fear of taking risks
- Continuous improvement – recognize what is not working, identify root cause and improve vs. burying ones head in the sand or redirecting blame
I have seen organization succeed with agile. I have also
seen organization with functioning agile team impaired or rendered ineffective by
executes suffering from the value discontinuity that often exists between agile
and lean teams and executives incented by arbitrary measures which drive bad
behavior.
How does this get fixed? This is a hard conversation to have
with an executive. Besides the obvious risk to one’s career, the message is likely
to be missed.
Think of it this way. Many successful executives are good
and figuring out the unspoken rules. The better they can navigate the hidden
rules, the more likely they are to rise. What are the rules? They can be different
from company to company but I have seen the following.
For successful companies, it is a matter of riding the wave.
Such companies are typically very profitable and in a stable market. Because of
the company’s market dominance, maintaining the status quo is what is valued.
So, building relationships and managing perceptions are on the critical path to
success. If your strengths are relationship building and perception management,
you will likely do well in such a company. Such a company typically frustrates
and drives away those that are results oriented.
For new or growing companies, it is about fighting for day to
day survival or improving market position. Such companies typically value
results. They look for people that can make a difference. The difference is
measured as impact to survival or growth. A skilled and results oriented person
will typically find such a company a rewarding experience. While it is
important to have a good working relationship, the relationship is valued more
for results they bring and not for gaining favor.
The former companies are likely, at one point, to lose
market dominance. Given that relationships matter more than results, the skills
of the company and consequently it ability to respond to market threats are
greatly diminished. We have seen this time and time again when well established
market leaders lose position to upstarts. Remember, change is constant and the
rate of change is accelerating.
The later example is also has its risk. Once a growing
company establishes its position in the market, it can lose the values that
helped it succeed.
Agile and lean values are about results now and for the long
term. It is about continuous improvement and rewarding behavior that connects
to the customers and the business. Agile and lean enables the executives and
the staff to align to the same goals and share a common set of values. This leads
to sustainable success. There is nothing more demoralizing to strong performing
teams then to see rewards parceled out by club membership or perception
manipulation instead of adding value.
Who has the brighter future, GM or Toyota? Which company declared
bankruptcy? Which company required government bailouts to survive? Which
company continues to grow and is admired for the quality of its product by its
customers?
Executives, it is time to remove the blockers to your
company’s present day and long term success. It is time to align what you
measure to the value you deliver. Yes, it is hard to rock the boat. Your chance
of implementing change is small; the risk to your club membership is high.
Consequently, we don’t see many established companies transform themselves. There
is too much executive self-interest to overcome.
On the other hand, leaders with courage and vision have been
able to transform organizations. Companies fortunate to have such leaders are
companies that have a long history of success and have the ability to learn
from failure and pivot towards success. If you are such a leader, look to agile
and lean. I believe both reflect the values and provide the practices that will
help you identify and remove the blockers to sustained business success.
Thursday, April 12, 2012
Executive Guide to Agile and Lean Transformation
First rule, transform oneself!
Typically, leaders see the signs of dysfunction. The business is not happy. They complain about cost and schedule and quality. The developers blame the business. “They don’t know what they want” or “They are always changing their minds”. You hear these comments in spite of the years of effort and training to implement project management.
The most common reactions are “What or who do I need to change to fix this?” “Do I need to provide better training?” “Is it the staff we have?” “Is the organization not following the processes?” Do you notice a pattern here?
It is everyone else’s fault but the leaders! The focus is elsewhere and not with the root cause.
This reaction is a long standing one and widely shared. Deming encountered it when he began to teach his principles behind “Lean Management”. In fact, after executives in the US turned a deaf ear to his principles, he traveled to Japan. The Toyota Product System (TPS) is largely built on his teachings. As a result, Toyota has gone from a small insignificant player to a global leader of transportation engineering and manufacturing.
How did this happen? Were the Toyota leaders focused on what changes the staff needed to make or did they first transform themselves? Deming stated that 85% of the dysfunction of an organization is rooted in the processes of the organization. He called it the system. It is the leaders that have primarily put the system in place.
Lean Management is fine for Japan but it will never work here. That was General Motors response to Toyota when they offered to help GM. With American culture and unions it is not possible they said. Toyota asked GM to give them their poorest performing plant. They did. One year later, Toyota turned GMs worse performing plant to their best. Did General Motors rush to convert their other plants? No! Instead they ignored the results and continued with their ways. Change is hard. It is even harder when you are the one that has to change.
In recent years a movement called Agile has emerged. It has primarily been a bottom up movement. Engineers, frustrated with the way corporation built software decided to take action. They were tired of the frequent failures encountered with traditional project management. They gathered to find a better way.
From their efforts, the agile movement was born. It has literally transformed the way software is being built today. This is in spite of the majority of executives not grasping why it works or their role in leveraging Agile effectively.
Agile and Lean work well together. Agile flourishes where Lean is understood and practiced. Lean, unlike Agile, started from the top. It’s about executives taking ownership for the system. Once accountability is properly placed, the leadership can teach themselves how to monitor the system, establish feedback loops, plan change and measure its impact. This is the “Plan, Do, Check, Act” pattern of continuous improvement. The focus is on improving the system, not blaming individuals.
Today, organizational transformations are underway. It starts with leadership taking accountability for the organization’s effectiveness. It is about leadership investing in their understanding of the lean and agile principles. Only through personal transformation can they become effectively leaders. They must lead by doing. They share accountability in results. There are invested.
Common principles shared across Agile and Lean:
- Self-directed teams – Lean recognizes that those closest to the work are the one best to define how to do the work. Agile is an advocate of self-organizing teams. Both require clear goals set by the leadership. Not objectives but goals. Effective organizations are not hamstrung by micromanagers.
- Pull based scheduling – Lean uses Kanban to ensure work is only done when needed; there is no sense building inventory upstream when there is no demand downstream. That is waste. Agile has teams pull cards from the backlog, one per pair, only when they finish the work they have. Pull based schedule maximizes the flow of work through the team consequently it is much more effect than push based scheduling practiced by traditional project management.
- Continuous improvement – Lean uses the shewhart cycle of “Plan, Do, Check, Act” via Kaizen to continually tune the system to maximize the quality and flow of work through the system. Agile uses a number of feedback loops included in Daily Standups, Retrospectives, Show and Tells and Test Driven Development (TDD) to continually improve the workflow and quality of the product.
- Visual Management – Lean use Andon boards to signal when an abnormal condition is recognized and help is needed. Agile uses Big Visible Charts (BVC) to make transparent the current state of the work for a team. Calling out issues brings support not blame from management thus issues are never hidden.
- Mistake Proofing The Work – Lean uses Continuous Improvement to identify how to eliminate mistakes in the process to begin with. Agile uses Pairing and Test First or Test Driven Development. By pushing defects to the left (i.e., find them earlier or eliminate them altogether) waste is eliminated and high quality emerges.
- Root Cause Analysis – Lean uses techniques such as the “Five Whys” and Fishbone Diagrams to identify the root cause of issues. Only when root cause is identified and the cause remedied does the system improve. Agile teams are encouraged to do the same via retrospectives.
By now, it should be clear that unless a leader understand why lean and agile work, they are likely to cause harm. For most, it requires a fundamental change in the way they manage and incent their organizations.
Ask yourself, do you manage by using Management by Objective. If so, what evidence do you have that the targets you put in place can be achieved by your current system? Instead, provide clear high level goals and monitor the trends for your organization. Is your organization trending in the right direction?
What do you use to measure the effectiveness of your business? Do you use Key Performance Indicators? They are point in time. What do they mean? Compared to what? Instead use trends. It is the direction of the trends and not a point in time snap shot that provides you the better insight.
How do you respond when an issue is brought to you? Do you look for someone to blame? Do you micromanage by adding weight to a bloated process? Instead determine root cause not blame. Once root cause has been identified and fixed, monitor trends for impact.
These are but a few examples of why it is essential for a leader to transform first before attempting to transform an organization. One of your biggest challenges will be to gain trust of your organization. Don’t expect the organization to become open quickly. After all, for years they have been trained to game the system. They have been given targets that were often arbitrary and tied to their compensation. This is an open invitation to “fudge the numbers”. You gain neither insight nor provide motivation.
They will watch your response. When issues arise will you blame or will you address the root cause. Will you support the organization by removing blockers or will you use the carrot and stick?
As you can see, you have many old habits to change. The first step to transforming your organization is to transform yourself. The change is well worth it. The impact will be larger and longer lasting than you could have imagined.
Subscribe to:
Posts (Atom)