Cross-engineering the Corporation a Context
In James Champy's "X-engineering the Corporation - Reinventing Your Business for the Digital Age", Champy offers the view of a network of interconnected processes, from customer to customer, organization to organization. This view is truly inspiring, even still today and perhaps even more so, as the promise of increased complexity has well and truly delivered since 2002 when the book was first published. Cross-engineering has become an essential part of some business models, however for many more businesses it is still deficient and requires focus.
Let's take an example, which is close to my heart, and has been haunting me like the ghost of outsourcing for more than ten years now, raising its annoying and preposterously bureaucratic head time and time again. Every time the deal is cut and the contract is signed I can hear the chains of bureaucracy rattling along the corridor entrapping the poor tortured soul, which ultimately is the customer.
The benefits of outsourcing could be significantly expedited if both parties spent the first few months cross-engineering the engagement process, and not the other way round, where during the first six months (in the best case) delivery commitments cannot be met because engagement is largely dysfunctional. This approach creates a poor perception of the vendor and starts the relationship off on the wrong foot―it takes time to put it right.
OK, we've made a business decision and entered into this thing, now before we kill two systems, let's sit down together and figure out the most effective and efficient way to engage each other with minimum bureaucracy and a focus on serving the customer as opposed to serving the dysfunctional engagement system and red-tape that prevents everyone from doing their jobs. That's why it takes so long to get the benefits of outsourcing, because most of the initial effort is spent fighting two opposing systems, as opposed to fighting the common enemy, in this case bureaucracy.
As we shall learn Team Learning and a culture that supports a collective learning approach could considerably help such recurring problems. Team Learning provides a proactive culture of collective inquiry that seeks to resolve these issues at the outset, as opposed to waiting for escalation in order to get things done.
The trouble with complex sociotechnical systems, like for instance ITIL®, is that no matter how well implemented they are they will always have their challenges and like any system some of the most difficult challenges are to do with cybernetics and the interface between the technical parts of the system and its people. Both the people the system is designed to serve, its customers, and the people whom are required in order for the system to work, its employees.
We very rarely get the most out of our systems sometimes we blame the way they are implemented, or the incorrect interpretation of ambiguous requirements, or people's resistance to change, or a lack of training and so on. We find an excuse or a popular scapegoat and put it down to whatever the "in reason” happens to be. What happens then?
Depending on the impact and urgency a task force or work group may be called into play, or a project planned or launched to address the "shortcomings of the system". There's nothing like a good crisis to get excited about and for many organizations crisis is still the major instigator of change.
Sounds familiar doesn't it? Here's the challenge: It's not always the system, this is what Champy was alluding to, and it's not always the implementation, nor the lack of training. One key reason why our systems fail is simply because we don't possess a consistent and holistic understanding of how to use them effectively. It's convenient to blame the system and difficult to admit failure or come to terms with our own inadequacies.
That may sound like a question of training, but it's invariably more complicated. We have a series of mismatches that are interpreted differently by individual team members and by individual teams or silos within the larger frame of the customer value chain. Training isn't necessarily going to help.
It requires a cohesive learning force to be fully effective, rarely can a trainer understand and interpret every nuance in our systems. Moreover, the learning experiences of people and the system are not available when initial instruction is required. This only comes with time and can only be understood and utilized effectively through Team Learning.
I admire the ingenuity of business users and their Excel skills, which have been systematically developed over the years to compensate for lacking system functionality. It is this tacit knowledge that Team Learning seeks out and elevates to the organizational level, where it becomes part of the overall system and therefore of benefit to a greater number of people.
Let's take ITSM as an example. Great structure, great definition, but it's not until we are a few years into the maturity curve that we begin to see systemic problems emerging. Most likely the symptoms of deeper underlying problems that begin as individual episodes and develop into systemic issues that are reinforced by the systems themselves.
Incident management is a good example, where service desks are measured on the numbers of closed tickets, or more specifically service desk agents are measured on the number of closed tickets. So it's advantageous for the agent not to want to share important knowledge with coworkers at the team level.
Another example is portfolio management, where services are managed in groups or portfolios and part of that management is cost optimization or service performance. What often happens is that over a number of years, service portfolio managers become competitive and what starts out to be more or less friendly camaraderie escalates into fully blown trench warfare. Especially in large corporations where service portfolios are becoming more and more stretched to perform.
A note of caution on vertically organized services: At IBM during the mid90's, Lou Gestner transformed the IBM landscape by refocusing on the customer. I was involved in the CRM transformation of IBM during those years, and I remember being puzzled at the length of time it was taking to get customer proposals out of the door, especially when multiple platform solutions were in play.
In those days it was becoming commonplace for customers to mix and match their requirements in one request, interpreted as say, two AS/400 servers, a bunch of Intel servers and an RS/600. Sounds easy right? All manufactured and delivered by the same company and yet why was it taking so long to get the proposals to our customers?
We were frequently losing business due to late submission of proposals. How do you think the customer perceived IBM? High-brow, arrogant and unresponsive. If you knew and saw the people involved, the IBMers, this was hard to believe, as they were customer-focused and cared about their customers greatly. So where was the problem?
Well we discovered that the vertical solution units had their own profit and loss centers and that they had no incentive to cooperate with each other collaboratively on just about anything including proposals. In some cases this attitude was even being enforced by management as well as the system, the willingness was not there and as a result the customer suffered.
With the above examples we must start to combine the foundation skills of System Dynamics and Team Learning. We must identify systemic barriers and remove them in order to open the way for real cooperation to take hold. It may be require a change in thinking in terms of how people are rewarded for their work.
A Systems Thinking Exercise
In section 2.2.6 of SOS there's a Systems Thinking exercise to identify the System Archetypes at play in the innovation case study. Use the same table and try to identify the System Archetypes present in the above examples. Read the section on System Archetypes for further context if you're not familiar with this term.
Another aspect to consider and as previously mentioned it can also be the area of cybernetics and the interface with our people and the system that causes the problem, not only the holistic perspective described in the cases above. Often this manifests itself in people's apparent complacency and sloppiness a few years after implementation and after the initial change momentum and short-term benefits start to wane. Now we find ourselves in BAU-land and that can be a frustrating place to be in some organizations, struggling with the everyday reality of fire-fighting and operations it can feel lonely at times with no-one to share the pain.
So what's up? And what's all this got to do with Team Learning? Well, before we launch another task force and set about upgrading or replacing the system, maybe we should invest a little time and effort into the team approach. What I have found is that often it is not the system but rather our organization's inability to use and leverage the system correctly and this is where Team Learning comes in. Before we go much further I would like to clear-up some of the confusion with the terms Team Work and Team Learning―they are not the same thing.
Teamwork is the ability for members of a team to work together collaboratively in order to produce a common outcome. Team Learning is the ability for members of the team to learn collaboratively and together. Not in the sense of getting together in a classroom and learning together that way, but rather in the sense of progressively and systematically uplifting the knowledge and understanding of the whole team whilst engaged in everyday work.
With Team Learning the common outcome of a team is typically greater, faster, more thorough, more innovative and more robust than it is with a team that doesn’t participate in the discipline of Team Learning. Senge mentions in The Fifth Discipline and I mention it again in SOS that this is not about discipline in the sense of “you must do this”, but rather in the sense of discipline that is more akin to studying, in this case studying the outcomes of the team and ultimately of the organization.
This is the real test of Teamwork, often, I hear people say they're team players, however, rarely do they participate in Team Learning and as result an aberration of expected outcomes occurs. Not only that but also the difference between a common team outcome and a common team outcome achieved through Team Learning, which is remember significantly more, is not realized. It’s lost opportunity and that’s a shame isn’t it? We could be much more than we are, so much more.
So then what is a good definition of Team Learning? It is taking what we have and making it much more. It is the able pragmatist, the way how to finally get our money's worth from the investments we have made into our systems. The key to an effective Learning Organization is Team Learning, it just as pivotal and important as Systems Thinking. Just remember that we must consider the whole. What to watch out for?
Guru Complex is when a guru emerges in a team and it comes about due to a number of different circumstances, usually either through seniority, in tenure, position or knowledge. Gurus tend to hold significant informal and influential power within and external to the team, they're also notorious for hoarding knowledge and information. The malign feature of Guru Complex comes from the consequences of team members not questioning the guru.
Often the guru is right, but not always and after many years of Guru Complex the reality of situations and the distorted outcomes of the team can be two very different things. In order for Team Learning to work there cannot be any gurus, each member of the team is an equal partner in the collective learning experience. Appreciate them and let them know they’re wanted and loved, but stamp-out the complex.
Not Suspending Assumptions
As Senge writes in The Fifth Discipline we often desist in suspending our assumptions within the team setting. By suspending assumptions we refer to holding out one's assumptions in “public” as if they were open for inspection and inquiry. This can be dangerous water for people as they are frequently scared of being wrong or being found to be lacking in knowledge or insight by their coworkers and supervisors, so they rather keep their assumptions for themselves and choose to forge on ahead, often at the detriment of the whole team.
People need a safe environment where they are not afraid to suspend their assumptions, often as a leader I break the ice by making a proverbial horses-ass out of myself in a team setting. Sometimes it’s worth taking the fall to open the way for others.
Demarcation Syndrome is the fallout of process-based working and activity based costing and is something I am finding to be very entrenched in many organizations. This is difficult to address and as we see more and more outsourcing our organizations are becoming much more commercially focused, which is a good thing, but on the other hand wasn’t it just so much easier when people just did stuff and got the job done?
"I am my job description" is one facet another is "this is not my job―I’m not interested". In solution delivery focused organizations demarcation can be extreme as the single pointed focus of many people is to deliver their part of the solution―it can be very hard to break down the barrier. Smash it, stamp it out, this is not helping.
Among all the scorecards and RAG statuses we forgot that we’re all serving one purpose―to serve the customer. Spend a couple of hours each week in cross team working patterns, encourage open inter-team feedback sessions and get people interested in each other’s work. I find communities of interest to be great avenues to nurture a cross team culture.
In certain situations Divergent Approaches can be a good thing and I positively encourage divergent approaches so as not to stifle people’s creative space. It is important to experiment with almost everything, but it is equally important to know when to rein-in ensuring overall alignment with strategic direction.
The Divergent Approaches I write about are a by-product of all of the above and in particular a by-product of inferring and assuming direction without seeking the collective agreement and confirmation of the team. This creates a nice segway for the next foundation skill Mental Models (stay tuned to vanwood.net for the next post).
Is it really what the system requires of me? Is this what is expected? Is this what other people are doing? Sounds innocuous enough, but sometimes they can be the hardest questions to ask. It’s bad enough when one or two teams suffer through a lack of Team Learning, however, when entire organizations are systemically impaired the overall result is catastrophic.
Challenge the status quo tomorrow and try a different approach, start to open new ways and nurture an environment that allows people to come out into the open with their learning and knowledge. Embrace the collective learning potential that is all around you and reap the benefits.
Here are a few pointers to help get started.
1. Stop checking tasks and start offering Team Learning opportunities in your team meetings.
2. Start-up communities of interest to encourage inter-team learning opportunities.
3. Identify systemic barriers, like with the IBM case, and systematically remove them.
4. Don't be scared to be the "fall-guy" if it helps to open-up the way for others.
5. Make a habit of seeking consensus about the team's capability, "if we were to do that how would we go about it?". This is a great question and helps to open up the dialogue.
6. Always use dialogue and never discussion, always encourage people to contribute and make sure they have an equal voice in the team.
7. Make a habit of bringing a learning experience with you to meetings, "oh and FYI, I learned today so and so, has anyone else had a similar experience?"
8. Set aside some time for creative space and allow people the opportunity to experiment with new approaches, remembering the above comment on reining-in.
9. Focus on clarity, use consistent terms and ensure that everyone is on the same page.
10. Invite other people from different areas to attend your team meetings and ask them to share learning opportunities and experiences.
Above all Team Learning should be fun and not onerous or obligated, people will share and enjoy the collective learning experience, it just might take some time for them to open up.
But I promise that when they do they won't look back. Enjoy!
If you haven't done so already please feel free to download your copy of Sea of Systems (SOS) by clicking on the link below.
Download Sea of Systems...