Talk to your customer support

I just finished having one of the worst customer support experiences of my life, it feels like these experience are getting worse and worse across the board. But I have a thought about how they could be a lot better for both the companies and the customers if we just think about it a little different.

The customer support problem

I spent many years working customer support for a lot of different products and companies. And I can say, people who are angry about automated systems and outsourced employees for customer support don’t understand the problem fully.

Customer support is a money loser for any company and the larger the company gets, the bigger a problem it becomes.

Think about it this way: (Not real math)

  • You buy a product for 20$.
  • The companies profit margin on that product is 5$.
  • You have a problem with that product and call customer support to speak to a person.
  • A customer support person costs 10$ an hour.
  • You spend 31 minutes on the phone with the agent.
  • This company has just lost money by having you as a customer.

The company is actually in a very tough spot here and in a lot of ways it’s not their fault.

Are you willing to pay for support? Probably not…
Are you willing to pay more for the product? Probably not…

I am actually not angry at the company for this, I understand the problem and why it’s hard to solve.

How companies respond

Companies have to make money. Period.
You also want your product for as cheap as possible most of the time.
Customer support needs to be made to cost less.

This is why you end up in annoying automated systems, this is why you get outsourced representatives in cheap countries, this is why they try everything they can to make you use the website.

And actually most of the time this is a sensible approach. Customers support is 99.9% repetition (made up number), every customers support job I have ever had consists of solving the same 4-5 issues over and over again. Automated systems and cheap people reading scripts is a fairly effective means of solving this. Most people have a very smooth experience when they have the 99.9% issues. And if they don’t they might also make you go away and deal with it yourself, which is also a way of keeping their costs down.

At the end of the day it comes down to this, a company of any significant size works to make their customer support cheaper, because in order to get you to buy their product in the first place they need to keep the product at a competitive price.

A different approach

But what if we approached this problem slightly differently? What if instead of addressing the symptom, the high cost of support, we addressed the underlying root cause, the issues causing the support requests.

What if had the people who build the product, in software: development teams, spend time with the customer support? Or even spend time doing customer support?

I have worked with teams who took this approach in the past, and I can tell you that we see a very different outcome.

The development teams start understand where the problems in their product are, and they are able to attack them at the root cause. The 4-5 most common problems are the first to go.

  • They are able to identify the ones caused by errors and fix them, these calls stop coming in.
  • Then they learn about the calls that are caused by people not understanding the product, they make changes that make it easier to use, these calls stop coming in.
  • Sometimes they see the issues that are too costly to address the root cause of, but a lot of the time they are able to provide the support some tools to address them faster and easier, these calls now cost less to address.

A different way of looking at the problem.

In the first way the company tries to solve the ”customer support problem” they do make it cheaper, but they do so with a lot of upfront investment and ongoing costs.

They need to build and maintain that automated phone system.
Taking on an outsourced support partner is a huge initial and ongoing cost. They need to compare companies, negotiate terms, sign contracts, train people, pay people, deal with legal requirements of that country, quality control the partner is delivering on it’s obligations, the list goes on and on.

But with the root cause approach, every time they fix a problem they save these costs into the future and often for only the upfront investment.

It also provides a much better experience, which creates happy customers, which makes their brand better, which makes more people buy their products.

At the end of the day the root cause approach is better for everyone.

Not a silver bullet

This won’t fix everything, issues will still be there. Some people would still require support and be a higher cost. But maybe the companies support costs are low enough that they can see this as a cost worth taking? And if not, well, they still have a much better experience for the customers who had the original 4-5 issues.


What is Value?

Understanding Value

We talk a lot about value in the Agile world, but value is hard to define, and a lot of the time I feel organisations misunderstand the value they deliver.

Take one minute and try to answer this question. Write down your answer.
”What is the value your organisation delivers?”

Now, Take one minute and try to answer this question. Write down your answer.
”What is the value your Toyota delivers?”

Did you answer something like a car or other vehicle? If so, consider this, if tomorrow Toyota invented a personal transport system that could safely, cheaply and instantly transport you anywhere, would they lose all of their customers?

Of course not, because that’s a great product, but the main reason they would keep all their customers is because they would still be delivering the same value. The value that Toyota provides is not cars, it is transportation.

If they invented a transporter that could transport groups of 5 or less people and 1 cubic meter of luggage, a distance of 900 km, at a speed of 200 km/h before needing to be refuelled, with an entrainment system,  would they loose all their customers? Again, the answer is no, because they don’t just provide the value of transportation, they provide that value under certain constraints. They don’t cross oceans, they don’t transport huge amounts of cargo. They transport a certain thing, at a certain speed, at a certain cost, in a certain situation.

The car is not the value they provide, it is the mechanism by which they provide it.

But why does any of this matter?

Because getting too locked into the mechanism leaves you vulnerable to disruptive innovation, while at the same time stifling your own innovation. All a competitor needs to do if offer the same value with better constraints to hurt you.

Blockbuster declared bankruptcy in 2010 due to being unable to compete with companies like Netflix and Redbox.

But Blockbuster had every advantage in this fight. They already had access and agreements with the content distributors, they already had a huge and loyal customer base. If they had adapted quickly when they saw this change in the market they likely would have blown theses companies away.

Blockbuster didn’t provide the value of renting movies.

Many people don’t know that Netflix has been around since 1997, they provided DVD and Blu-Ray rentals via traditional post for a very long time. Netflix realised that the value they provided was not that of renting movies. They provided the value of entertainment, and by changing the mechanism and constraints by which that value was delivered they were able to take the world by storm.

Do you think it matters now?

Agile is about being able to adapt, not about being able to deliver features faster. Agile organisations need to focus on the value they deliver, not the mechanism by which they deliver it.


Calling it Kanban

I have been taking a liking to Kanban a lot the last couple of years, it’s feels to me like a natural evolution for most Agile people from Scrum. Don’t get me wrong, I like Scrum, and I find a lot of it’s practices to be great. And in many contexts perfectly well functioning.

But the last 3 teams I have worked with wanted to try Kanban, or so they said… I think there’s some kind of picture in peoples minds about what Kanban means, and I have rarely seen a team claim to be doing Kanban who I would say actually is.

While that is a little hard to say, because Kanban is so light weight, it does have a few rules, and limit Work in Process is one of them. The problem I am finding is, teams don’t actually want to do Kanban, what they want is to stop estimating, and stop committing. I’m not even saying I have an issue with this, I feel estimating is a precarious activity at best, and a wasteful and destructive one at worst. I don’t have a problem with the concept of no longer committing to Sprints, I think a flow based work cycle feels a lot more natural. But I think what most teams think they are getting with Kanban is what many developers dream about. ”Just leave us alone, it will be done when it’s done”. To me, this is not at all what Kanban is about…

Kanban focuses very heavily on delivery, that’s what I like about it!
Kanban focuses very heavily on collaboration, that’s what I like about it!
But they are right about one thing, Kanban doesn’t focus on estimation, it focuses on Lead and Cycle time, which I personally think is a much more effective system of gaining predictability.

I wouldn’t really take issue with this, except that I worry there are many work places that are starting to think of Kanban as a bad thing, because there teams are not really practising Kanban. So, what kind of things do I see?

They generally don’t have WIP limits, or ignore them, which is essential to the success in Kanban. When you don’t use WIP limits, you lose almost all the value, you just end up with a lot of work started and nothing finished. There’s no drive to unblock tasks, just keep pulling stuff in.

They don’t measure they cycle time and lead time, so they cannot have any predictability, and the question ”When will it be done” is answered with ”shrug… we are using Kanban”. This makes it not very popular with managers you can imagine 😉 When we have reached stability in Kanban, that’s a question we should be able to answer very easily ”7-9 days” type of thing. Also, with no metric, it makes it very hard to gauge improvement.

They generally just have a board that says To Do -> Doing -> Done, which is fine if that is indeed how your process works, but it basically never is, this is actually something I see in Scrum teams a lot as well. The board is a visualisation of you’re process, and as such it should represent how things work, not how you want them to work, and not just so you have a to do list. If you can’t see where things flow out from the point of ”code committed” then you don’t actually have any idea how much WIP you have. Also, you need to understand the inflow into the team. I am huge fan of visualising the refinement process in Kanban.


The in and outflow are estential to success in Kanban. In order to get that predictability, you need to be able to have things arrive in a somewhat standard state, and have them leave with ease.

One of my favourite tools in Kanban or lean is the concept of explicit policies. Explicit policies are extremely helpful, not just in identifying discrepancies in the way the team works, but how to collaborate on fixing them.

So, a few quick thoughts on Kanban. You need WIP limits, otherwise you just have post-it notes on a wall.
You’re visualisation has to be representative of your process, otherwise, it’s just post it notes on a wall.
The other things can maybe wait a bit, but I think having a workshop about those early on is very valuable, and I will be doing a writeup soon about how I’ve started doing this.

I have several projects I organise in this way, running my company, the conference I organise, but those are a different context, and I don’t really need a Kanban approach in those projects.So, If you’re not doing this stuff, I don’t mind.

But please stop saying your doing Kanban and making organisations allergic to the word… It makes my job so much harder 😉

Standing up when you make a mistake

Anyone who knows me knows that I am a firm believer in Lean and Agile principles. One of those principles is ”Respect People”, which for me extends far beyond simply treating people politely, although it includes that, it also means respecting that people are human beings and all that comes along with that.

One of the things I see in this is respecting that people make mistakes, and I try to believe that there should be no shame in that. We act in the way we see best at that point in time, and it is a certainty that at some point we will make a mistake.


The issue is usually not that we make mistakes, but that we lay blame on others when they do, and this leads to people trying to cover up their mistakes due to the shame and pain that comes along with it. I don’t believe in laying blame, mistakes are inevitable, and if you accept that you come to realise that the only relevant question is how we improve as a result of those mistakes. In Scrum language, we need to Inspect and Adapt.

So, I try very hard to make sure I admit to my mistakes when I make them and learn from them.

Standing up

Not long ago I published this post:
Which talked about a negative experience I had when I started with a new team. It occurred to me that some people may have been offend by this post , which caused me to re-examine it and determine I had in fact made some mistakes. This was never my intention, but none the less, I feel I should stand up and say so. But being a human being I will of course also try to justify my mistakes 😉

This post was about how I perceived what happened, and that I don’t make any apologies for. But that doesn’t mean that others are expected to share my viewpoint. And when I read through it again, I realised there were many things that I did not make clear and that was unjust of me.

Inspect and Adapt


There are a few things that when I re-read them I realised lacked the needed context.

”The team had not been informed that I would be working with them beforehand, so the first word they had of a new team member was when I was standing in front of them.”

This was not entirely accurate, most people were aware that there would be a change, I had even met some of them in the interview process. But most were not aware that a decision had been reached and that I was starting on that day. The organisation itself did feel they had informed people, which I’m sure they did, but many people made it clear they did not feel it was appropriately communicated. This was a communication problem, we should have focused on how it happened instead of trying to say why people were right or wrong about it.

”What’s more, there was a team member who had been serving as Scrum Master in a part time capacity, I was being brought in so that he could focus more on development work. Which he didn’t know until I was standing there in front of him. It actually turned out he was very upset and had clearly stated in the past that he was keen to remain Scrum Master.”

I realise now this might have given the impression that this person held it against me in some way. This could not be less the case! He was very welcoming, supportive and helpful. He was a pleasure to work with, and an all around good person. My reason for saying this was because I felt it did hurt my credibility with the team, I might be wrong about that, but that is my impression of the situation.

”This team was already very frustrated with the way their organisation was handling this transition and now I was just one more part of that problem. I am sad to say it was a blow I was never able to recover from. I worked with them for about 6 months, and I don’t feel I was every actually accepted into the team and as a result was unable to help them move forward.”

I thought about this one a lot, but I don’t feel I made a mistake here. I do feel that I got off on the wrong foot, I do think we never really recovered from it, and I did feel at the time that I was never truly accepted into the team. The team may see that differently, and they are perfectly entitled to that opinion.

This does not however imply that these people mistreated me in any way whatsoever. This was definitely not the case. They were kind and welcoming to me on a personal level, I was speaking more in the work culture divide I felt it created.

My final word on this is that I consider myself the only one responsible for our inability to move forward, if I was not able to overcome this then that is my failing and I need to improve my skills or approach to do it better the next time. I felt embarrassed over the situation and was personally not able to overcome it.


So, what matters now is I try to improve on the situation.

That was the intention of the original post. I wanted something I could have to send to teams and organisations in the future to make sure I took responsibility for not allowing this to happen again.

This post is also an attempt to adapt, I am trying to improve on the mistakes I made by admitting it was me who made them. I will add this post as a link from the previous post. But I will not remove anything from the original as I feel that would be hiding the problem.

I will consider things I write more carefully in the future, because I honestly didn’t think of any possible negative consequences of what I was doing. I try very hard to be an open and honest person, I usually consider this to be my strongest trait. It also means I am not always good at knowing what not to say, which is my weakest trait.

Finally, I will invite anyone who was offended to say so in any way they see fit. You are welcome to comment, I will gladly make you a guest poster to write your own post disagreeing with me (anonymously or otherwise), you can call me for a personal apology, or I will happily buy you lunch and discuss it further.


I am always cautious not to use the names of any person or organisations as I feel it is not responsible to out anyone without their consent, as well as it being a legal question. Please respect this if you decide to comment.

Makers Academy Experiment

My partner, Henrik, and I have spent a fair amount of time discussing how to improve the IT market in Göteborg, and really how to improve the IT industry in general. This is one of our main motivations in creating and structuring it so that we never have any incentive to lower our quality standards (

We are facing a lot of different issues in the IT industry not the least of which revolves around technical excellence.

The question is not one of intelligence, we have absolutely no shortage of brilliant people in our industry, but one of environment and practice. Most people do not enter the workforce with knowledge of modern engineering practices like test driven development, continuous integration and delivery. Once they enter the workforce there is a lot of stress and pressure which results in virtually no time to learn new skills. Sure, they will need to learn things everyday to solve the problems they face, but what about doing more than just solving the immediate issue? What about a larger shift in the way you think or work?

Most day-to-day environments don’t allow for systematic improvement and addressing root causes of problems. Obviously, this leaves underlying problems in place instead of them being fixed once and for all. We can all agree on that this is a great waste. This is especially true in our industry where demand is ever increasing – addressing the symptom will not save us. We need to attack the root cause.

This is why, when we were approached by, we were intrigued. The concept is simple, it is a 12 week intensive coding camp, aimed at teaching people the fundamentals, enabling them to hit the ground running – and keep running. But what is important is that modern engineering practices are considered to be part of this foundation. Students work from day one with automated testing, continuous deployment, and other such skills. Meaning when they enter the workforce and are faced with problem, their instinct will be to solve right rather than just hacking a solution together.

Our hope is that this will contribute to a changing culture in the world of software development, which has already begun, and improve our technical excellence for the better.

But, we have never done this before and there are a lot of unknowns.
Can someone become a good coder in the course of 12 weeks?
Is this program the best way to go about that?
Will it provide value to those who attend it?
Will it be something we are proud to have our names on?
Do we have something to contribute?

As we always do when uncertainty is high, we decided to perform an experiment. We will work with for their first 12 week camp. We will be doing this free of charge and during our spare time. At the end of the 12 weeks we will know a lot more than we do today!

Wish us luck, I will keep you up to date!

Meeting the team

Edit: If you are reading this article, please read this one afterwards as they are a set.

The horror story

I once started working as a Scrum Master with a new team in about the worst possible way.

The team had not been informed that I would be working with them beforehand, so the first word they had of a new team member was when I was standing in front of them.

What’s more, there was a team member who had been serving as Scrum Master in a part time capacity, I was being brought in so that he could focus more on development work. Which he didn’t know until I was standing there in front of him. It actually turned out he was very upset and had clearly stated in the past that he was keen to remain Scrum Master.

This team was already very frustrated with the way their organisation was handling this transition and now I was just one more part of that problem. I am sad to say it was a blow I was never able to recover from. I worked with them for about 6 months, and I don’t feel I was every actually accepted into the team and as a result was unable to help them move forward.

This was really tough for me, as I am an extremely sociable person, and am usually accepted into new groups very easily and consider the trust that builds to be an essential component in my ability to do my job.

More often than not

Even when the story isn’t that bad I find there are a few things that hold me back when starting with new teams.

I’m a consultant

This tends to put me on bad footing right from the start which I think you can’t blame people for. Here is a person who is being paid what they believe to be a lot of money (not nearly as much as people think, but that’s another subject 😉 ) and also works with something a lot of people consider to be very ”buzzwordy”.

They don’t know me. They don’t know that I do what I do because I love it. They don’t know that I would do it for free. They don’t know that I take what I do very seriously and work very hard at making sure I am the best I can be at it.

I listen

I am a very firm believer that the worst thing you can possibly do when joining a new team is to come in and start talking about change right away. Not only is this dangerous as you lack the proper context to know what is needed, but it’s incredibly arrogant to think that you know better than people who have been working in this context a lot longer. I believe doing this will erode trust before it has ever started to build.

So, when I join a new team I generally spend a few weeks simply listening and asking questions before I offer any kind of opinion, doing the ”inspect” of ”inspect and adapt”. I usually keep a document I call ”inspect” which holds my observations and questions during this period.

While I think this is a good practice sometimes I feel it comes off as I am shy (which could not be further from the truth), that I am intimidated, and that maybe I don’t really know what I’m doing.

How can I improve this?

When I started with my latest team I was determined to improve this situation.

I told the person I was meeting with the horror story, explained I was not ever going to repeat that situation and that it was very important I meet and get the blessing of anyone I would be ”replacing” before hand. Happily both those individuals were excited to get the chance to focus on development work again.

To alleviate the more common issues I opted for transparency and honesty. I had a meeting with the team the very first day to introduce myself.

I explained what experience I had, that I was a ”Scrum Master” by profession and that I enjoyed it very much. I told them about the communities I have founded and helped to build and

I explained that I would be simply listening and asking for a few weeks and precisely why I would be doing that. I also explained that I would keep this document of my observations, but that it was purely for my own use and would not be shared with anyone directly.

Finally, I said that eventually I would have some ideas and suggestions and I would appreciate if they gave them a fair chance and tried them out, but that ultimately the process was theirs and theirs alone and I would never attempt to enforce anything that they did not agree to.

Did it work?

I have been very pleased with the result of this.

I think that the explanation of why I was going to be remaining quiet for a while earned me a lot of respect from people and that it greatly accelerated the building of trust. One team member even took the time to tell me how good he thought this way of thinking was.

I think that explaining who I was also helped to establish my credentials so they knew that I wasn’t just some guy who took a two day course and called myself a Scrum Master. And I think that talking about the communities helped to establish this was something I was very passionate about, and not just in it for the money.

But at the end of the day, I ended up with a great group of people and the credit is really theirs, they were very welcoming and open.

How do I do it even better the next time?

One thing I was not happy with was the meeting of the team members I would replace, it happened later than it should of and I am not sure it came across that they actually had a choice in this. I will work on this from meeting one next time.

Also, I think I may start sending this blog post as an introduction in the future.

And of course, keep looking for ways to do this better!