In many companies, especially large companies, there will usually be some sort of process for acquiring and approving software for use in the company. These processes can be quite fast and agile, or quite slow and arduous, but they are generally in place for an understandable reason: If everyone can just pick and choose the tools they want, completely without restriction, there will be chaos.
Collaboration becomes harder, onboarding of new employees becomes harder, and there will be very little control over spending and security. However, it is easy to also fall into the opposite trap: over-standardisation. If you try to lock everyone into using the same tools, with the goal of reducing spending and increasing security, you will likely not improve either, and also get a host of different problems. That is what I am going to write about here.
Miro was introduced as a digital collaboration tool in Telia some years ago. I became aware of it around 2020. My team started using Miro in the middle of covid lockdown, as a tool that allowed us to collaborate relatively efficiently, even though everyone was sitting in their separate home offices.
Miro advertises itself as “your team's visual platform to connect, collaborate, and create — together”. It is a collaborative online platform where teams can visualize and organize their ideas, projects, and workflows. It offers a versatile digital canvas for creating and sharing content, enabling real-time collaboration, task management, and integrations with popular tools like Slack and Jira.
We have utilized Miro for a range of uses, from brainstorming sessions and workshops, to retros and documentation. Both for synchronous collaboration while in a meeting (digital or face to face), and asynchronous collaboration.
Recently, a decision was announced to decommission Miro as an official Telia tool. The replacement tools suggested was a combination of Microsoft Whiteboard, Microsoft Visio, Jira and Confluence.
If you are a Miro user, and have any knowledge of the suggested replacement tools, it will probably not come as a shock that the internal response to this decision was not overly positive.
If I were to put myself in the shoes of whoever made this decision however, I can easily see how it would make sense.
I do not know any specifics about how this decision was made, so the following sections are riddled with assumptions.
Let us assume that you are responsible for purchasing software for Telia. In general, your job is to make sure that we as a company have the tools that we need, and that we spend as little money as possible to get them. One obvious way to not spend money needlessly, is to not pay for the same thing twice.
Given this situation, you go through our software portfolio. You know that we are paying for Miro as a digital whiteboard service. You ask the users of Miro what it is being used for, and they give you some examples:
- Workshops and collaborations, utilising digital post-its and drawing
- Documentation of different activities, like workshops and user insight
- As a task tracking and planning tool
- As a system for diagramming user flows and other, similar things.
Then you take a look at the rest of our system portfolio. You see that we are paying for the MS Office suite for all employees. This includes MS Whiteboard, and Visio. You also see that we are paying for Jira and Confluence licenses for more or less all the employees that also have Miro licenses. Together, your opinion is that these four tools can provide everything Miro is used for.
While an individual license for Miro isn’t necessarily expensive, in total, for all users in the company, it becomes a significant amount. It also makes sense that all employees should be able to use the same tools for the same tasks, and only a few employees, relatively speaking, are using Miro.
So, you land on the obvious solution: We should stop paying for Miro, and migrate usage to the other applications that we are paying for.
In all systems, there is a tension between standardisation, and flexibility. Having standards help different parts of the system talk to each other efficiently, but reduces the ability of different parts of the system to tailor solutions to their specific needs. Having flexibility does the opposite. Individual components can get exactly what they need, but communication between different components in the system becomes a lot more challenging, maybe even impossible.
An organisation is a system, and one way of viewing that system is as a collection of teams and individuals. Standardising tools can aid in the collaboration between teams. If we are all using the same tools, and know the same systems, we can easily share information between the teams, and even individuals between the teams, because it reduces the amount of stuff you would need to learn in your new environment.
Demanding standard tools, fails to take into account that all teams, no matter how similar or close to each other, operate in different contexts. They solve different problems, they collaborate with different people, they consist of different people. These people have different preferences, experiences and modes of collaboration.
Where one team might love using Jira for tracking their tasks, because of their knowledge of that system, their need for highly customisable boards and workflows, another team might loathe all the overhead with setting up Jira, and would prefer to just use post-its on a physical whiteboard.
Where one team might have no problem using Confluence to document the things they need to document - because the data types and views in confluence are perfect for their uses - other teams might want to use a different tool, like a wiki on GitHub to keep their documentation close to their code, or Miro because what they need to document is a huge mess of different media types that are not easily transferred to a wiki solution.
But it is probably not a good idea to allow all teams to pick and choose from all available tools according to their wishes either. If every team uses a different tool for documentation, it becomes harder for people outside of a given team to find what they need. If everyone chooses to code in their own language, it becomes a lot harder to share solutions or people between teams. There is also a security risk. Individual teams will not necessarily know whether the data storage solution they chose is complying with regulations for example.
The natural conclusion, as in most other things in life, is that you need to find a balance between standardisation and flexibility. You need some standardisation, from a cost perspective, from a security perspective, and from a usability perspective - again, collaboration can be easier with standard tools. However, you also have to have some flexibility in the tools that can be chosen, to account for the different teams who are doing different jobs in different contexts.
Let us go back to the example of Miro. Whoever decided that we should stop using Miro, seems to have asked around about what it is used for, since we have some suggested replacements that technically can do the same thing as Miro did.
But those suggestions annoyed people, more than they were accepted as helpful. Why? Because again, if you have used Miro, and the other tools, you know that they do not really replace Miro. But why don’t they do that? They do offer mostly the same functionality.
When asked, it is hard to give specific examples of what Miro does better than the other four tools, except that you can do them all in the same place. Arguably, Visio is better for drawing diagrams, and Jira is better for task planning and tracking. Arguably, Confluence is better for documentation. These are tools made specifically for their purpose, not just a general tool that can incidentally do that. While MS Whiteboard is not, arguably, a better digital whiteboard, because it does not have feature parity with Miro - are the differences really that big?
It is easy to give small, insignificant examples. Here are some that came up in the discussions following a demo of MS Whiteboard:
- Miro feels better to use than all four of the other systems for a lot of people.
- Miro has more shapes that you can draw.
- Miro has more emojis you can put on post-its.
- Miro has more post-it colours.
- Miro has more fonts, and font-styles.
- In Miro, you can link two elements, and the link will remain even if you move the elements.
- You cannot have anonymous elements in Whiteboard.
- There is no Mac Desktop app for MS Whiteboard.
And so on and so on. Every single one of these reasons are very easy to argue against. How important is it to have 16 colours of post-its to choose from, rather than 12? Can’t you just move the link after you have moved the objects, or recreate it? What are you really gaining by being able to make text bold? Emojis? Come on!
But that is exactly the point of the flexibility that is needed. None of these are an insurmountable problem in the particular, but in the aggregate, they become a huge problem. The usability and usefulness of the replacement systems are, taken as a whole, much worse. While we are saving money on the license cost, we are also losing productivity and employee happiness, because the employees have to work with inferior tools. Is that worth it? That is a discussion one can have. But the main issue is that the people who are making the decision about what tools to buy, cannot rely on their own understanding of how the systems are used, or what they do.
It is precisely in the specific usage of different tools, you can understand what makes that tool better or worse than other tools, and that usage is entirely dependent on the context of the teams using the tool. Maybe my team really needs a green post-it that is not available in MS Whiteboard. Maybe we have an existing workflow for some workshop that required a loooot of different emojis, and recreating that workflow will take a lot of time. And the employee experience and productivity for those teams, should be an equally big part of the decision as cost savings and security. In all cases in acquisition of tools, but especially when replacing an already established tool. Asking for feedback about how the systems are used, without really taking the time to understand their usage, is useless. Because you can easily find examples of tools that do the same on the surface.
This could easily lead into a blog post on how it is very hard to quantify the user experience (UX). Usability, usefulness, desirability, findability, discoverability, credibility and value, are all important, and all hard to measure and understand. But since I have already written a novel, let’s save that for later.
Well, in this specific instance, in my opinion, yes. In a general discussion of “should we keep tool X when we have replacement Y?”, that is harder to answer. As I have spent a lot of text arguing, you have to find a balance between standardising and being flexible, and also to figure out if Y is actually a viable replacement for X, even if they look similar on the surface.
The main takeaway I want you to have after reading, is this: Employee experience and productivity should be equally important in these discussions as cost and security. And if you are making a decision about available tools on behalf of others, you need to spend time to understand the needs of the people you are deciding on behalf of, if you want to make a good decision.
In general, having two tools that do the same thing is not a problem. The two tools can probably fulfil each other, and even giving users the option between two tools, gives them a lot more flexibility to choose a tool that works for them, than just having one.
And as an actually final closing remark: In general, people are not choosing tools outside of the standard to be difficult. They choose them because they work better in their context. And if you deny people the ability to use the tools they need, they will either be unhappy, break the rules, or leave the company.
So, either sad, bad or a nomad.
None of those are good outcomes.