by Pat Bodin
The whole goal of this book is to teach technologists how to become enablers of the organizations they are in so they can have an impact on the organization. Once we become enablers, we will be seen as relevant, will be asked to join the leaders at the table, and we will find meaning in being part of something bigger than ourselves. That is what the framework is about.
Because, let’s face it. If you don’t find a way to be an enabler – a way to have a material impact — you become a tool, and the problem with being a tool is that you can be automated.
If you want to have a material impact on your company, this book is for you.
If you are a business leader who wants to know how to align your company resources to react quickly and productively to market changes, this book is for you.
If you are a supplier who wants to know how to be a good business partner and less of a discount warehouse, this book is for you.
If you are a technologist or other STEM professional who wants to know how to be relevant to your organization and how to communicate that relevance effectively to business leaders, vendors, or customers, this book is for you.
Is change worth the risk?
This book asks you to change. That raises a question: Will this change be worth the risk? Some of you might be tempted to maintain the status quo because you aren’t sure the future will be any better. You may assume that you have a limited time in your current position and that you’ll just move on when this stage comes to an end. You may not feel an incentive to put in hard work and get back…what? What exactly will you get back? You’re not sure. You may feel content to clock in, do the job your boss asks of you, clock out, and repeat the next day.
Is change worth the risk? Let me answer that with a few other questions. Are you satisfied with your job? Does your work have meaning? Are your daily activities imbued with significance? Do you feel relevant? Job satisfaction, meaning, significance, and relevance all come from using your abilities to positively impact others and your organization. You can keep trudging along, doing what you do—but isolated from the bigger picture, you’ll be neither relevant nor satisfied. You’ll always know you could have had something more.
A Technologist can be relevant. They can be an integral part of your organization’s success. They should join business leaders in the main boat to help them navigate obstacles and steer toward triumph.
Is the benefit of change worth the risk? I certainly think so.
Why don’t you come along on this journey and see for yourself?
Pat Bodin
SECTION I.
How Business Works
Chapter 1.
What’s Around the Bend?
Rapid change is making life hard for technologists and this change carries inherent risk. Should we swap non-cloud services for cloud services? Risk. How should we direct the company? Risk. Massive sea changes are happening. What’s more, the speed of those changes is increasing exponentially.
Consider something with which we are familiar: vacations. We travel much differently today than we used to. Twenty years ago, planning a vacation required a visit to your local travel agent. You would drive to the office, sit down in front of the agent’s desk, browse through catalogs, and the agent would dial up flight options on their computer. Today, planning a vacation may involve sitting at your kitchen table while still in your pajamas, reading reviews on Trip Advisor, booking a room on Airbnb, and checking flight options on applications such as Hipmunk or Kayak for the best deals.
You can generalize these observations about change to almost any other organization. The trend began in the 1990s in high-velocity areas like Wall Street financials and it just hit Main Street in the last decade. Want proof of the trend? In the 1920s, the average public company had a 67-year life expectancy. Today, that lifespan is 15 years.1 Business is rife with uncertainty.
Leadership within a business often causes change. Major shifts by the people who lead an organization affect the company’s direction. However, those changes aren’t always obvious to the employees downstream. This disconnect creates uncertainty because technologists don’t know why leaders are altering course—they may not even realize anything has happened.
Technologists strive to use technology to promote business goals. However, if no one is telling them that the entire organization has changed course, they will likely be directing technology decisions toward an outdated goal. Time and resources will be wasted and the business will be thwarted in reaching its objectives.
In a Different Boat
I don’t know if change will continue at this tumultuous pace. It may not be sustainable. But for the time being, we must manage hundreds of decisions that could go awry.
Think of it like white water rafting on a highly turbulent Class 5 rapid. Every decision you make now affects later decisions. If you decide to paddle right to avoid a boulder, you may find a new obstacle awaiting you. You don’t know what the next rapid will be like—a whirlpool may throw you into the water! That is the uncertain future and technologists are bearing the worst of it.
For various reasons, the technologists have been kept at arm’s length from the business. You might think they’d be able to sit alongside the business leaders, notice an upcoming rapid, and alter course together. Why can’t they? Because they’re not in the same boat. They’ve been placed into another boat that trails along behind.
The Paradox
Here’s the paradox: as I survey my career of over 30 years, technology is more relevant than it has ever been and yet technologists are still kept at arm’s length from business decisions and discussions. I find it interesting that technology has become highly important while the person who is supposed to be managing the technology has become a roadblock. In fact, technologists are almost universally perceived as roadblocks. How do I know? I did a sampling.
Over two and a half years, I interviewed 750 businesspeople, simply asking, “What do you think of IT?” Before the interviews, I expected to have some negative responses. What I never expected was an utter lack of positive reviews! Out of 750 interviews, 750 responses were negative. “We don’t like IT. IT is a roadblock. IT is in our way.” Yet, when I asked for them to give me an example of how IT specifically was a roadblock to them, at least 70% of the people I spoke with could not provide me with one.
I believe this indicates a lack of understanding and a lack of communication with those in IT. People in the business functions—those who do sales, marketing, engineering—don’t know what the technologist is doing. Moreover, they don’t communicate what they are doing to the technologists. Both sides are mutually ignorant of the other.
Since the technologists are unaware of the business functions’ requirements, they spend an exorbitant amount of time studying what new capabilities to develop for the business, but often by the time they reach a conclusion, the needs of the business have changed. This is a massive disconnect. Change happens in the business while the technologists are still hard at work trying to implement the last change, which is often a capability that has already become obsolete and irrelevant.
What’s the issue? They’re not in the same boat. If functional leaders and technologists were sitting together in the same boat, they would all be able to see the upcoming rapids at the same time. They could navigate around rocks and branches and whirlpools together. They could change in unison and work as a team. To face an uncertain future with confidence, technology leaders need to get in the lead boat along with business leaders.
The negative reviews
Earlier, I shared my experience of asking business leaders what they thought of IT. I’d like to return to that experience, but also let you in on the story behind it.
Some years ago, I was sitting with a senior vice president of one of the largest chemical companies in the world. This man, a few years shy of 70, oversaw the American operations. During our conversation I asked, “So what do you think of technologists?” He proceeded to say, “I love technologists! T
hey are so fantastic.”
I was surprised, because most business leaders are not so enthusiastic. I inquired, “What do you mean?” “Well, Pat, one of the many things we do is paint cars for automobile manufacturers. When I started in this industry, we had to have a thousand cars come off the assembly line with the same color—because we couldn’t cure the color back then. We had no tools to be able to change colors on the assembly line, so the solution was to paint a long series of cars the same color. Today, because of our technologists, we can paint cars with custom colors quite easily. If you buy a car in London with a paint job in your favorite color, then wreck that car in Germany, we can repaint the car there with precisely the same color. Technologists have enabled our business to offer some incredible features.”
As he spoke, I realized that when he said “technologists” he was talking about product engineering. So, I continued, “Okay. Now, what do you think of IT?” And the VP went from total excitement to total despair. (Sometimes I exaggerate my stories to make a point, but this time I’m not.) He said to me, “Pat, we’re never going to solve our issues with IT.”
That conversation made me think, “I should ask other business leaders what they think of IT.” So, I began collecting data, and over the past two and a half years whenever I found myself speaking to a functional leader outside the IT department, I would say, “In general, what do you think of IT?”
I thought the answers would be mainly negative, but I wanted to be hopeful. Never did I expect that in two and a half years not one person would give me a positive response. One person initially answered positively, but then I asked, “Great! Why are you positive toward IT?” He chuckled and said, “Well, I’m not sure. I want to be positive, but last week they messed up our ERP system and we couldn’t sell for an entire week.” Out of 750 people, not one positive response.
My follow-up question was, “Why do you have this negative outlook on IT?” And 70% of businesspeople could not give me a precise reason. I find that very interesting. It tells me that highly intelligent and highly competent IT people who brainstorm ingenious ways to solve business problems are not viewed as part of the team. They feel like lone wolves; they struggle with communication. Thus, the functional leaders have come to view them as obstacles and not enablers.
What happened?
How did this situation come to be? How long have technologists and business leaders been in different boats?
I enjoyed watching Hidden Figures, a movie about female, African-American scientists who helped NASA put a man on the moon. The women were whiz mathematicians and their job title was “computer”. Yes, back in those days, a “computer” was a human being who was skilled at math. The first electronic computer imitated those human computers’ abilities. Soon, we had the advent of the mainframe and then in 1964, we had the IBM 360, the first general-purpose computer, a central processing unit. For the next 20 years, those large computing devices lived within a function of the business, such as operations or engineering. Data processing belonged to a function and was not generally a shared service.
Let’s say you work at an airline in 1976. Your job is to book airfare for customers and you need computing devices to process those transactions. However, if you wanted to communicate with the customer, you would either need to type and mail a letter or place a phone call and hope they were there to receive that call, as answering machines were not yet in home use. Likewise, other business functions generally had no computing devices at all. Sales? Doubtful. Marketing? Probably not. They had physical paper and typewriters, but not data processing.
Data processing came first to functions that handled transactions, such as payroll and taxes. Engineering also used computers when they needed to calculate something faster than a human computer could. Before 1981, technology assets were decentralized among the functions of the business. Everyone either had their own computing systems to do their own, specific job or they had nothing at all.
The advent of the IBM PC in August 1981 was a game changer. When the PC came on the scene, it provided increasing freedom from the typewriter and gave access to computers to more functions in the business who previously had none. By the mid-1980s, the PC was widespread in the business world and there were many business applications written for the PC. Increasingly, accountants no longer had to reconcile statements by hand, clerks didn’t need to retype letters they made mistakes on, and managers were able to type up their own reports. It was at this time that technology assets which were once decentralized in their own departments began to be centralized for efficiency and supportability. By 1990, Microsoft was able to collapse the needs for word processing, spreadsheets, and slide sharing into one usable, friendly, functional tool; Microsoft Office. With Office, everyone in the organization could use a shared set of tools. Likewise, there were other suppliers that helped to consolidate and centralize the IT needs in communication, manufacturing, supply chain, and a myriad of other areas. This furthered the pull toward IT centralization and the technologists were separated into their own department. The goal of IT centralization was to efficiently share assets but the unfortunate result was IT isolation.
So, IT centralization has not always been the status quo. Formerly, the tool was closer to the business functions—in fact, it was inside that function. But during the mid-1980s and 1990s, that tool became a shared service. Over the last 20 years, the IT department has lived outside of the function it serves, whether sales, marketing, product engineering, or anything else.
What’s the problem with that? The problem is that speed has now increased in the functions to such a rapid pace that sharing resources is no longer practical. If the entire organization is sharing a resource, that resource may be too slow to react to any one particular business need in a certain function. Suppose you are the head of marketing and you’ve been charged with understanding exactly which customers you should send a promotion for a new product launch. Some of the data you would need would be contained in your ERP, CRM, and other systems and some of the data you need would be external. If you waited on the IT shared service to provide you with the data for this promotion, you may miss the product launch. As the marketing leader, you might create your own Data Analytics solution that looks at both the internal data about your customer and also the external data, so you could make the right decision in a timely fashion.
As a reaction to this problem, the pendulum is now swinging away from centralization toward decentralization. Decentralizing those assets may seem less efficient. However, the non-shared assets become free to support the specific needs of the particular business unit, which actually improves effectiveness.
The emergence of new assets in technologies has furthered decentralization by helping business functions to handle technology themselves; smartphones and tablets put control back into the hands of the user. Cloud and SaaS-based solutions (Dropbox, for instance) let the user demand the application logic, not depend on a centralized asset for that logic. Business functions embraced DIY and stopped relying on the shared service as much.
Not all technologists are supportive of this shift. Some younger technologists resist decentralization because they don’t realize that a centralized technology organization hasn’t always been around. Since they are only in their 20s or 30s, many presume centralization has been around for eons, not just the last 25 years. Others believe that technology decisions are best left in the centralized IT department who are most capable of managing those assets. They often react in fear like Chicken Little (“The sky is falling!”) calling this newfound independence “Shadow IT” or “Rogue IT” in an effort to resist and delegitimize it. They must realize that decentralization is not the end of life as we know it, but rather an intelligent effort to connect technology to function and make sure we are in the same boat.
To summarize, the shared asset became slow and extremely disconnected from the functions of the business. Then, due to technological advances, the business functions decided they could hand
le matters themselves. The IT department resisted, but the business could not afford to depend on shared services that did not react to their specific needs. The functions couldn’t wait anymore. The desire for efficiency was outweighed by the need for speed.
That’s why the technologists are in a different boat. They are thoroughly disconnected from the business functions and the functions are trying to solve problems on their own.
Decentralization
One of my favorite books is The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford. It’s a novel about DevOps, which is an integration of Development with IT Operations. Basically, DevOps practitioners want to “get in the boat” with the business leaders. Their pitch to the leaders is, “You tell us what you need. The developers and IT operations will execute simultaneously.” The question is: how do you get Development and IT Operations to walk in lockstep?
As The Phoenix Project opens, the company Parts Unlimited has problems. One is that IT is operating as usual. Technologists are in a vacuum and not enabling business success. Major projects are failing and the competition is outflanking them. “Project Phoenix” is supposed to be a breakthrough, but it has been in development for three years, gobbling up time and money.
The solution for Parts Unlimited was to integrate the components of their business together. The company dealt with many continuous improvement issues, especially the theory of constraints (see Eli Goldratt’s The Goal). How do you deal with constraints in the system? How do you deal with workflow? How do you avoid rework? Parts Unlimited applied continuous improvement concepts to the development process and finally started delivering projects on time.
