Thursday, October 24, 2013

Supporters to the teams!

Yesterday I wrote about customer support and how it is separated from the rest of the organization in many cases. (Read Blog Post).

At Jimdo, one of my clients, we discussed this topic quite often, and Jimdo (once again) is doing things differently when it comes to support work. Here are some details which might be worth sharing.



Quite some time ago, there was a whole lot of support tickets that were directly related to the work of the payment team (or „painment team“ how they used to call it at that time). Everyone who has ever tried to provide credit card payment for his services knows that everything related to payment is a big pain in the a...
So at this point it felt natural to have a support person directly in the team. This was a huge lever! The developers could understand better what problems the customers were facing, and the supporter got a better impression of what was going on in the payment team and shared this knowledge with the other supporters. They were so satisfied that they never thought about releasing the supporter from the team again. The opposite was true - they conducted an experiment: What would happen if we pair-program with the supporter? Sounds silly? Again, it was a big success! They gained an even better understanding of the „other world“ (development and support). And something else happened: Not only were they pair-programming, but also pair-supporting. So the developers were „forced“ to deal with real support tickets and use the same tools the supporters use day by day. Here again the very simple trick paid off: Bring together the people who are facing a problem with those who can solve the problem! It turned out that sometimes a developer could simplify support work with rather little effort (e.g. writing a script to automate things), while the support person did not even know that this was possible! So it was no question that the experiment was successful, and know paring with the supporter has become a kind of standard in this team.
The payment team might be the perfect fit for pulling a support person in. But why shouldn’t the same principle work for other teams as well? So kind of the next logical step was to do this for all other development teams as well.

P.S. When it comes to support, there is another interesting thing going on at Jimdo, which is called Support Alarm Party. But that is worth a future blog post...

P.P.S. Jimdo is one of the the most fascinating company I have ever seen. Fridtjof (one of the founders) and I will present the Jimdo Story at Lean Kanban Central Europe 2013 in Hamburg, Nov 4-5. Also we have written a small online booklet called „Management, Alignment and Leadership at Jimdo“. You can find the German version here. And this is the English version

Wednesday, October 23, 2013

Support – shield and sword of the company!

During the past couple of years I happened to see a lot of different teams and organizations. Although every organization is unique, there seem to exist some common patterns. The one I find most disturbing is the complete separation of the support department from other parts of the organization! What do I mean by this? There are a couple of development teams (no matter what kind of product or service they are providing). And then there is a support team department which deals with customer requests. And there is almost no connection between those two. Often they are located in different buildings, cities or even countries. And in big enterprises it is quite common to even outsource the customer support to a separate company. This is a disaster! The support people are usually the ones with the most customer contact. They know very well who uses the product we are developing (whereas sometimes the developers, project managers etc. seem to not know this); they know very well how our customers use our product, what they like and what they don’t like about it, where they’re facing problems when using our product etc. So they are very, very valuable when it comes to feeding the things we are developing back into the development teams. But usually organizations don’t do that. Or they do a survey once a year to ask the support department what features were requested most often by the customers. Even organizations which are quite mature when it comes to agile software development rarely do so. This strikes me to be absurd, because customer feedback plays such an important role in the agile world. But instead of bringing together the people who have the problems (as represented by the supporters) and those who can solve the problems (the developers, admins etc.), we separate them carefully. This leads to dissatisfied customers and therefore more requests for support. And what do we do? We hire more and more support people and train them to deal very efficient with customer requests. And sometimes we hire other people who should bring the customer perspective back into the teams.



And there is another perspective to this pattern, which makes it even worse. Not only don’t the developers know what the customers want. But the supporters don’t really know what the developers are developing. But the support is the first (and mostly the only) direct contact our customer has with our company. How can the supporters deliver an excellent customer service if they have no clue which features will be developed (and when), which ones are already in progress, which ones won’t be developed at all etc.?

I hope now it has become clear why I see supporters as the „shield and sword of the company“. But instead of respecting this and using this huge potential, very often organizations treat them as cheap resources. I suggest we start thinking about the role and the value of support and how we can use this potential to deliver better products/services to our customers.

Stay tuned: Tomorrow I will publish a second post on this topic with an example of how companies can do it differently.

-> Read the follow-up: Supporters to the teams!