Executive Patterns: Becoming a Catalyst for Change

Executive Patterns: Becoming a Catalyst for Change
Originally Posted Tuesday, June 7, 2011
By: Skip Angel

In our last newsletter, we conducted a poll asking the following question:
“How much executive support do you get for your Agile initiative?”
The results were encouraging, as 36% believed they were getting all the support they needed. The remaining 64% had some support, but could use more. Everyone that participated in the poll indicated that there was at least some involvement by their executives. As a coach having supported the adoption of Agile across several organizations, I usually see one of the following patterns when it comes to executive involvement.

The Impulsive Executive 
“Greg” is very reactionary in nature and isn’t afraid to pull the trigger on new ideas. After attending a local class, he gets very excited about Agile. In fact, he decides that he wants to go “all-in” and that all teams should adopt Agile practices ASAP. This isn’t the first time for Greg to react this way, as it seems there is a new initiative coming from him every few months.

At first, it seems things are going well as the teams take on Greg’s mandate. After the newness wears off and the teams start running into challenges, Greg is already off searching for the next new thing. Without his support, it is determined that Agile is too hard and teams are better off doing what they did before. Some people are glad they didn’t commit too much effort to something that isn’t going to stick around. For others, it is just another frustrating “strategic initiative” from Greg and raises concerns about what new changes are just around the corner.

The Laissez-Faire Executive 
People like “Jan” because she is very laid back and conservative in her approach. Her answer is always the same, “Do what you think is right”. If teams want to work on their own, so be it. If they want to try out a new methodology, practice or tool, go for it. Under Jan, teams can develop their own standards. It’s all up to them to do “what’s right”. They like the feeling of empowerment, but some team members are overwhelmed with the choices available to them and wish things were simpler.

One of the teams decides to adopt Agile, as its members believe it may be a lighter approach to project management. After struggling a little bit at first on their own, they start to make progress and begin to deliver great results. When they run into problems that they cannot resolve on their own, the answer from Jan is always “make it work”. The team does its best to work around the problems, but the biggest challenge is coordinating with other teams. Since the teams are using different methods, tools, and technical solutions, it becomes very difficult to integrate in order to deliver work together into the production environment. Because they can’t solve this larger problem, the team comes back with the recommendation that Agile would only work for very specific projects that are completely independent. Future projects decide not to adopt Agile because they are considered “too complex” to work with that approach.

The Misguided Executive 
“Peter” always believes he is doing the right thing, though he gets frustrated that things don’t always work out the way he intended. Over time, Peter has become a little “gun shy” and is more careful about trying new things without addressing all of the risks. While he is excited about the possible outcomes that Agile could bring to his organization, he has also heard that it exposes potential challenges that need to be resolved.

He creates a group to investigate what needs to be done to do Agile successfully. After several weeks, they come back to Peter with a plan. To ensure success, they need to develop a specific methodology tailored to their organization with all of the best practices and tools that are recommended by the Agile community. Peter agrees to the recommendations and also adds another requirement. To save on potential licensing costs, he decides to start out small with a pilot, just in case it is a failure.

Several more months pass, the group develops the “perfect” methodology and all of the tools are in place. After some basic training on the process, the first pilot team is able to get started. Soon they struggle with how "Agile" works. The methodology is hard to understand and follow, the tools are difficult to fit into the process, and the training results in more questions than answers. Isn’t Agile supposed to be lightweight and focused on delivering software? It seems the team spends more time with the process and tools, leaving little time to deliver anything.

Peter originally thought that with Agile, the team would increase their productivity. After only a couple of sprints, the team has come to a halt. Given that he isn’t seeing the immediate results expected, he decides to terminate the pilot. He bans applying Agile to any future projects because of the significant time and money wasted over the last several months.

The Catalyzing Executive 
Like others, “Cindy” is very excited about the benefits that her organization could receive from adopting Agile. However, she also has read enough and received advice from the community that Agile would require a significant organizational change.

Cindy realizes that if this change is going to stick, she needs to become a catalyst. As this catalyst, she knows she needs to provide a sense of urgency for others to buy-in to the idea.  She spends time with those on existing projects and helps them see how projects are taking longer, quality is down, and end users are not happy with what is being delivered. She realizes that through these discussions, she is acquiring other champions to further “the cause”. Cindy enlists the help of outside consultants to provide guidance through training and coaching. These coaches focus on reinforcing the principles behind Agile, so that teams can better understand how to adapt the process to get expected results.

Cindy takes an incremental approach to the adoption process by rolling out small waves of project teams at a pace that the organization can handle. She encourages everyone to take chances, try new things, and learn from the results. Cindy works with other managers to address things that are slowing teams down, such as complex processes, a variety of tools, and a lack of big picture thinking. They come up with streamlined automated processes, minimal use of a standard set of tools and technologies, and tighter alignment to strategy through technical and product roadmaps.

Because of Cindy’s efforts, real change is happening in her organization that not only benefits the teams delivering software using Agile methods, but extends to all areas that are learning how adapt to any changes that may come.

Does your executive fall into any of these scenarios? 
Perhaps they are like Greg, Jan, and Peter and are less than thrilled with the results of Agile in your organization. Maybe they can learn from Cindy and consider a more direct and active approach to transforming the organization by introducing Agile practices. Want to become a catalyst like Cindy?

Here are some questions that you should explore if you want to change the behaviors needed for Agile to “stick”:

The meaning of success—Does it mean meeting dates and budgets, or delivering on measurable objectives and delighting customers?
Punishment vs. reward—Are people punished for bearing bad news, or rewarded for providing opportunities for learning and improvement?
Competition vs. collaboration—Are they rewarded for heroic efforts in a competitive environment, or for working well with others?
Decision making—Are decisions made by committee, or are they delegated to those closest to the problem?
Time allocation—Is the majority of time spent thinking about what should be done in meetings, or getting the work done?
Isolation vs. group thinking—Are you working in a "heads down" environment, or a place where people can interact and share ideas?
The elephants in the room—Is most of the time spent working around organizational impediments, or removing them?
Multi-tasking—Are team members juggling many projects at once, or are they working on a single, prioritized project at a time?
Time for innovation—Do people have to learn on their own time, or are research, training, and experimentation encouraged?

Click to read more post by Skip Angel

To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network

Why is IT so reluctant to look at itself?

Why is IT so reluctant to look at itself?

By Patrick Gray | June 2, 2011, 9:48 AM PDT

There is an interesting tendency among IT organizations to be hesitant to looking inward, with a view of improving internal processes, performance, and interactions with other elements of the company. Perhaps since IT is tasked with performing these functions for others, it seems frivolous to expend time and energy internally, when there is always a large backlog of work for the consumers of IT’s services. This is a misguided notion however, and if IT is truly going to sell itself as able to digest, implement, and improve on corporate strategy, it is imperative its own house is in order.

Perception matters

While many are loathe to admit it, perception and appearances matter. Just as one would be hesitant to hire an obviously out-of-shape personal trainer or a tattooed and pierced estate planner, organizational appearance can have a similar effect. At the most obvious, the IT shop whose frontline staff constantly complains about those jerks in “the business” and reflexively answers “no” to any and all requests is not going to be positively regarded. More subtly, the CIO who is in a constant state of panicked chaos, always too busy to talk, and late to every meeting negatively impacts IT’s perception just as badly.

Strive for a perception of control, pragmatism, and openness at all levels of your IT shop. The junior analyst should be just as willing to frankly discuss an idea with a business peer, as the CIO should be scheduling regular meetings with colleagues in sales, marketing, operations, and finance. An IT shop that appears to be staffed with a cadre of business professionals will garner far more appreciation than one that seems loaded with propeller-head prima donnas.

Benchmark thyself

Most IT organizations will proudly proclaim they are excellent at benchmarking, producing rafts of charts, graphs, and reports that minutely analyze everything from server uptime and performance, to the cost to send a single email, calculated with seven decimal places of precision. While that is all well and good, few IT organizations effectively track their performance and perception in the larger organization. While knowing technical benchmarks is fine, it is far more valuable to know if the larger company perceives your IT shop as inflexible, incapable, and generally incompetent. This need not be a mind-numbingly complex endeavor, and an external party can perform a basic benchmarking exercise for a minimal investment of “time and treasure.” Furthermore, knowing where you stand and continually monitoring your organizational performance allows you to quantify and measure the results of efforts toward improving your internal practices.

Practice what you preach

Nearly everyone in IT talks about improving processes throughout the organization but often ignores its own idiosyncrasies. From eight people being involved in a process that really needs only two, to poor internal management of incoming requirements and project requests, most IT organizations have myriad opportunities to improve their internal processes and systems. Rather than being frivolous or self-centered, making your internal processes more effective creates an IT organization that is more nimble, quicker to respond to changes in the business, and a more enjoyable place to work. The IT organization that is constantly in a reactionary mode is never going to get a seat at the strategy table, nor is it going to be perceived as a valuable asset to the company.

While it may seem unsettling to look inward when problems abound outside IT, each hour spent improving your internal practices can pay long-term dividends. With some targeted investments, you can shift your IT shop from a reactionary, “break/fix” driven entity, to one that can thoughtfully approach a business problem, propose a considered solution, and confidently guide its implementation.

Patrick Gray is the founder and president of Prevoyance Group and author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO’s Companion. Prevoyance Group provides strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at patrick.gray@prevoyancegroup.com, and you can follow his blog at www.itbswatch.com.

To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network

Face it: Organizational charts don't work - reposted

Originally Posted on TechRepublic
By John McKee
June 1, 2011, 12:58 PM PDT

Takeaway: Can something as simple as your organizational chart impact the company’s performance? Executive leadership coach says definitely. In this blog, he explains why.

Recently, I was asked to take a look at a client company’s organization chart. It was to be a part of a review on performance and morale. Company management wanted me to review and make suggestions that would help ensure they were accurately depicting their business. After reviewing the first page, I declined.

From experience, I knew it would have been a frustrating exercise (talking to a lot of people and hearing their opinions and recommendations). More importantly, I knew it wouldn’t have resulted in any effective changes within the place. By declining, I chose to look after the client’s expenses. And my sanity.

The company used a traditional pyramidal structure, i.e. boss at the top, next in command on the line below, their underlings on the next level. As far as I can tell, this structure probably started about 5,000 BC with the Sumerian civilization. After they crashed, it was picked up by subsequent generations of leaders — next being the Egyptians about 2,000 BC. It has existed, more or less, in the same style since then.

Given how successful this reporting and management structure was for all the past civilizations, I am not inclined to recommend it to anyone....

There are tons of management studies that support the reasons for not using a structure like this.
Key issues include:

• they’re always out of date,
• they don’t deal with how things “really” get done, and
• they distance company leadership from the important work of the organization.

I like flat organizations: They work when the boss is involved. And, if he or she isn’t involved, they show that the leader is not up to the task and should be replaced.

It’s not simply for small companies. The critical factor — that the boss is never more than one step away from the person who’s doing things – can be modified for even the biggest companies. Apple’s structure proves it can work. In that organization, virtually every key area’s leader reports directly to Steve Jobs. Nobody “in charge” of a key area is more than one step away from the boss.
Consequently:

• decisions are made faster,
• money is spent according to the priorities of the company, and
• there’s less culture clash internally with fiefdoms being created by each department head.

If you oversee an organization, reduce the levels between you and those “on the bottom.” Challenge yourself to get involved, and you’ll be surprised (maybe amazed) at how fast things start moving.

For anyone who really enjoys his or her job, reducing the number of levels will make it more fun — and successful.

John M. McKee is the founder and CEO of BusinessSuccessCoach.net, an international consulting and coaching practice with subscribers in 43 countries. One of the founding senior executives of DIRECTV, his hands-on experience includes leading billion dollar organizations and launching start-ups in both the U.S. and Canada. The author of three published books, he is frequently seen providing advice on TV, in magazines, and newspapers.

To learn more about the Performance & Quality Improvement Network, other topics and initiatives - subscribe to this blog, follow us on Twitter, visit our website PQI Network