Every one of us is dealing in one way or another with high technology. Whether it is by trying to develop a product, trying to deliver a service, or just preparing our slides for a presentation, we all deal with the high-tech world. This usually means that we must communicate with high-tech people, and typically the results we get are dependent to some extent on how well the high-tech people do their work.
Communicating with high-tech people is a challenge. Not only do they speak their own brand of jargon, they also tend to be very literal. Like the literalness of the computer itself, high-tech people seem to think that if you ask for a three-pronged left-handed widget (or a thingumbob, if you like), then if they deliver a three-pronged left-handed widget to you, you should be happy.
Unfortunately, it doesn’t work that way. With software, for example, the requirements are never completely known. Typically, when the first working model of a new software system is shown to the people who asked for it, their reaction is: “Oh. I see what you have here, but what I really want is something different.”
This can be frustrating for the technologists who worked for a long time on the development. One of their countermeasures now is using Agile development practices, in which a working prototype is shown to the “customer” early and often. This allows the developers to correct their course early and gain confidence that they are building something that will actually be useful.
But why is it so hard to specify what we want in advance? Is it because we don’t speak the same language as the techies? Or is there something inherent in high-tech that obscures the simple outcomes that we know we want and we think we have asked for?
I believe it is both. Not knowing how high-tech stuff is constructed, we don’t know which jobs are hard to do and which are easy. We also don’t know how elaborate the underlying structure has to be in order to get what looks like a simple result. So we ask for things that we want and find ourselves puzzled by the groans from the technologists who see years of work ahead of them to satisfy the request.
We also don’t really know what we want when it comes to interactions with a computer-based system, because the possibilities are endless and the examples we’ve seen in the past color our view of what we think the interactions should be. For example, if you’ve used Word Perfect for years to do your word processing work, you will not find it easy to switch to Microsoft Word, because the interactions and functions are different.
There’s a new discipline in computer systems development called user interaction (UX) design. It calls on specialized skills ranging from graphical design, human perception and interaction protocol design, to database design and web programming. But even as this new discipline is helping to make systems easier to interact with, no one can substitute for you, the user or customer, in defining what the system should do.
Sometimes you have to say, “I want it to be easier to use than this,” when you see how a system works, even when you don’t know how to make it easier. If you challenge the development team to try different ways to make it easier, you will usually get something better.
But this poses a problem. If they are experimenting with various ways to make the system easier to use, how long will it take to get to the finish line? How much will it cost? The fact is that doing engineering and design requires creativity and experimentation. And you can’t schedule a breakthrough.
So you have to settle for setting a limit on how long or how costly the project is to be. An entrepreneur may run out of money before delivering a satisfactory system. But if you are constrained to actually get a working system, you want the best you can get within the constraints.
This comes back to the Agile approach. If you ask to be shown a working prototype often, you can do course-corrections frequently while you also gain confidence that the developers are meeting the most important criteria for your project, because you make them show you how the system meets those criteria first.
The Agile Management Bottom Line
Give up trying to specify everything at the start. Begin by prioritizing the key features or results you need, and ask for frequent demonstrations of a working system. You’ll end up with a lot more confidence in your high-tech developers, and they will be less frustrated with you.
—–
John Levy helps business managers who are frustrated by the lack of results they are getting from IT or Engineering. He specializes in rapidly getting high-tech teams to align with business strategy and to contribute to business success of the enterprise.
John has been consulting for managers in industry for over 20 years. John’s book on management for technology executives, Get Out of the Way, was published in May 2010.
For more information, please visit his website at https://johnlevyconsulting.com ,
Email him at info@johnlevyconsulting.com , or call 415 663-1818.
About John Levy