Jeff Bezos on believing and persisting

In a previous post, we talked about two key starting points for change: belief and persistence. Forbes magazine recently came out with an insightful piece about how Amazon.com grew to become the giant that is is today.

Bezos: [...] Our first shareholder letter, in 1997, was entitled, “It’s all about the long term.” If everything you do needs to work on a three-year time horizon, then you’re competing against a lot of people. But if you’re willing to invest on a seven-year time horizon, you’re now competing against a fraction of those people, because very few companies are willing to do that. Just by lengthening the time horizon, you can engage in endeavors that you could never otherwise pursue. At Amazon we like things to work in five to seven years. We’re willing to plant seeds, let them grow—and we’re very stubborn. We say we’re stubborn on vision and flexible on details.

In some cases, things are inevitable. The hard part is that you don’t know how long it might take, but you know it will happen if you’re patient enough. Ebooks had to happen. Infrastructure web services had to happen. So you can do these things with conviction if you are long-term-oriented and patient.

Reading this excerpt made things click in my mind. If you're old enough to remember -- Amazon was in the red in its first 3 to 5 years. Despite this, Bezos persisted. Shareholders kept believing and investing in the store. Amazon kept wowing its customers even though they would lose money doing this. (I know some friends who got 2 copies of books they bought because the first shipment didn't arrive on time, so Amazon Fedexed replacement copies to rectify and then the first set of books arrived a week later). 


Just imagine. You're a fledgling company, you're losing money because you're not reaching the right  sales volume, and you insist on delivering great customer service at a loss. Most would have given up. Bezos believed and persisted and slowly, Amazon thrived. I especially like the last part of the excerpt on ebooks ("they had to happen" -- what faith this exhibits!). Bezos was ahead of his time and waited and waited and waited. 


To compare: as an IT businessman, I also saw that ebooks were coming (way back in 2001). So I made this proposal for an ebook store and sent it to some local book publishers and distributors I knew. They gave a lot of excuses. They hemmed and hawed. My faith on my proposal was weak and I threw away my proposal. Ten years later, I am buying ebooks. If I only persisted, I would have become a pioneer here in the Philippines. Today, I've made peace with this and treat it as an important lesson for me and my students in change management class.


If Amazon did not have a long-term vision in mind, and Bezos wasn't persistent, and his stakeholders weren't convinced of Amazon's long-term vision, then we wouldn't be seeing much of Amazon these days. I am thankful that Amazon and Bezos were stubborn. 


Read the full article on Bezos and Amazon here. 


Read the previous blog post titled "Believe and persist in your advocacy"

Believe and persist in your advocacy

All IT and software deployment projects are change management problems to solve. If you don't handle the change management aspect very well, your deployment will fail. 

* * * 

In my change management class (which we formally call Leading Organizational Change), I always emphasize that the first step in advocating for change is to first believe in that change. Have you encountered salespeople who tried to sell you something but didn't really know what they were talking about? They came across as insincere and nothing they said could sway you to believing them.

In the same manner, if you don't believe in the change you're pushing (it could be an IT solution like an intranet, an information system, or even a community effort like a school feeding program), your target audience (aka intended users or stakeholders) will sense your insincerity. You will come across as fake and you will blow your chances of making change happen.

On the contrary, when you believe in the project you are rolling out, you will have a genuine concern for people who are resisting your efforts. You will ask them why they are not buying into your effort and you will find ways to convince them about it.

I had an epiphany when I was considering switching to a Mac. For about 23 years, I have been a user and staunch defender of PCs and Microsoft. A Mac store attendant tried to convince me to switch. He asked me what was making me hesitate and I told him that I feared the Windows tools I was using (like MS Project and Visio), wouldn't be on the Mac. Without speaking a word, he activated BootCamp and started up Windows on a Macbook. That was my turning point. It started with a store attendant being genuinely concerned about my issues.

When you believe, you win over people. More importantly, you gain another strength as a change advocate: persistence. Persistence will help you survive through resistance and opposition. 

As the person leading change, you are put in a dangerous position. Heifetz and Linsky point out in the book Leadership on the Line that your opposition will try to use politics, seduction (offer you distractions to divert you from your advocacy), and character assassination against you and/or your project.

Once, a livid representative from a customer company threatened to kick our team out of a project (that's a different story to tell). Our team thought the customer company would benefit a lot by using a new but very flexible Technology X. We found out later that Livid Representative was leading an in-house development team who was creating a similar solution using Technology Z. They probably wanted to claim credit for discovering and creating the solution for the company. Hence he threatened to kick us out of the contract. Of course, our team stood down and grudgingly supported what the in-house team was doing (after all, we were only contractors). It was a clunky and dirty technology -- we knew because we had a taste of the power of Technology X.

We swallowed our pride, but we persisted in using and promoting Technology X. Years later, the company rehired our team to deploy exactly what we previously recommended to them. It turns out that the company grew dissatisfied with their in-house team and the Solution Z. Desperate, they hired an independent IT consultant who recommended -- guess what? -- Technology X.

We secretly gloated and we knew we wouldn't have reached this goal if we gave up that early.

First, get the process right

Instead of using IT to initiate change, focus on the process and people first. Put the customer at the center, reorient the processes to delight the customer, then create the IT system to support the improved processes. Managers and IT developers, take heed!

* * *

Here's one trick I've learned in developing an IT solution. First ask, what process is our IT solution going to enable or support? Then, we build the IT system to fit that process. I've found this to be very effective in increasing the chances of success. And by increasing chances of success I mean making the software really useful, enticing users to use the system and get attached to it.

After a couple of IT project failures, I reevaluated our development approach. We hinged our hopes on the thought that employees will use software because it will make their work easier. But most employees are not naturally techies at heart. Instead, they think, "New software = more work." I've seen this happen many times that I thought we should start approaching development in a different way.

To change the approach, simply reverse the premise and assume that employees are usually averse to technology solutions. This opens up a different development approach. It forces us to design and develop around the needs of actual users. It requires us to understand the work process that users and actors go through, and how our IT solution could facilitate that process. It also involves working more closely with the users/actors, which in turn brings more buy-in for the solution.

One of my earliest clients to agree to this approach did not take a lot of convincing. She knew that their different branches used different procedures to perform the same job. She saw the sense of first seeking to standardize the different office procedures before attempting an IT solution.

So first, we embarked on writing down the steps for each core process, noting the variations. Next, we took a look at their policies, guidelines, and legal documents to find the minimum requirements. Then we improved the procedures by asking the question, "What value does this procedure give to the office?" With this filter in place, we were able to remove non-value-adding steps, redundancies, and outdated activities in the process. We closely consulted the users/actors who were involved in the processes.

The result were improved office procedures that were leaner and faster. The manager issued a memo introducing the new, standardized procedures, and tied these to the incentives of branches. Hence the motivation for adapting the new procedures was not IT itself.

When time came to build the IT solution, we simply got the improved flowcharts and used them as bases for the software. And since we worked with the users/actors to define the new procedures, the people  saw how the IT component snapped in place to facilitate the new procedures. This in turn built more enthusiasm and anticipation for the coming of the new software.

In traditional IT development, we often neglected to focus on the processes and the value that these processes delivered to the office and the employees. But the revised development approach, we gain a new lens on managing an IT project -- one that allows us to focus on the things that matter and to treat the client as development partners.

This demonstrates how, in many cases, management complements IT. Management's strengths can make up for the shortcomings of IT,  and vice versa.


Related article: IT is not the solution.

IT is NOT the solution

I often preface my talks and lectures with this statement: "IT is not the solution."

After saying that, I can separate the veterans of IT projects from IT development newbies. The veterans will nod in agreement and the newbies frown at my puzzling statement.

Blame it on the phrase "IT solution" that the industry uses. The term tricks us into thinking that technology is the solution by itself. It is not. Information technology is only an enabler or facilitator of the real solution.  

I'll give an example. In one failed database project I've been asked to troubleshoot, the boss (let's call him Mr. A) expected that a document tracking system (let's abbreviate it to DTS) would solve the pesky problem of employees consistently misplacing important files. Yet, when the software was built the problem persisted. They even installed bar codes and scanners to make DTS more convenient to use.

Mr. A asked me if RFID (radio frequency identification) would help improve the DTS. Apparently, some vendor had approached their company and told them that bar codes are history. The real solution is RFID. Why? Bar codes need line of sight and people actually "shooting" a scanner on the bar code. RFID gets automatically detected without people having to do extra work. 

I interviewed him and his staff to find out more about the problem. What I found is that even if they had installed RFID, the real problem would still continue: employees did not buy into the value of tracking documents easily. And Mr. A never really understood that installing the DTS would need at least two factors:

1. A change in the office procedures to add a checkout step. ("Before you bring that file out, please sign the logbook.")
2. A records officer who would really do his job. ("Hey, where are you going with that file? Bring it here and sign the logbook.")

None of these steps require technology. They in fact require a change in staff behavior. And to change behavior, Mr. A needed to convince employees of the value of checking out a file.

Mr. A had too much faith in information technology and he thought installing the DTS and a nifty bar code or RFID system would automatically change the procedure. In reality, employees found it tedious to log the file they were borrowing for just a few minutes. By not seeing the big picture (ie, if we lose the important files, we lose time and money trying to hunt down where the files are currently located), the employees did not buy into the need for logging and tracking documents.

So remember: IT is NOT the solution. Remembering this will help you make your IT projects less prone to failure.