As IT companies mature, they loss proximity with their customers and each other. This article discusses the importance of relationship building and trust.
In small IT companies there normally is a great sense of responsibility, because the team members work very close with eachother and collaborate close with their customers. Projects are handled by a small group of people. The team makes sure all are informed well and if there is an incident there is a good chance you go ask for the story to act quickly. Problems are typically resolved in a good trusting relationship: the few clients these companies have is the reason for their existence.
As IT companies grow bigger the proximity to customers and collegues becomes smaller. Team members have more fellow collegues to inform as well as they have to learn them the way "we do things around here". To keep all lined up and in order, rules are made, protocols are written and some sort of planning mechanisms are installed to handle the workload. At this stage you see that some customers become more and more dissatissfied, because they aren't handled as quickly and swiftly like they were used to.
This trend carries through into the next stage of growth. Typically, small customers are replaced with big customers who don't deal directly anymore with developers, but with assigned managers. What happens is that customers find it harder to get what they want. The IT business is seen as slow and inflexible. The once trustfull relationship between the customer and the company has changed. Every customers problem is decorated with the highest urgency to regain the proximity that once was, but no longer exists.
Moreover the role of the oldests and experienced developers changes as well. The successfull ones have become managers, due to their success and are thought to understand the business well enough. Typically these managers gain a new sense of proud in that their practices as a developer now are finally paying off giving them the stature they deserve and maybe longed for. The rules and protocols are written in stone and become the new way 'we do things around here'. New rooky developers are trained to learn ´the way´, but are not given all the information and responsibilities, because it threatens the status quo and they are not automatically trusted. If they play by the rules of the game and show that they are successfull, than there is a chance they'll become managers as well some day. This is why some good developers hit the bricks and start of for themselves due to dissatisfaction with the way the company does things and to the feeling that they can do better on their own.
This all seem to work for some companies, because the IT business is still booming and there is plenty of room for all IT businesses to do their business regardless of their ways. However, like in every business there is a point where the growth will stop and the market slows down.
In that moment only businesses that continue to succeed in having satisfied customers will survive.
Rules and standardisation only work when there is a non-complex task to accomplish. For example standardisation is greatly practised and works fine at McDonalds. It works because all burgers have a calculated composition and as a customer you know exactly what you get when you order it, there are no real supprises. You can standardise it every step of the way and this is what McDonalds has done. It offers its products all over the world in a nearly identical standardised fashion and has been successfull with that. When we look at customized (web) applications we can't use this methodology, because the customers of customized applications don't know in advance what they´ll get. This is typically the result of the mutual collaboration proces. The outcome is very much dependent on the customers business logic and can't be created by following a recipe. In this collaboration proces a specific user story is made clear and will be translated in application innovations. This process repeats itself over and over during the relationship and nobody knows what the platform will develop into eventually. It's the outcome of a itterative process of incremental innovations and basically is continuously changing and adapting to the business logic of the customer. It's much more complex. Therefore rules and standardisation won't work in this dynamic reality, because as soon as they are written in stone they become obsolete. Also they are not rich enough (don't provide answers) to deal with a new situation. So, rules and standardisation are no way to deal with this, than what does work? The way small companies have always coordinated their business and that is with mutual adjustment and communication. Communication is much more rich and tells the story faster and better and works as a vehicle. While mutual adjusting helps in continuously closing the gap between the actual state of the application and the business.
In any relationship to make a commitment and become involved, trust and understanding is of great importance. This is particularly true for a patient who ends up in a hospital for some problem he is enduring. In the treatment process he wouldn't want some unskilled doctor messing around with him and trying out experiments that have a high probability of an unknown outcome. The patient has to be able to trust the skills of the doctor and the advise given. The patient is very much dependent on the doctors skills and knowledge to resolve his problem. While being treated, the patient is providing great insight in his inner workings. He 'll be reluctant to do so if that doesn't lead to a relationship where his story is translated into an improvement of the situation, which is in some way is feeling better than he was feeling before het entered the hospital. Creating or customizing web applications is in a lot of aspects like the doctor-patient relationship. You can replace the patient with the customer, you can replace the situation with the application and business logic and the feeling better is better business results than they had before the customization\build activities. For IT companies trust and understanding should be build into the process of creation and customization of web applications.
To improve trust you should regain proximity in the relationship with the customer and your collegues. Increasing proximity in the relationship means communicating frequently, directly, clearly, openly, being fair and honest. For example you should be direct, open and clear of the impact of proposed or implemented changes and at the same time you should make sure the customer doesn't get affraid, or feels uncomfortable. He should have no reason for doubts about the proposed or implemented change. Communicating clear entails that you explain things in non-technical terms and develop a language with the customer that explains parts of the application. Images can help a great deal because they are rich of information and are better suited to explain the problem at hand (just like the X-rays pictures do in hospitals). If your company becomes more and more transparant, it's important to work on a basis of trust with your collegues as well. A good change can easilly go bad if it's not dealt with appropriatly in the team. This can be accomplished by working close in teams, which supports rich communication. Members of a good team will be communicating toward the customer more synchronously after a while and this helps improving clarity at all areas.
To improve the relationship with your customers, a history (just like the patient-medical history) is also important. It leads to less need for communication to retrieve the needed support and leads to less frustration, because the customer doesn't have to explain himself over and over again or reinvent the wheel with new rookie developers. It prevents solutions being tried multiple times without learning. Trust isn't always there when you start, but tend to grow over a longer period of time where successfull changes have been implemented. This history creates a certain comfort(zone) for customers that activities employed are indeed necessary, focused on their business logic and right. They often have not this insight from the beginning, but it grows in communication with the webdeveloper, if he shows enough technical knowhow and has the good communication skills. With this customers comfort on your side you are able to act quicker and reduce customer frustration.