Here on the Lagoon team, we find ourselves in an interesting and somewhat unique situation. There are just seven of us, located across the US, UK, Australia and New Zealand, and yet we find ourselves wearing a lot of hats supporting all of our customers while developing Lagoon and managing it as an open-source project. So how do we do it? It’s not easy!
So what are we doing, and how do we manage? Let’s get into it!
Obviously, we do feature development for Lagoon. Some of those features are initiated and planned by us as a team, and some are requested or necessary for clients. We also fix any bugs that come up. As Lagoon is technically complex, comprising multiple services and tools, we need a lot of time and clear space to be able to develop effectively.
Then there’s support. You’re thinking, doesn’t amazee.io have a support team? Of course we do, but sometimes issues arise that require an in-depth level of Lagoon knowledge that our support team doesn’t have, so those issues come over to the Lagoon team. These are paying amazee.io clients, so they generally take priority.
We also have a newer offering that we are working on at amazee.io to offer Lagoon-as-a-Service (LaaS). This is for customers who want to run their own Lagoon, but pay for support to help with it. Their requests go to the amazee.io support team first. However, their questions tend to be more focused on the ins and outs of Lagoon, and since they need to be competent with Kubernetes to take the LaaS approach, many of their issues get forwarded to the Lagoon team. Again, these are paying clients, so we generally prioritize these issues.
The final tier of support is community support! Lagoon is an open-source project, so there are always teams who are trying it out, playing with it, and asking questions. We absolutely love our open-source users, and we’re thrilled when someone new pops in to ask a question! However, we have to figure out how to support them without taking too much time from the rest of the work the team needs to do.
So how do we triage all of these issues and keep everyone happy without dropping the ball?
And did I mention there are only seven of us?
The most essential thing is to establish what support looks like for each level of customer so that we can manage expectations on all sides. amazee.io’s hosting customers all have contracts that determine how quickly issues must be responded to and resolved, and we work with the support team and TAMs (Technical Account Managers) to keep our clients happy and in the loop while we work through issues. Also, as a global team, with global customers, we also need to ensure that we can minimize the time taken to resolve these issues - which means trying to reduce the reliance on a single person to “own” a particular element of Lagoon
When we started developing the LaaS program at amazee.io, we knew that it would hinge on our ability to support these customers, so we put a lot of thought into it. One of the initial things we decided was that these customers must be competent enough with Kubernetes and Helm that we wouldn’t have to hold their hand on the platform end of things - that their support needs would be limited to Lagoon itself, and not managing their cluster. This takes a lot of weight off of our teams in terms of support. We also drew up guidelines to outline what support looks like for these customers, and how issues are escalated. We work closely with these clients, and our Lagoon Lead functions as a TAM for them.
And then, of course, are the community users. We love them and want to support them, and don’t want them to feel like they don’t matter! That said, of course, we need to support our paying clients first. So how do we balance it? As with LaaS, we drew up a document outlining how support is escalated.
Community support can be tricky. We want to help everyone, and we want everyone to succeed in their efforts to use Lagoon as an open-source product, or we wouldn’t put it out in the world to be used! But our resources are limited. When possible, we point people to our documentation or example repos. We do our best to be responsive in community channels, even if it’s just asking someone to create an issue so that their problem doesn’t get forgotten. Often, other users will chime in and help, which is exactly what we want to see in an open-source software community!
We are in the process of planning an official community launch, and one of the things we want to happen is to have all of our Lagoon users of all levels to be able to interact in one space. Ideally, one of the things that will come out of that is that the community will start to support itself, and when a user has an issue, another user will chime in to help, as you see in many community tech spaces, like StackOverflow. Right now, our users are siloed in their various channels, so we are working to bring them all together. Keep an eye out for more community news this summer!
It’s not easy getting it all done, but documentation is a key part of it. Both having thorough documentation on your product, including FAQs and common issues, as well as documenting your support and how you escalate and triage issues. That way everyone knows what to expect, what is expected of them, and whose responsibility it is to respond to a given issue.
Top comments (0)