Let Your Developers Talk to Customers

Feb 10, 2016

Dear software development managers, please listen. Please, please, please, let your developers talk to your customers. I simply cannot understand the reasoning behind creating several layers of abstraction between our highly-valued end users and our just-as-highly-valued developers.

Large companies run large IT systems. Over time, large IT systems that are used by thousands of users tend to fray at the edges. Things run this way for one country, that way for another. Sales organization A works different from sales organization Z. These things are implemented because the users think it makes sense; because they say it makes their lives easier.

IT management, of course, doesn't like this. The more processes deviate from each other, the higher the cost of support. So, understandably, management creates harmonization initiatives to get things under control - and that's where the trouble starts.

In order to seize control over what's implemented, layers and layers of abstraction are inserted between these pesky end customers with their annoying requirements and our precious developers. So, soon, if you want your software to change, you will need to follow The Process®. The Process® is sacred, The Process® must not be bypassed, and The Process® ensures that the goals of process harmonization are met.

The Process® goes like this: the end user has to talk to the local key user, who, in turn, asks the global key user. The global key user contacts the business architect, who needs to get approval from the process owner. He then talks to the system architect, who talks to the application manager, who talks to the solution specialist, who drafts a solution for the developer (located in an outsourced delivery center) and communicates it via the development coordinator. Once it is developed, it goes back down the chain of reviews and approvals until, about a year later, the end user can actually work with it.

How high do you think the quality will be? How well will the end user's requirements be understood by the developer? Is this a way to ensure customer satisfaction? And don't even get me started on The Support Process®.

We do not need several dozen people to take care of one small change in our software. What we need instead is competent developers who understand the business and can see the big picture. What we also need are educated and motivated end users who go for global instead of local optimization. And what we need more than anything else is management to trust and empower people to take the right decisions about what makes sense and what doesn't.

If we let our developers work directly with the end customers, if we guide and educate them about our field of business instead of controlling and micro-managing them, and if we ensure that there is a consistent vision for our system, then we will end up with something that customers love and developers care about.

We will have developers and designers who really understand the business and the way it works. We will have a tool that is as flexible and powerful as our business, and because we invested our resources into education instead of bureaucracy, quality and maintainability will be even better than before.

All it takes is a rock-solid vision and the courage to trust people to make the right decisions.