Five Strategies for a Happy and Healthy Software Maintenance Team

Software Maintenance Teams provide a broad array of services, customized to the industries they support. As a software development consultancy, our portfolio includes industries like energy, aerospace, healthcare, medical devices, precision agriculture, and others. The products we build live on Desktop, Embedded, Mobile, Web, and Cloud platforms.

With such a diversity of industries and platforms, our Maintenance and Evolution team also needs to be diverse. We need experts in multiple technologies, techniques, and domains. Our staff may be called to support a mobile app this week and a desktop app next week. We need to act quickly when our clients have a high-priority need – which may mean interrupting work already in progress for other clients. Here are five strategies we use to delight our clients while keeping the software maintenance team healthy and happy.

Strategy 1: Getting Comfortable with Change

At any given time, our team is actively supporting four to five products. Team members are typically responsible for concurrent support of at least two products. We recognize that priorities are fluid. Setting this expectation ahead of time enables better management of the chaos and is key to keeping the team happy, engaged, and efficient.

We manage most of our portfolio via electronic Kanban board. We like GitHub Projects, but some clients prefer Cardboard, Jira, Azure DevOps, or Trello. Kanban allows us to focus on “what’s next” while also providing a deeper view of what’s important. We collaborate with each client to ensure that their highest priority items are being addressed. We also recognize that their priorities change. What is most important now might not be what we thought would be important a week or a month ago.

Priorities must also be balanced across our portfolio. We need to respond when clients have high-priority concerns. It is important to determine, in advance, who is responsible for managing inter-project priorities. In almost every case, it is not a developer. We have a single delivery lead for the entire support team who manages prioritization, team assignments, and any inter-project negotiations.

This provides two advantages – the managers aren’t burdened with the day-to-day management, and the developers have a single point of contact for managing assignments and priorities. By adding this layer, we separate managing the client relationship from daily technical management and low-level decision making. Our managers appreciate offloading daily management and developers appreciate that priorities are expressed in one voice.

Strategy 2: Managing The Skills Mix

SEP’s Maintenance and Evolution team provides Tier 3 support for a broad array of platforms, domains, and technologies. In a perfect world, the perfect developer would be available at the perfect time for every request. But it’s not a perfect world. These are complex software products serving complex product domains built with complex tech stacks.

For larger and long-running engagements, we have the opportunity to build expertise within the team. Maintenance engagements that include Evolution impart opportunities to capture deeper technical and domain knowledge. Including a developer from the original development team will accelerate the learning curve.

It’s a bigger challenge to build our knowledgebase for smaller or short-running engagements. Getting sufficient time to learn a new domain or a new tech stack may take several iterations. Fortunately, many of the products we support were also developed by SEP, so there is usually a resident expert to help us learn the technologies and domain.

What is Tier 3 Maintenance

Where Tier 1 and Tier 2 focus almost exclusively on help desk and knowledgebase support, Tier 3 teams are focused on deeper problem solving. They are responsible for fixing bugs, resolving infrastructure problems, responding to changes in platforms or third-party integrations, and developing new custom solutions.

Most of our clients have their own Tier 1 and Tier 2 support organizations, as part of their larger customer support organizations. If an issue requires a deeper technical dive or identifies an issue with the function or performance of the product, our team springs into action.

Strategy 3: Being Transparent with Clients

We never want to surprise a client. There can be times when their priorities are not our priorities at the moment. We may not have a team available because everyone is fully engaged with other clients.

We are transparent about how we transition their product from development to support.

• Sometimes, someone from the development team joins the support team, either permanently or temporarily.
• Other times, we arrange for someone from the development team to help onboard the support team.

We are transparent about timelines.

• We let clients know when they are sharing developers with other support teams.
• We try to set realistic expectations about when those software maintenance teams can start working on their projects.

We discuss team availability during the quoting process, especially for clients who depend on shared teams. And we let them know the potential impact on our ability to respond.

Strategy 4: Pairing Engagements

Oftentimes, larger support engagements have some built-in flexibility – times when the client needs full go development and times when they need us to pause a beat. This is especially true for bucket-of-hours style evolution-heavy engagements. We can leverage slack time to staff smaller engagements, especially maintenance engagements that only need a few days of support per month. It’s a great way to support our larger evolution clients at the velocity and spending levels they need, while also reserving capacity to support our smaller maintenance clients. For this to work effectively, it is important to manage our skills mix, so it’s easier to support multiple clients. It’s also important to be transparent with clients, so they aren’t surprised when their team changes.

Maintenance vs Evolution

In a prior post, we explored the need for both reactive and proactive support.

Reactive support (Maintenance) is a necessary service – fix a bug, restart a cloud service, or check compatibility with a new version of Android, iOS, or Windows.

Proactive support (Evolution) recognizes that software is never done. It must continually grow and adapt. We leverage feedback from users to evolve the product to delight existing users and attract new ones.

Strategy 5: Maintain your Tools

Nothing is worse than returning to a codebase to make a simple update, only to spend a week updating the development tools or finding out that libraries are riddled with security concerns. Convincing clients to pay for enough support to also keep the tools up to date is difficult, but will ultimately save them support dollars and time in the future.

Bonus Strategy: Food

SEP runs on food. It’s embedded in our culture. There is no better way to get the entire team in one place for a casual conversation and a little team building, than over a meal. Take an hour or two to restore bonds with the folks on the larger team. While it’s important for the support teams to schedule outings to celebrate a milestone, it’s also important to schedule outings for the entire software maintenance team – across the entire portfolio. One big team!