AKA: How to build better technology solutions for your organization.
Back in 1994, I worked for a large insurance company. I was building a document assembly system (contract assembly) – one that would receive some notice in the tech world, eventually being written up in PC Week (pre eWeek) and would lead to me consulting for several law firms and insurance companies.
At that time, the IT department interviewed me for a position as a programmer. You see, I didn’t work in IT. I was a business analyst/project manager in a user department – meaning, I was embedded with the people using the software I developed.
Side note: I’ve coached a number of IT Leaders (CIO’s/IT Directors) and IT Departments. In that process I advocate a strategy of Departmental Immersion. The above history is why I do so. I am certain it helps IT professionals gain a better understanding of the user’s world, the true business needs, and, quite simply, empathy. As I often say, “The user is the purpose, not the problem.”
I joke that I didn’t receive change orders, instead my co-workers would walk over to my cubicle, smack me on the head, and say, “FIX THIS!” It was amazing training for impact awareness.
I didn’t take that programmer role, even though it offered me a significant raise at the time. I’ve written about my reasons and spoken about it in my podcast but, in short, there are times to trade pay for opportunity. Given the projects I was in charge of, the people I worked with, and the broad skills I was developing, it was the correct choice.
At the end of that interview, one of the IT managers, someone who had become a friend in the months prior, asked me how I arrived at such innovative solutions. I quipped that I was, “Ambitiously Lazy.” I explained that I simply looked at business work-flow and was willing to work really hard to make the tedious and mundane go away!
But my quippy answer was just that, quippy. Soon after that, I decided to dissect and analyze the thought process and methods I used to create technology solutions.
The result was, Concept Over Process (COP).
Later, with my first consulting company, Concept Over Process became the critical element in teaching them to take a true business-centric view of how to build better technology. Eventually, it would become the longest chapter in my book, The IT Career Builder’s Toolkit and it’s follow-up, Building Your IT Career: A Complete Toolkit for a Dynamic Career in Any Economy.
In fact, one IT leader, a managing partner in one of the largest consulting firms in the world said about my book and specifically about Concept Over Process, “This is NOT a must read, this is a MUST DO!”
Privately he told me that if adopted and taught to new IT consultants entering the field, they could become truly valuable to clients in months rather than years.
Alright… I’ll take that.
LET’S GET CONCEPTUAL
All that precursor for this. Over the next few days, I’m going to publish key elements of Concept Over Process. I hope it adds value to you as a technology professional – and, quite honestly, as a [fill in the blank] professional. When my book was heading toward publication, the copy editor working on the book, wrote me a wonderful email that I’ve kept to this day. She found the material interesting (funny, too) and useful for her career as a copy editor and for her husband, who worked in a totally different field.
Concept Over Process is broadly applicable to a number of disciplines. In fact, I used it when coaching soccer and in other areas where I hope to gain better understanding of the big picture prior to diving into the technical details.
At the end of this series, I’m also going to provide a copy of Concept Over Process, the chapter from my book. I welcome meaningful dialogue on anything I cover and am happy to answer questions or explore ideas further.
CONCEPT DRIVEN / PROCESS SAVVY
I also want to head this off at the pass, though I discuss this in COP as a whole. There can be a reaction, most often by IT professionals, when I emphasize the importance of broad business understanding, that I am ignoring the importance of technical excellence. I consider the reaction short-sighted.
That would be missing the point of COP entirely. It is not an either/or idea. It is a both/and. You must have a strong understanding of the business and you must have technical excellence. As the above heading says, we should strive to be, Concept Driven / Process Savvy.
INTRODUCTION: A PREMISE
Concept Over Process starts with a premise.
A perfectly-defined technology or process, based on a flawed business concept or understanding will produce a perfectly-flawed result.
-and the adverse-
A less-than-optimal technology or process, based on a well-defined business concept or understanding will produce a solution.
The first is a costly throw-away. The second is a solution that can be optimized over time.
The word picture I’ve often used it that of a train hurdling down a track. If we look ahead and see that the track is broken (the concept or understanding), the absolute wrong solution is to stoke the engine and optimize the train’s speed and performance (the technology or process). We need to first fix the track or get the train onto a new track prior to optimizing technical performance.
It is not a perfect analogy but I’ll contend that it is close enough.
END OF PART 1
Let’s stop here today. Tomorrow I’ll publish elements from my book’s chapter on COP. I’ll discuss what to expect, what not to expect, the objectives, and identify the dangers of a process-driven mindset.
If you are impatient 😉 er, I mean, excited to jump ahead in class, contact me and I’ll cheat and send you a PDF of the chapter right away. But only if you promise to stick around for parts 2 and 3.