Preface

I’ve always deeply enjoyed helping people. That moment when you realize the fruits of your labor fulfill a purpose in someone else’s work. Helping is what excites me about work. Having an impact.

My career in technology started in high school when I was a lab assistant, helping people in the computer lab after school. It started as a simple job. By my senior year of high school, I was helping people across the school district: students, teachers, staff and others. It was rewarding work. When people hit stumbling blocks, I had the good fortune to help them overcome challenges.

I say fortune because I had the opportunity to help so many different people. And there’s nothing like helping a teacher before being a student in their classroom. I became friends with many teachers, and learned many things I never would’ve learned in the classroom. We talked while waiting for software to install, or a computer to reboot. Sometimes we didn’t even get to the task at hand because of a tantalizing headline in the news that day and a mutual interest in the subject.

My passion for technology grew into developing software. My mom planted the seeds of success with books, software, computers and encouragement. She knew how much I loved technology.

Periodically, I try to figure out how I got to where I am. I try to find what influences led me down the paths I’ve taken. In many cases, too much time has passed and I will never be able to reconstruct what led me to where I am now. Nonetheless, I still reflect because reflection is what leads to awareness and improvement.

When I reflect on how I approach work, and how I approach improving the work I do, I occasionally find deeply held, faulty assumptions. Things I never thought about, that significantly impact the work I do. I enjoy finding these assumptions, invalidating them, and finding better ways to work.

About two years ago, I became aware of what may be one of the most counterproductive assumptions I’ve ever held. Work, up until that time, was always defined by two fundamental paradigms. I did what I was asked to do. And I was paid for it by the hour. I’ve searched high and low for the seeds of this assumption.

And I’m left with the conclusion that I subconsciously took for granted that work was about exchanging time for money. And the assumption that I could get enough done in an hour to make it worthwhile. This wasn’t an intentional assumption, or something I arrived at after contemplation. This was simply the nature of every job I had ever had. Whether I was harvesting vegetables, babysitting, or coding a website, I did what was asked of me and tracked the time so I could be compensated. This is the nature of most jobs.

As my professional career developed, I encountered things that chiseled away at this subconscious assumption – experiences that repeated, solidifying an eventual place in my conscious mind.

Experiences like software that went completely unused. And complex software that users couldn’t even understand, let alone use. Also, software that was underutilized. I noticed that people often didn’t understand the software they had asked to be built. I saw frequent miscommunication. I saw customers over engineering requests to do things they would never need to do. I found myself suggesting things that would never be needed, in anticipation of making the software flexible.

I was used to taking requests, like taking an order at McDonald’s. My focus was on breaking the order into steps to build the software necessary to fulfill the desired request. Like handing a person a bag of hamburgers and fries and then calling out, “next.” I confused delivering what was asked for with being helpful.

Eventually I realized, what people want isn’t always what they need. I started wondering, what is this particular piece of software worth to my customer? I was shocked when I realized I had no clue. I had simply built what I was asked to build, or at least my understanding of it.

Not knowing if it was worthwhile was disturbing. Even if I felt good about delivering what was asked for, it was a false sense of satisfaction. I was taken aback by the thought that I may actually be doing harm. Was I, at times, burning through customer resources to produce something that wasn’t needed?

Furthermore, because of the ubiquity of billing by the hour, I always felt a need to improve my efficiency. To justify the hourly rate. In a never-ending quest to ensure the work was worth as much as possible, to ensure it was worth something, hopefully enough, to be worthwhile. And maybe, just maybe, to justify the increase that would be necessary to ensure I had room for growth within my own organization.

I became efficient at doing the wrong things, or potentially the wrong things. Occasionally there was a success in the mix. But the majority of the time, the requests weren’t a good idea in the first place. That’s just the nature of an obsession with ideas, tasks and actions. It detracts from a focus on what makes the work worthwhile.

People have ideas all the time. As a consultant, I realized part of my job is to help people validate and refine ideas. But that requires an entirely new skill set. That requires an understanding of value. That requires a conversation about results and desired outcomes and decomposing wants into needs.

I realized that I need to focus on being effective if I really want to help people. That efficiency takes a back seat to doing the right thing. I realized I had to make a commitment to creating value. That’s what helping is really about. Helping isn’t about praise for doing what shouldn’t be done. It’s about doing what should be done.

This book, is based on the commitment I made to value. It will help you understand what this commitment entails and offer some advice for making the commitment with technical work.