Reestablishing a High-value, Technical-to-Business Culture
This article describes a leadership journey involving Robin Barrett (below). During the journey, Barrett had an opportunity to reshape his career as well as to identify his interests and passion.
Barrett was asked in the fall of 1995 to join American Express in the United Kingdom in the capacity of Chief Information Officer (CIO) responsible for international technology (all American Express technology organizations operating outside the U.S.). While the firm is continuously successful, worldwide, Barrett’s job offer did not promise an easy time. Rather, it was a call to help restore an IT organization that had gotten off track and was not delivering as needed.
Robin Barrett
“At the point in which I joined Amex, I knew that I was joining an organization that effectively was broken,” Barrett explains.
Indeed, when he arrived to assume a leadership role, there was a very reactive, order taking mindset to the technology group. The concepts of creativity and adding value were missing. Group managers and staff lacked credibility with their business counterparts and the result was causing extraordinary frustration among business units.
At a time when the business was going through revitalization and needing to expand their business lines into new areas, the existing systems were unable to support these objectives. The technology was archaic and incapable of delivering acceptable results. Under production conditions, the applications frequently broke down, causing enormous problems and negative exposure to the business.
The technology leadership at that time Barrett joined the firm lacked the commensurate experience and the confidence to take the business firmly on an improving technology path. Whatever was tried was destined to fail.
They were, in effect, paralyzed, demoralized and unable to work their way out of a troubled situation. Conversely, the business units were increasingly strident in making demands of the IT leadership to develop new applications that exceeded the available skill sets and developer confidence to deliver workable solutions. The business had reached the point in which they despised the technology group, expressed no confidence in them whatsoever, and was openly electing to bypass them entirely to look for technology solutions from external suppliers.
“My mandate coming in was to figure out what was needed internationally and recover the situation. Because we were international, and operated outside the corporate dictates in the U.S., I was given a good deal of latitude in how I approached the issues,” Barrett said. “My management allowed me the freedom to craft my own solution.”
Barrett quickly recognized that he would be involved in unraveling a complex relationship. The open hostility between areas was as much of a problem for the business as it was for the IT group. Behaviors were in place on the business side that would never allow the technology to recover its full-partner role. Ironically, the demand for new applications, in itself, contributed to an increase in the antagonism felt on both sides, because of the assumptions of inevitable failure. To Barrett, it was a project management nightmare.
“What I observed were instances in which the business had not been clear from the start about what it was they actually wanted. Conversely, the IT group lacked the fortitude to insist on clarity, as well as to resist spurious changes to the original specifications. Changes were introduced, often at mid-stream, as the project progressed,” Barrett explains.
“When the application eventually went into production, the lack of effective project management and technology leadership coupled with poor communications between the stakeholders and technology group, resulted in the business having little, if any, ownership of the features and functions they had requested some time during the development cycle.”
The technology group at the time, according to Barrett, was not adept at understanding business terms, nor was it able to relate effectively to the need to give priority to launching new products. In short, there was a yawning chasm between the IT department and its constituent users. As the situation spiraled downward, the business users, whose own objectives were not being fulfilled, ended up literally shouting at the technology people in meetings out of sheer frustration.
The Cost of Delivering New Applications
Because of the limitations described above, and the lack of robust, flexible technology platforms, it would typically cost in excess of $1 million to develop and launch the infrastructure around a new credit card. The high costs had to do, in large part, due to the nature of the platforms designated for supporting new cards. These host-based platforms were hard wired and inflexible.
When a new card initiative was requested, the business needed unique features for each new market, new product and new card. The technology group seeking to avoid frustrating their requestors and adding to the rancor, would agree to all the customized specifications at the kickoff of a development cycle.
“The problem was, the technology group was effectively building a whole new technology platform every time we launched a new card. We lacked the reusability of useful components developed for other cards. This made the products exceedingly expensive to produce.”
Barrett indicates that there are only five basic variables that need to be deployed in launching a new card: card design, credit limit, interest rate, fees, and grace period. If the technology group could bring the business to understand what the relative costs are for modifying only the five variables, rather than 20 or 30 “bells and whistles,” it would dramatically reduce the costs (borne by the business) of producing new card offerings.
“The costs associated with running systems as well as developing new systems were quite high. It also took an unacceptably long time to develop the system. It was not unusual to take 12- to 15-months to develop and launch a new card in a market,” Barrett said.
When American Express competitors were able to accomplish the same objectives and produce viable cards in two-to-three months, this knowledge only added to the frustration the business users felt.
Taking Stock
Barrett describes a checklist of the situation he confronted.
“I was aware that:
- The existing applications were failing frequently due to poor design causing long periods of down time to make repairs
- The systems in production were inflexible and so it would be difficult to make enhancements to them
- We needed to find a better way for IT to respond to the need for new cards to meet business opportunities or match competitive inroads.
In the longer term, we needed to change the attitudes and mindsets so that we could begin to plan for new technology platforms that would be much more flexible allowing new cards to be launched at a fraction of the cost and a fraction of the time.”
Changing Mindsets and Fostering Resilience
It was clear to Barrett that the changes for the better could not begin until the mindsets of the business and technology people were both changed and the relationships improved. However, no changes to the dismal situation could begin until the technology group was capable of delivering.
Changing Mindsets and Fostering Resilience
It was clear to Barrett that the changes for the better could not begin until the mindsets of the business and technology people were both changed and the relationships improved. However, no changes to the dismal situation could begin until the technology group was capable of delivering.
Barrett was given the authority by his management to hire 10 technology leadership positions at the vice president level. He recruited people he felt had the tenacity, leadership and technical skills to take on and run the areas that were faltering.
“I was able to attract very capable people from good firms to come in to start to turn the IT group around. I had the leeway to also to give them the latitude and freedom to change not only the ‘paint’ but the ‘canvas’ too”
Barrett gave his turnaround plan a hard deadline of 18-months to succeed. His strategy was to get good technology leadership on board and then gradually apply efforts on the part of more seasoned leadership to gain control over existing processes and begin swapping out systems that were prone to high failure rates. He knew that if he did not make the changes that were needed, he would be the point of blame and someone else would be brought in to do what he could not.
Avoiding the Compulsion to Firefight
When systems failed, the mindset of the organization at the time was that the entire IT leadership would be expected to jump in to help coordinate the recovery efforts. To Barrett, this seemed wrong and he was determined not to be pulled into the tactical firefights.
“It is not uncommon for individuals in technical areas to get promoted from technical to leadership roles,” Barrett explains. “These people often have difficulty leaving the comfort zone tasks they performed well before being promoted. They have great difficulty being able to resist a hands-on tinkering approach, particularly when systems crash. That was totally inappropriate as far as my role was concerned. If you are frequently down in the bottom of the ship doing repairs in the engine room, you do not have the perspective to plot and steer the course,” Barrett said. “There were plenty of good engineers, but I was brought in to provide leadership.
One of the first things Barrett had to do was to change people’s expectations about his role when something went wrong.
“They should think twice before coming to me and expecting me to lead the team to fix it. I would tell those who came to me, ‘My focus is on developing a new strategy and fixing the root causes, not on troubleshooting problems. I would tell people who came to me, ‘You are responsible for this application; you understand what the issues are; you need to meet with the business and let them know the situation; you are fully capable and I expect you to manage this problem through to its resolution.’”
While Barrett’s remarks may have given recipients the impression they were getting a rebuke, they actually were part of his larger strategy to rebuild the confidence of individual IT managers to take charge of their respective product areas while not getting seduced into making the repairs personally.
The Climate of Blame and Finger Pointing
A common practice that would take place during any of the frequent system outages was to ruminate in the IT hallways whispering about which team, which manager, which system or database was responsible for the most recent failure.
Barrett noticed that no formalized practice of involving all parties in a post incident assessment of what actually happened was occurring. So he changed it. He introduced post incident “review meetings,” Those practices and procedures that had not prevented a problem from occurring could be changed or refined, as needed.
“One of the first principals I introduced in our post problem meetings was, it doesn’t matter who was to blame, what does matter is what can we all learn from this incident so we can reduce the likelihood of it happening again or how can we do things better.”
Barrett needed to restore some sense of inter-departmental connectivity and establish a framework of trust to build on, if he hoped, in the longer term, to reestablish cross-department teamwork.”
Behavior Modification
In parallel with growing the strengths of his management team, Barrett also began to push back on the behaviors of business leaders whose bellicose style and negative communications were unacceptable. His newly appointed senior leadership people also started to do the same.
“We had several confrontations where shouting matches would ensue between the business and my technology leaders,” Barrett relates. “My people would be treated with irrational anger and disrespect. When this happened I would call up the business leaders, inform them that the behavior would not be tolerated and, if it happened again, I would withdraw all technology support from them.
“I was not averse to walking out of unproductive sessions with our business leaders saying that I will be happy to come back when we can discuss this calmly and intelligently with a solution in mind.’”
Barrett found that once he directly challenged a bully on his behavior, it began to change the behavior. He also directed his senior managers to carry the same approach with their business counter parts. He instructed them not to fall victim of the “blame game” and focus instead on ownership of problem solving.
“I wanted my team to be people who could stand up and say, ‘It doesn’t matter who is to blame, we need to get out of this situation. What are you going to do to help resolve this problem?’”
Once the adversarial posturing was called out as being unacceptable, it opened up opportunities to identify problems that had actually been occurring on both sides.
As the climate became less confrontational and cooperation improved, Barrett’s team was able to identify mistakes that were not always totally the fault of the technology group. Some mistakes were now being understood as being rooted within the business, such as inadequate certification or over certification, as well as data failures introduced by the business.
“We started to rebuild several of the collapsed bridges between the business and technology areas.
Team Rebuilding
“We had to find ‘courage’ and we needed to relearn how to trust one another. To do this, we invested considerable money in organizational development. We had our leaders and middle managers take a five-day development program that put them through physical stress and intellectually challenging situations that broke people down and then rebuilt a team around a new mold. They were shown where the culture was and where we all needed to be as well as what needed to change to get to our new culture objective. ”
Barrett and his senior leadership also insisted that the entire organization be more “business aware” and “business savvy.” The IT teams needed to understand the business drivers and help guide the business partners in adapting appropriate business solutions. Technical analysts needed to be business analysts, as well.
“We had to lead our own people in building and rebuilding communication skills in a business-centric direction,” Barrett explains. We needed to be clear about our performance expectations and the consequences of non-performance. We also needed to improve on the nerve of our leaders to deal effectively with poor performance on their respective teams. If our programming and operations personnel were unable to move in the right direction, perhaps it was time for them to move on.”
Numerous roundtables and town hall meetings followed up the initial communication of the goals. These occurred in 12 different locations across the globe.
“The journey we went on was one that required people to change their behavior. The technology had to change for the better, as well. We began to see a marked difference in how we could respond to market demands. When I joined Amex we were only able to launch three cards in a given year. In 1995, we began to see exponential growth in the way we were able to launch new products. For example, in 1996 we launched an unprecedented 25 cards and then the numbers went up to over one hundred products within the next three years.”
* * *
Thanks Bill. That was an inspiring story.
Reply to this
Thank you Waleed. I am glad that you liked it. It is a good example of how organizations that get off track, can recover with good leadership. It isn't easy or pleasant. But it is important.
Reply to this
Bill,
Very insightful article. I enjoyed how you described the relationship between the individual, organizational, and technical issues. Leaders have to lead in all those areas, and understand the interrelationships between them.
Reply to this
Bill and Robin,
Thanks for an effective download of a business and technical success story. In between the lines, I could see quite of few episodes of Dilbert. But what resonated with me most was "Avoiding the Compulsion to Firefight". Not only for myself, but I can see all around me that as very competent technicians advance to leadership positions, it's imperative for the captain to understand that what the team is looking for is the leader (not the expert technician), whether in business, at home or in one's community. Good stuff! Great reminder for me.
Reply to this
Danny,
Thanks for your comments. In my coaching I often come across the issue where the new “leader” is out of their comfort zone and won’t let go of the familiar territory of the “engine room” from where he/she came. I tell them that they are behaving like Scotty wittering on about his dilithium crystals when their team is looking for Captain Kirk to man the bridge! But that gives away my age!
Robin
Reply to this