How support and development joined forces to help clients better | Easy LMS Talks

We strongly believe in joining forces. After all, you can learn a lot from and with each other. Also, different perspectives on the same subject help enormously to make a balanced decision.

Development and support are essential in delivering the best client solutions

At Easy LMS, development and support are essential in delivering the best client solutions. They worked together already, but they were separate teams.

Until June 2021, this is how they worked together in a nutshell - simplified and without any nuances 😅. Support was responsible for serving our clients at their best. They spent a lot of time listing to them and helping them reach their training goals. Part of this was answering their questions in chat or demo and logging their bugs and feature requests. Tie it up and go! Then the product owner came in. Based on the information logged by the consultants and his product vision, he decided what feature was built next to and pitched his solution to the development team. The developers made the solution - rarely with help and insight from support - and launched it! Finally, the consultants updated all related content. Done!

Make more use of the team's strengths

As you can read, we could use the teams' strengths better. That's why we decided to bring the collaboration to the next level. A new team was born: a problem-solving team that includes members of development and support. Furthermore, a UX designer and Product Owner are involved in the team.

Interview with team Jabba

At the moment, we have two problem-solving teams: team Jabba (the name consists of all the initials of the team members) and SummerKnowly (named after our mascot). Anna and Joey are members of team Jabba. Together with Communication Owl Caroline, they talk about the details of the upgraded collaboration.

Caroline: Since June 2021, we have the problem-solving teams. Anna, can you explain how the teams process client questions nowadays?

Anna: "Support still processes the client questions; we are the first contact point. We answer them and help them out. If a client reports a bug, we try to reproduce it with some help from development, and if we succeed, we log it as a bug and mark the urgency and impact.

For feature requests, it is the same as for bugs, besides the reproducing step. We send a feature request with as much detail as possible to Productboard, a tool to manage all our feature requests. Our Product Owner Jeroen and UX Designer & Researcher Dyann process those and carefully weigh and rate the feature request against our company's purpose. This results in a to-do list of new features to build."

Caroline: Okay, this looks a bit like the old process; besides, there is more communication and interaction. So, when does development come into the process?

We bring in different perspectives

Joey: "Right at this moment. Instead of the product owner, the teams are responsible for what to work on and the chosen solution. From our problem-solving team, Anna and I are responsible for choosing what to work on next as a team. We bring in different perspectives here. Anna knows what a client needs, while I have a good sense of the complexity of a request."

“We prioritize bugs against potential new features and decide what to work on based on time urgency. When we have chosen, we write down the current circumstance of the issue and the result of that circumstance, so the rest of the team knows why it's urgent to resolve the issue. Then the rest of the team comes in to discuss the solution and write it down. Dyann, our UX Designer & Researcher, often joins the conversation to ensure the chosen solution is user-friendly and easy to understand. The discussion is precious because of the multiple perspectives we bring in. Everyone has a say. After that, we send our proposal to the product owner for approval."

Caroline: Do you always get approval right away?

Joey: “Most of the time. If it isn't approved, Jeroen will have some questions we try to answer in a call or the proposal document. There is some writing back and forth before we get a green light. Once approved, we write user stories (red. a short written explanation of what a user wants and expects) and divide the tasks among the team.

Caroline: Is support involved in writing the user stories too? Before this was only done by development.

Anna: "That depends if it is a feature or bug. We always join for new features, for bugs it isn’t always necessary. Writing user stories is relatively new to us. So, we are working on getting better at it.”

”What we also do is immediately start writing the related content for the new feature. Related content is the labels for the administrator or participant interface or help articles. Furthermore, we need to decide what client communication needs to be done, like in-product messages, direct client messages, etc. We do this alongside the feature getting built."

Caroline: So, the main change is that support and development pick an issue and craft the solution together. You both have more influence on the end result. How do you experience this new working process?

Anna: "It was definitely a change to getting used to the new working style in terms of scheduling and working closely with new people. Which was also a benefit as well. I like to work more closely with developers because they have different perspectives on what to build and why. We make more balanced decisions now. Also, it helps that we see from each other how we work. In the past, we would accommodate issues. We would do more manual work, and that became the norm. Developers notice easily if manual work can be automated or streamlined. It's in their nature to think that way. Their help saved us already a great amount of time."

We now have a lot more insight into what is actually happening

Joey: “We now have a lot more insight into what is actually happening. How do clients use our LMS, what is important to them, and the reasoning behind it. It feels like we are more in touch with the client's needs. So before, an issue was handed over to us after it went through multiple company layers. We were at the end of the process, so much essential information got lost along the way, and many questions weren't asked. We know the system technically a lot better; we look at problems differently. Being with support together from the start allows us to ask questions we need to build an effective and sustainable solution. We could say that the information gap has been closed."

Caroline: We are also doing client interviews to understand our clients' needs better. I assume this is very valuable for the problem-solving team?

Joey: “Yes, it is! Because what clients want is not always what they need. What they think goes wrong isn't always the underlying thing that needs to be fixed. That is very difficult to see as an outsider. So, the client interviews are a valuable tool to reveal underlying issues. They also give us context!"

There is a lot of knowledge sharing

Caroline: Okay, back to the collaboration between development and support. How do you complement each other?

Anna: “There is a lot of knowledge sharing. Besides the consultants bringing in the client’s perspective, we both know different things about the LMS. Leading to the fact that sometimes we know how the tool works and they don’t, and vice versa. So for instance, something is totally obvious to us (red. support), while developers didn't think it worked that way or people used a feature that way. Likewise, we might spend twenty minutes replicating a bug, and if I send a message about it to a developer, they know the solution instantly. So, there is a little bit of that on both sides, and now we get to share that.”

Caroline: Is there a downside too of working this way?

Joey: “No, bringing development and support together was a good step. In general, there is always a downside to changing your working method. You need to get used to it; that could lead to some frustrations. It's time-consuming. But those are just obstacles you need to overcome. It isn't a dealbreaker. We don't want to go back."

Caroline: Can you elaborate on that. What was the most challenging?

Joey: “The most challenging was figuring out how we could use each others' strengths in the right way, and not waste each other's time. In the beginning, it happened a lot of times that we had too many people at meetings and could not contribute to the discussion. So, that was a waste of their time. But the opposite happened too. We had so-called mis meetings. People could have contributed but weren't there. Eventually, we managed by communicating about our experiences and by applying the trial and error method."

Caroline: Anna, what did you learn from the developers in your team?

I learned how to structure my daily work better with fewer interruptions

Anna: "It kind of hard to say. Just kidding. First, on a more philosophical level, the work of developers is a lot more structured than support work. I learned how to structure my daily work better with fewer interruptions. Developers are very strict on their time, which is logical because they need uninterrupted time to do their work—seeing that helps me bring that to my workday. So I learned to keep my time and boundaries better. Then, more on a practical basis, the developers provide me many troubleshooting tips to help clients out."

Caroline: And in return, Joey, what did you learn from the support consultants in your team?

Joey: “I think it is the opposite of the last thing that Anna just said. We always had a lot of ideas of how to fix things; all we could do was rely on our knowledge. But we don't use the system the way clients do. So, by interacting with support, we learned a lot about how clients actually used the system and what solutions would fit them. Before, it was just guessing and doing the best we could. We involve the end-users perspective more in what we do. We can better imagine their situation.”

Caroline: Do you feel we are building better solutions for our clients now?

Joey: "Yes, definitely! A good example of that is our entirely new payment system."

Caroline: As a company, we are continuously improving and changing. But are you now, after eight months, comfortable with the new working process?

Anna: “For me, in the beginning, I wasn't sure how I could contribute. Do I really need to be here? What's my value? What's the reason for me being here? At least, at that part, I'm much more confident now. I see that I have value and have a place on the team."