Jeroen Boks

I am Jeroen Boks. I am from the Netherlands, if you could have guessed from my speech. I am working at TOPdesk, and I have been working there for a lot of years, since 2003, basically. I have had different roles within that company. I started out as a service management consultant, constantly working at customers to implement our own tools, of which I will show a bit in a second. Then I became head of our support department, and I did that for about seven years during a period in which we were rapidly expanding. During the same time, actually, we started to transform from on-premise software per customer toward a SaaS solution, which became bigger and bigger. Currently we are hosting about 2,500 companies on our SaaS solution, which is about half of our customer file. Most of the new customers and more and more existing customers are transferring.

In my role as head of support and, on the side, as head of ICT internally, I created a team that actually built our SaaS solution. Because of that, I became responsible for those services, and over time it became that big that I had to stop my customer support experience. I am now full-time focused on getting that experience better and better. That is the context I am currently working in and the story that I am trying to share with you today.

What we do: we are a service management provider. Our customers are often people that help other people in different contexts. You might have internal customers, like your own colleagues if you are an HR department, a facility management department, or an ICT department, or, just like we, serving your external customers if you have a product that you are getting out there. You might also be a municipality. Because of that, we focus on all kinds of workflows that come with that. We support ticketing. We have asset tracking so that you know what you are talking about. We are highly focusing on self-service, and of course some processes that also facilitate other things behind that. I am not going too in-depth into that because I am not here for a tool presentation.

What makes us different from the competition, I think, is that we are constantly focusing on trying to fix services. What we often see within an organization is that different departments are trying to help the same customer, but in a fragmented way. Do you recognize that? Getting into your company, are you being sent to the first department? "No, that is the responsibility of the other one." That is actually what we are trying to fix in what we do at our customers. That is where the tool is focused around, and that is also how our implementations take place.

What we basically do, and that must be recognizable here as well, is that we are constantly breaking down silos. Although it might be somewhat different silos than normally are being talked about at DevOps conferences, we are talking about internal departments or service departments that interact with each other and should be working together toward one customer, but often do not. It often happens because the workflows simply do not match.

What we are trying to do is include the customer there also: be in contact with them, give them self-service opportunities, get them self-supporting tools to get there, but also get feedback in. That is very important in that. Of course, in the same chain, you often rely on external parties, outsourcing parties, hosting parties, and other expertise that you include. You need to have seamless collaboration between them as well to serve those customers. Basically, what our realm is about is communication between all those silos that are there.

When we started out in 1993, our first TOPdesk version was actually a DOS version, so we have some legacy. At the moment we have grown into a company that has almost 750 people going around and serving our customers in 11 different countries, and it is growing rapidly. When I started out, we were only 80 people. Now we are 750. We have about 60 customers a month coming to our services. Just to get a general idea, it is a whole mix of different companies, because the type of services that they deliver are often seen in any industry that you can imagine. It is quite interesting to see what kind of customers we are serving.

Recently, we came into contact with one of the people that are also here at this venue, Electric Cloud, which has recently been taken over by CloudBees. We came into contact with them, and they reached out to us because they noticed that we were often serving the same customers and that there is constantly interaction between them and us, making sure that those silos were breaking down at the customer as well. We got into some interesting conversations about why that was happening so that we could optimally work together in that.

Basically, the whole story was around, hey, what is actually happening? You are trying to integrate every expertise that you have in your organization and have them work together instead of working side by side and working around each other. Basically, that is not new. That is all about DevOps, trying to be faster, but trying to be multidisciplinary and working on getting the value out as fast as possible toward your customers. That is not new.

What we actually noticed was that often an element was missing. This is recognizable from my own situation as head of our support department. At the support department, you are actually talking to those customers. While I often hear Agile is very customer-focused, I tend to challenge that a bit. Yes, it is customer-focused, but specific, and I will get back to that in a second.

At the support desk, in our own situation, we often have all kinds of service requests. We want to have new functionality turned on for us, or we want to upgrade the scale on which we are using it, or we have a feature request, or something is not working, or I do not understand it. There are incident workflows to help your customers there. There is an awful lot of knowledge being gathered on the customer experience, which you constantly recycle and constantly update. There is a lot of customer satisfaction measuring going on, not only just in reporting, but also because of the talks that you directly have with all kinds of customers. The service desk is basically the touch point that most customers will find, in our situation at least.

What I noticed while we were doing DevOps, and mind you, I am very much a fan of DevOps, was that something was happening at the service desk. Basically, because we were going faster and faster, we got into a mode where our service desk was becoming uncomfortable. On one side, it could have been that DevOps was too fast, so customers were confronted with new functionality that the help desk did not even see before, and they did not know what the questions were about. On the other hand, people were waiting for functionality that was already mentioned earlier in our marketing campaigns, but it was too late in their opinion. So there was a struggle there to keep up and have the right information available to actually help your customers.

When we dove into this thing that we were talking about, we came to the conclusion that the two worlds needed to be more connected here. Again, has anybody attended Jane Groll's session last day? Yeah. I totally agree with her assessment that both ways of working are not competing with each other. They should complement each other more and should even grow together even more.

To illustrate that a bit, I will start from the DevOps side. Often this is about getting features out toward your customers. This might be new features or adjusted features, whatever you like, or fixed features. They go from a change environment, which is now often served by Agile, which I am very happy about, toward your run environment. But what is often forgotten is that your run environment also consists of an existing product around it. In our case, in general, I think we are changing about 1% to 5% of our application at any time. It is different parts over time, of course, but we are only changing a bit. The Agile part is totally focusing on getting that right and getting the feedback on those changes and making sure that they deliver the right thing.

At the service desk, you are actually confronted with the whole package, and not even just the product, but also the services that you have built around them, which might be consultancy or anything around it, and also the effects of the platform that you are using it for. Just this week, we have seen that a low-level platform can have a high impact in the Netherlands. This week we had a large disruption which totally disrupted all of the telephony systems in the whole of the Netherlands. Even 112 was unreachable. That is a low-level thing that was impacted, and it has a high impact on the customer service and the customer experience.

In my opinion, everything should revolve around customer experience. That is actually what you are trying to focus on. That is what you are trying to achieve. It is very much broader than just the things that you are changing at one time. In one direction, you are working on the product delivery, the information around it, the product itself, and the support around it. But on the other hand, you have a whole lot of feedback, which is broader than just the things that you are changing. That should eventually get on your backlogs, get prioritized. Some things might be important. Sometimes it might be less important and it can wait. Eventually, you will be working together and using each other's frameworks to get the changes done that you actually need, and on the other side, still serving your customers on the whole package that they are experiencing.

Basically, if I come back to the story that we tried to solve at our customers, we identified a new silo: the DevOps silo. That was an interesting challenge. That was a conversation that was taking place, and we were looking at how we could solve this.

The good thing in a company like us and the position that I am in is that we are able to experiment with these kinds of concepts. We are such a company. We are in the DevOps move. We are trying to get the best customer experience out. So let us try it first in-house, learn from that, and build upon that to get it toward our customers again.

Just to give an idea of the challenge we are at currently, we are currently growing quite rapidly on hosting locations. For instance, we are soon opening up in Australia for once. That means that we need to be hosted somewhere near there for privacy purposes, but also for latency purposes. We are opening up hosting locations all around the world. At the same time, we have a rate of approximately 60 customers onboarding constantly every month, and that rate is slowly going up. We need to be prepared for that. At the same time, not just the scale, but also the type of services that is being demanded is changing rapidly. With the introduction of AI, machine learning, and the capabilities that are now out there, we see a lot of opportunities to further improve the way that customers are being helped by integrating that into our software.

Then a full halt, because that did not match, again, with the monolith that we were still hosting for all of our customers, the framework that we had. So we needed to make a change. While scaling up, at the same time we have started to change from monolithic approaches toward our customer, per customer, toward a multi-user environment, a service-oriented architecture which can change rapidly and can easily be augmented with new technologies like AI and machine learning.

To get that out there, we have a continuous delivery cycle. That is not actually new because we have been doing continuous integration already for 10 years. Internally, we would see that as sneaks going around. Every day we have the current state of our software. No matter what any of our 16 development teams have delivered and checked in, it is there. The whole of the company, everybody at support, at sales, et cetera, can see the product change over time, including the bugs during the process. But that is what a sneak is for, and we get a lot of feedback on that before it even reaches further stages.

What we have done the last couple of years also includes our own environments in the staged rollout that we are actually doing toward our customers. The problem that we had, with the support department not knowing what is actually hitting our customers, we have solved by updating them first. They are early in the process. It is an environment which is pretty heavily used daily, and it is the people who need to support it anyway. So they will be seeing the new features early on. If all the tests have gone green, the security test, the performance test, the code tests, then it is going live in an environment that we actually use daily, heavily. The next step is going toward the customers, where we update the customers' test environments first, and then we go into a staged rollout over all of the data centers that we have worldwide.

The last couple of years, we have sped up that cycle from half-yearly releases, or about nine months, up to two weeks. We now have a two-weekly update cycle, which breaks down the big changes that we had in the past into smaller increments that are constantly easily adopted by our customers. We make sure that the changes that are getting to them are small enough to not impact their processes anymore. That takes away a lot of communication internally at the customers, testing around it, and process redesign. We try to get it as low as possible.

That is not fast enough for us yet, because a cycle of two weeks after you have created something is hindering us from getting feedback right away. Imagine that we have a performance bug or something like that. Having to deal with that for two weeks is, in our opinion, not acceptable anymore, also because you know that you can do better.

The first goal in our collaboration internally with CloudBees is that we actually implemented their tool and got grip again on the process that we had. I showed you a couple of stages that we had, and all of those stages were managed by individuals within the development department. They are smart, they are automating stuff, they are scripting stuff. But what actually happened was that we had a lot of silos within the development department. Every step was optimized, but over the whole, it was very difficult to get a grip on it.

First, we removed those steps, we removed all the custom scripts that we had, and we integrated that into Electric Cloud's tool. Because of that, we got one plane that is actually controlling the whole cycle from the development department until the last customer is actually using it. Because of that, we also removed quite a lot of slack. Technically, we could do faster, but we were constantly waiting until the next person got into the office and would push a button. If he was not in, then we had a day of delay or even more. That was not very beneficial. You are not having productive time. We were just waiting for each other. So we removed quite a lot of slack. Because of that, the monolithic releases have now dropped 50% in rollout time. Now we can actually move within half a week, if anything happens, to all of the environments out there.

That sort of looks like this. This is the dashboard that you actually get with the tool. You see the different stages. You see the status in every stage. Now everybody in the development department knows of each other's stage and each other's step, but we do not need those different people anymore. We now have just one release manager who is actually watching the release quality, and if it is good enough, she gives a go for the release, which is actually processing, and then the technology is just going to do the staged rollout until somebody hits the stop button because there might be feedback from a customer or a monitoring system or anything that we are using to get feedback that might indicate that we should not go further.

That was a tremendous step. It takes a lot of slack away and a lot of work that is not very fun to do anyway. What we also gained, because we were centralizing all those steps and the data, was more insight. We are growing. We get more and more services. We got more and more customers with a monolith. So we got lost in the whole process, and because of the data now in one place, we actually get new insights: which releases are successful, which are not, and where to focus on.

The current state actually is that we dropped from two weeks until 15 minutes for most of the releases. That will give us velocity. If anything goes wrong, we can intervene within 15 minutes. In most cases, that will mean that the customer will not even have noticed. We will probably have seen it on the monitoring, or even in our own environments and been warned by one of our colleagues. So there are a lot of steps in between before it hits the customer, and then we can intervene before it reaches the larger public.

The second step, which I think was even the more important one, is radical transparency. I already described that the service desk was pretty much overrun by the velocity that we gained, and now we increased the velocity, so that problem is even becoming bigger. We focus now on getting those silos gone again and trying to get the optimization, because basically what we saw was a lot of feedback from the rest of the organization. Now development was in control, DevOps was in control. Everybody knew what was happening, but not so much in sales, not so much in consultancy, not so much in the support department. All customer-facing departments were constantly behind.

After talking to a lot of people that actually have the same problems, because of course we are not unique, we got into a state where we realized that radical transparency throughout change, sharing information with each other, will help in collaboration, will make people have the same reasoning, the same information to build their decisions on, and often will come to the same conclusion about what needs to be done. That is what we have focused on. Secondly, try to get those workloads, those tools, those insights linked together. I realize that tooling for DevOps is a whole different type of tooling than you have on the service desk side, and you do not want to constantly switch tooling to get the information. It is there, but try to teach your support desk to go through three or four DevOps tools before they actually have the information that they need to serve the customer who is on the line.

What we focused on is trying to make an integration there, and everybody still using their own tools in their own way, but sharing the information that they actually have. That led to insights like this. This is actually a custom-built report based on the information that we now have in Electric Cloud, which shows us the different development stages, the different products that are out there, and the different versions that are in that product. We are not done yet here. There is actually information behind it, when it has last changed. If a customer is calling and complaining about a certain functionality, the help desk directly sees in their own tool, "Hey, this component has changed yesterday." So it might be useful to contact the development team to give them feedback about the product they just released. Or even better, they could see which version is coming up and what is inside of that version. They might be even in the state that they can actually communicate to the customer, "Yeah, we know. We saw what happened, and we already have a fix coming on. Wait 15 minutes, and then you are there."

We recognize the strength of two tools on the development side and on the support side, and we are now actually sharing the same information, but in the format that is useful in the context of the people who are using it. Because of that, something else happens. The collaboration actually kicks in again. I showed you this picture before. There is a lot of valuable feedback coming from the customer side. What actually happened now is that our support department is becoming part of the production process. They actually influence our development department now.

We have module specialists within our support department that are directly linked to specific development teams. If they hear anything from the customer side, they can influence the backlogs. They are talking to our POs: "Hey, this happened because of this release. Could you give this bug fix a priority, or could you get this feature in because people are missing out on something?" This also increases the fun on support. You are not just overrun and constantly confronted by somebody else's decision. You are now actually part of the decision. You can influence it.

The feedback cycle back to development actually has increased. Actually, what you saw here is that we have broken down the next silo in organizations to actually serve your customers in an excellent way. I told you this is an internal experiment, and I think that we are on a success path here. So the next step is going to try to reach out to everybody that we are serving out there.

We are now talking with CloudBees to make this a standard integration. We see the value in it. We see the value in sharing this information. We see the value in using your own tools in your own context and having the freedom to do that. Soon, we will have standard integration here and go out to the general public to actually solve this silo in public again, and hopefully by that, improve DevOps again.

To start up with my initial statement: bringing service desk and DevOps together, yes. You can, and I actually think you should. That brings me to the end of my presentation. Thank you very much.