Get in the Boat

by Pat Bodin

  Get in the Boat: A Journey to Relevance

  © 2018 Pat Bodin. All rights reserved.

  Printed in the United States of America.

  ISBN-10: 1-946203-20-3

  ISBN-13: 978-1-946203-20-5

  —Disclaimer—

  Although the author and publisher have made every effort to ensure that the information in this book was correct at press time, the author and publisher do not assume and hereby disclaim any liability to any party for any loss, damage, or disruption caused by errors or omissions, whether such errors or omissions result from negligence, accident, or any other cause.

  Table of Contents

  SECTION I.

  How Business Works

  Chapter 1.

  What’s Around the Bend?

  Chapter 2.

  The Architecture of Your Business

  Chapter 3.

  Value Chaining

  SECTION II.

  HOW PEOPLE WORK

  Chapter 4.

  The Color of Business

  Chapter 5.

  Fulfillment in Your Job

  Chapter 6.

  CAT: Core

  Chapter 7.

  CAT: Risk

  Chapter 8.

  CAT: Language

  Chapter 9.

  CAT: Motivation, Care, and Challenge

  SECTION III.

  UNDERSTAND GREEN

  Chapter 10.

  Business Model Canvas

  Chapter 11.

  Risk

  Chapter 12.

  Financial Analysis

  SECTION IV.

  SPEAK BLUE

  Chapter 13.

  USIM: Understand and Simplify

  Chapter 14.

  USIM: Identify and Measure

  Chapter 15.

  Competitive Advantage

  SECTION V.

  ELEVATE RED

  Chapter 16.

  Are You a Lone Wolf?

  Chapter 17.

  What Do You Fear?

  Chapter 18.

  Three Steps to Elevate: How to Change Your Color

  Chapter 19.

  Three Steps to Relevant Execution

  SECTION VI.

  COMMUNICATE RELEVANTLY

  Chapter 20.

  Be Interested, Not Interesting

  Chapter 21.

  Value Mapping

  Chapter 22.

  Conclusion

  Reference

  Acknowledgments

  About Pat and Robert

  Bibliography

  DEDICATION

  For Chrissy, my wife of 30 years.

  Life with you is always a relevant journey.

  FOREWORD

  I wish I’d read this book at the beginning of my career – or even 20 years ago.

  Let me step back and share how Pat and I first met. We met when we were both presenting at a conference a few years back. Pat was just fleshing out the Impact Framework, a system to easily understand people and their roles, and he and I had a lively discussion about Green, Blue, and Red people and their roles in a company. I have to admit that I didn’t quite get it at first. I interpreted the colors as representing a specific meaning for each role. I mean, of course I wanted to be Green. They are the decision maker. Everyone wants to be Green, and the Blue person just sounded like a bore, so I wouldn’t want to be him. Red is always bad, right? It means “stop”.

  Pat bluntly informed me that I had it all wrong. The colors weren’t symbolic or significant – they were just shorthand for the roles they play. Green = Decision Maker. Blue = Business Enabler. Red = Product Producer. He said if it helped, I could assign any color to any role. Purple, Gold, and Platinum would work just as well. The essential point was that there are three basic roles, and each of these roles is necessary to the success of a company. For example, without the Red people, nothing would get done. You’d just have a bunch of Green and Blue folks sitting around talking. All the Colors are good, if done well.

  I started to understand the message, but I still privately thought, “Well, sure, but I still want to be the Green guy.”

  When I read Pat’s book, however, I realized that, though I understood the concept of the roles, I hadn’t quite grasped the importance of the framework in which they operated. As I sat in the lounge of my hotel in Melbourne, you would have thought I was reading a thriller or some kind of comedy. I was absolutely absorbed by the material. I finally appreciated the significance of the colors and why it is important to know not just what role you are playing, but also what role the person you are working with or for is playing.

  Knowing the role tells you how to relate to the person you are talking to.

  Think about that for a second. At the end of the day, we don’t do business with companies, we do business with people. In any negotiation or discussion, there is simply a person on the other side of the table, and your goal is to find out what you can do for that person – how you can be relevant. One of my favorite quotes from Pat is, “Be interested – not interesting.” The goal is always to understand the objectives of the person sitting across the table. Never be afraid to ask the simple question, “What does a good day for you look like?” Let’s be honest, other people aren’t truly interested in what you are saying unless it is making their world better in some way. If you can find a way to the person on the other side of the table – a way to contribute to the growth of their company – you’re relevant. The easiest way to do that is to simply ask what they need.

  Years ago, I went to my company’s Senior Sales leader and said, “I don’t know exactly how we’re going to do this, but I know what outcome I want. What are the top ten accounts this quarter and how can we (IT) help you grow them?”

  I guess he saw my passion and sincerity for the project because he gave me the green light.

  And then he gave me stock. In advance.

  Understand what I’m saying because this is a big deal in my world. He gave me a bonus before I had produced a single thing. I cannot tell you how great it made me feel to be rewarded by the client – to have his confidence. It meant more than the stock reward – just knowing that he was backing my idea was huge.

  Years later, I found myself in a similar meeting with Sales leadership. I had a good working relationship with the lead guy because I had consistently delivered on my promises to his organization. He had half an hour to hear my proposal and I spent the first 20 minutes telling him in detail what our organization did, how much collateral we generated, and how we delivered content – basically, how much work we were doing for the company. I could tell that he was just waiting for the time to pass until he could be out of our meeting. He was probably making a grocery list in his head while the minutes ticked by.

  I got to the last 5 minutes of our meeting – the part where I talked about how we were driving growth and how we had developed a program that placed an IT advisor on all of his top accounts. My main message was that that my team had their backs. The guy completely lit up. I had his full attention as I described the plan in that few minutes and I realized that I should have started our meeting by discussing growth and the IT Advisor program without all the technical preamble. We could have spent the majority of our time really discussing how best to partner and make these efforts successful.

  You see, this guy didn’t care about anything but customer success and growth. Well, I’m sure he cared about his family and world peace, but in his work, his top priority was growing the business. He simply doesn’t need additional information. Our relationship has grown leaps and bounds since these interactions because he knows that we share a common goal. Once I started speaking to the outcome he was trying to drive, we were speaking the same language.

  This
is the fundamental reason that technologists are rarely invited to have a seat at the table: We are not effective at communicating our relevance to leadership. We have developed our own jargon and defined our own processes in isolation. When we come to the table for the discussion, we are speaking an almost completely different language from the rest of the people at the table. I mean, for example, we use the word “virtualization” all the time, but there is literally no translation for that word in any other language on the planet. That’s because it is only meaningful to technologists. No one outside of our discipline has a true understanding of it. We also think that the hard stuff we do is what we need to tell people about because these things take the most time and effort. The truth is, the other people at the table just need to know how we can help them get where they want to go. We need to be asking them “What are your goals and how can we help you achieve them?” Further, we need to be able to express ourselves in a common language.

  I have an employee on staff who is a super technologist, just incredible. They can talk “Speeds and Feeds” to anyone in purely technical terms, but they are also able to explain tremendously technical processes in a practical way to people who don’t need to know precisely HOW something is done. This is the sort of communication style that technologists need to learn.

  Pat and Robert’s Impact Framework gives us a methodology for doing just that. They offer a means of getting to the table and for being a part of the discussion once we get there. That’s what made this book such an exciting read for me. It was a clear, quantifiable explanation of what I had seen in action over the course of my career.

  I do wish I’d had this book 20 years ago, but I also find it very useful right now. It’s a book for any stage of your career, and those of you at the early part of your career are doubly fortunate. You will have the insight and tools it has taken me decades to acquire. Read the book with an open mind and get ready to learn about principles you can put it into practice right away to become a key asset in your organization.

  Use this book. Utilize the Impact Framework. Be wildly successful.

  Lance Perry,

  Vice President

  Customer Strategy and Success

  Cisco Systems

  INTRODUCTION

  I’m a hard-wired technologist. I’m proud of what I know. In a more revealing moment, I might even admit that my technical competency is where I find security. Over 30 years ago, I started my career in public accounting, but it wasn’t good enough just to be an accountant – I had to be a CPA (Certified Public Accountant). When I went into computer engineering and worked for a few Fortune 100 companies, most notably Cisco Systems, I sought the most thorough and prestigious certification available at the time, the CCIE (Cisco Certified Internetworking Engineer). My goal, though I would probably have not admitted to it, was to be the smartest guy in the room and to have the credentials and experience to back it up. I felt my work, by virtue of my knowledge and experience, had meaning and importance. Boy, was I misguided!

  Over the years, I found that expertise was simply not enough for satisfaction in my work. I enjoyed creating something from nothing. I liked the challenge of solving a problem someone else considered unsolvable. This is at the heart of why I was drawn to IT. It is a difficult, ever-changing world of problems requiring complex solutions and creative innovations delivered on almost impossible timelines. However, once I had mastered infrastructure technology, I was ready to move on to a new challenge: training others to master IT – architecting it, selling it, and using it.

  I created Firefly, a technology training company, in 2003 as an answer to the biggest problem I saw with typical technology education. IT training made a lot of paper experts, but few people with real expertise. I believe this came from trainers who tended to have little to no experience at actually doing what they were teaching and from course curricula that favored marketing over practice. My company solved this lack of experience by combining professional services (mentored implementations) with the absolute best technical training available and became wildly successful because of that. After 10 years, Firefly had become a global success and it was time for me to move on to the next thing, so I sold it to a European consortium and took a few months off to chase down my next challenge.

  I had been toying with an idea, just a thought, really, about what makes work meaningful. I knew that I was happiest in my work when I felt like what I was doing had meaning and it wasn’t a question of how much money I was making or how much I could prove I knew, but of how I was using my knowledge to solve problems and create new concepts. That was clearly part of my satisfaction with my work, but I wondered if that was the path to a happier professional existence for everyone. I began my quest for an answer by reading, of course. I really enjoy concepts conveyed in a narrative, and my favorite writer of business narratives is Patrick Lencioni. His most famous book is The Five Dysfunctions of a Team: A Leadership Fable, but the one that really had an impact on my life is The Three Signs of a Miserable Job: A Fable for Managers. In “Three Signs”, Lencioni declares that you must know the people you work with and you must be able to measure what you do, two things I believe most corporations lack. What really captured my attention and imagination, though, was the assertion that you must have relevance. Lencioni says, basically, that you’re not relevant because of what you do, but because what you do affects other people.

  The moment I read this, it became crystal clear that in technology and in STEM (Science, Technology, Engineering, and Mathematics) professions, relevance begets meaning. You become meaningful in your work because you are relevant in how you impact other people. So, as a technologist, how do you communicate the relevance of what you do to your organization? How do you decrease the friction between the technologist and the business leader or customer so things can happen faster and better? Can you answer the question of why you do what you do in the context of what your company provides its customers? How do you even get a seat at the table?

  In the past, the downside of not including the technologists in business decisions was less severe because changes were few and spread out over time. Today, though, our businesses are experiencing change at speed and businesses can’t afford to make decisions without their technologists in the mix. The paradox is that while Technology is more important than it has ever been, technologists are often still kept at arm’s length from business decisions and discussions. This is the crux of the problem that this book seeks to solve.

  I think of it like whitewater rafting. The business leaders are in the first boat. They are reading the river to determine the best route, while the technologists are being towed behind, picking up oars or coolers that the passengers in the first boat may have dropped. This setup may work well enough when running down Class 2 rapids, but today’s businesses are running at Class 5 speeds, and towing the technologists in a separate boat is impractical and downright dangerous. There have been several companies over the past few years that have ended up with damning coverage in the Wall Street Journal due to the disconnect between the business leaders and technologists, especially in areas like cybersecurity breaches. We need a better way. We need the technologists to “Get in the Boat” with the business leaders to mitigate the daily challenges in real time and not purely in a reactive mode. It is imperative that organizations perceive technologists as relevant to the ongoing success and health of the business.

  During a business trip to Munich about a decade ago, a colleague took me to Octoberfest where he introduced me to Robert Schaffner. I found a kindred spirit in Robert. Like me, he was striving to find meaning in work, and in 2013, we found ourselves in Paris at the same time, having lunch at my favorite restaurant on the Bois de Boulogne. There, at Le Chalet des Îles, overlooking the pond, we sat talking about finding meaning and relevance in work for four hours over a very decent little rosé.

  We spoke of our frustration with technology suppliers who often sold products without understanding the customer’s real
problem. We believe that great technology selling should always be about the customer’s needs and not about just giving them another widget. Customers have problems and a great technology company provides solutions to those problems – not just the next new thing that the customer didn’t know they needed. We discussed our concerns that companies generally fail to connect the dots between what their products provide and what the customer needs. Thus began our journey into relevance.

  Robert and I, along with our colleague Michael Pohl, spent the next four years creating the Impact Framework. Over those four years, we found that there is an opportunity for Technologists to value chain what they do and what the organization needs. We realized that there are actually psychological and sociological differences between technologists and business leaders and we had to find a means of bridging the gap. We struggled to find the right methodology. We tried different approaches and different business models and we drew on a variety of domain expertise. In the end, the final piece fell into place simply because I didn’t feel sufficient in my knowledge.

  It wasn’t the business knowledge. I have that. I’m a CPA, and I’ve built successful businesses from scratch.

  And it wasn’t the engineering, the technology. That’s been my home nearly my whole life.

  Then, last year I went back to university (after too many years to count) to complete the Lean, Six Sigma Black Belt certification and that led me to the missing piece. What I was missing was the process. For instance, you can’t actually deliver complex infrastructure technology directly to the business. You have to go through a framework to convey the relevance of the technology you are delivering. What we’ve done is create a framework that provides a systematic model you can use to be relevant. Every. Single. Time.

  We have arrived at a way to teach you what you didn’t learn when you were acquiring expertise in your field. What technologists and other STEM professionals are missing is the understanding of how to plug into an organization and connect the tangible (the things that you do) to the intangible (the thing your business needs or wants) through the business process and how to communicate your relevance to your organization.