Software Implementation: Changing Your Tech Stack and SaaS Tools

Modern technical team leaders are becoming increasingly employee-oriented, and rightly so. They want to ensure that employees at their organization are equipped with the devices and gadgets they need to perform their jobs well and with minimal hiccups. Luckily we’re in a time where software options are in abundance. There are a variety of SaaS tools that cater to teams with distinct specializations, from design tools and agile project management tools, to company-wide communication and team collaboration tools: we’re spoiled for choice.

On the other hand, having more choices of software tools also means that technical teams have more difficult decisions to make. If technical team decision-makers become overwhelmed by suggestions for new software, it may be tempting for them to double down on existing tools and deny new requests. But is that really providing the best service for employees? Recognizing your current SaaS tech stack is no longer serving your business or team is a tough pill to swallow, but often a necessary one.

When technical leads take the time to partner with engineers, designers, marketers, or other cross-functional team members on designing their tech stacks, that’s where the magic happens. Decision-makers must empathize with the problem case and the reason why a tool is being requested. Being able to examine the switching costs of swapping or adding new tools to your stack is also an important consideration.

Understanding requests for new tools and software starts with an empathetic ear

There is a path forward that ensures mutual success for employees and technical team leads, and it starts with getting on the same page as to why a request for a new tool or piece of software has been made, and what the current challenges are.

There are so many reasons why teams may request a new piece of software:

• Their current tool may be outdated or not scaling with the team’s growth and scope
• They may be perfectly happy with their tech stack, but need something that integrates with other tools
• Other times, it may be a matter of not knowing what you don’t know. Is the issue with the tool itself or has no one taken the time to properly train employees on how to use it?

Your best bet is to get answers to these questions via team leads or, better yet, work with team leads to find these things out from employees themselves. A department or team survey can be a quick and easy way to get the answers you need. Some fact-finding questions you can ask include:

1. How often do you use this software? How integral is it to you doing your job?
2. What about this tool is currently working?
3. What isn’t working? (Is the issue service reliability? An outdated feature set?)
4. How will the requested tool be used/how will it amplify the team’s current tech stack?

Sometimes, employees are already using these tools, they’re just not explicitly telling their leaders (also known as “Shadow IT”). If you discover that employees are using tools outside of the company’s approved tech stack, try to take a curious, rather than disciplinary, approach. See if you can identify why employees are using the tool and what the impact would be on their work if you suddenly took away their access to it. There’s always an opportunity to learn and partner on solutions at every corner.

Examining the switching costs of implementing new SaaS tools

Beyond price, leaders have to carefully consider other potential costs of switching SaaS tools or implementing brand new ones. Naturally, the team will need to take some time to integrate new tools into their processes and learn how to best work with them. So, some critical factors to assess when it comes to switching costs include:

Onboarding and ramp-up time for new tools

How long will it take to implement this new software securely? How long will it take for teams to adapt to using this new tool and will they have to slow down to learn how to use it? Is this change in behaviour expected by team leads and is it OK? New tools such as project management software and team collaboration software can be a big switch for a team, as they are such a central part of day-to-day work. So, it’s important to set your team up for success.

These are all questions you have to find the answers to in conjunction with department leads. After all, it’s important that they also understand when they may potentially be doing something that hinders or slows down output.

Adoption and ongoing usage

How will you ensure that employees are perpetually getting value from the software? How do you ensure that new products are being optimally used by teams (i.e. you’re not paying for more accounts or “seats” in the tool than you need or are actively using)?

Gauging the usage and adoption of tools within your organization should be a regular practice. Understanding how much and how often teams are using their tools can also help you assess whether employees are in need of brand new solutions or whether the solution is to help them maximize on their existing stack.

You can always reach out to a software’s customer service team and ask for additional help on employee training and coaching. It also helps to have an internal champion, usually a member of the team or a team leader, who encourages employees to provide feedback and adopt better usage habits of the tool.

For example, at Zenhub, we offer our users several of these services to help new users get off on the right foot. We run regular webinars on how to best use our product, offer professional training services, and have the Zenhub Community where people can learn from other users on how they are using Zenhub in their teams.

Choosing new software for your organization

Let’s say you’ve conducted your fact-finding survey and have determined that you need to purchase a brand new software solution for a department or team. It’s important that you’re partnering closely with department leads on finding a new solution. Avoid surprises — like showing up one day having already chosen a tool — at all costs. You’ll need the department lead’s buy-in to later get the rest of the team’s buy-in, so don’t skip this crucial step.

Come up with criteria together for what the tool needs to do or have to be useful to the team. Department leads will likely talk about the jobs to be done, while IT leads will have a lens towards security, interoperability, etc. From there you can narrow down your choices together.

At some point, you may want to put together a small focus group of employees and share the different options with them for their input. Remember: the more buy-in, the better.

Supporting the adoption of new tech tools

Like any other major endeavour, it helps to have a project plan when it comes to introducing new tools to teams. Are you going to need to migrate or merge data between platforms? Will one tool need to be “sunsetted” officially (and rendered unusable for a period of time)?

There are many layers to rolling out a new piece of software. Aside from figuring out the learning plan for how employees will train with the new tool, you’ll also probably need things like:

New software implementation is a process that requires a lot of patience and it can’t succeed on one team’s shoulders alone. By building a strong partnership with department leads and taking the time to understand the core needs, technical team leads can provide outsized value to organizations. With this approach, your company and team can be the kind that introduces tools and processes that wind up generating revenue, not just saving costs. Now that’s an impact.