Jeremy clicked on yet another software tool notification and sighed. As lead developer at SuperCorp, keeping track of project workflows was becoming a nightmare. The company had doubled in size over the past year, and so had its hodgepodge of specialized software. The sales team used CRMs, support used helpdesk apps, designers collaborated in Figma, and engineers coded in GitHub. Each team swore by their preferred tools, but little did they know this would create chaos.
Information got lost between siloed systems. Management had poor visibility into who was doing what. Onboarding new hires took weeks just to understand the tangled mess. With so many disjointed apps, even simple tasks like bug tracking became complex games of telephone. How could a rapidly growing company prevent success from being its own undoing? How can we tame software sprawl before it derails us?
The Problem of Siloed Software
We are a small software development company. I imagine that our processes aren’t very different from most companies in the industry. Each department in a company like ours uses its own piece of software:
- Developers use version control software, VCS
- QA team uses test management software, TMS
- Project management team uses a project management software, PMS
- Analysts use a document management software, DMS
- Designers use collaborative design software
- Support team uses a helpdesk system
- Product team users a product management software
Also, different types of software are used across the teams:
- Team messaging app
- File storage
- Time tracking
- Calendar and meeting software
There are many problems that arise from using that many systems, and one of the biggest ones is data silos. With each team using their own tool, there’s no way to share the data between them, even though the typical workflow is very interconnected.
Product team makes decisions on what needs to be done based on customer data, that is connected to helpdesk. The features that product team prioritizes are exactly what the analysts, designers, developers, QA engineers and will be working on.
If the systems are not interconnected, there’s a lot of manual work and duplication in how the team operates. I’m using the software development process to illustrate the problem, but it’s the same for every company — there are tools tailored for specific use-cases and it’s perfectly normal. Let’s look at what are the options to deal with this problem.
One System to Rule Them All
There’s a number of systems that allow you to model any type of work, Notion is probably the one that is the most wide-spread.You can model any process with it, but as any universal tool, it’s main disadvantage is the consequence of its flexibility. It’s true with any other similar tool.
First of all, someone has to set things up. Notion does not provide any predefined structure, and any decent process needs to be modeled by someone who is a Notion expert. If you don’t have a Notion expert on your team, someone will have to become one, which means that this person will need to spend time learning the tool and then dedicate time maintaining and improving what’s been created.
I’d also say that it’s very risky to have just one person on the team being responsible for the whole process, the safer way is to have a few people doing this, or hire an external agency to set things up and maintain. Both of these things may or may not be a good option for your company.
Usually, trying to use one universal tool will become a problem after some time. Things quickly become complex, it becomes hard to navigate the system and find the right place for the right task, entering data becomes cumbersome because there’s a lot of fields that need to be filled in and no want to remember why it’s needed. Yet, it’s a good place to start.
Often times, this option is considered the cheapest — you generally will pay less than $10K per year if you go with that option. With a team of 40 people you will pay only $7,200 per year as of now, given that you pick Notion’s business plan which gives you decent access control, and pay for a year. Other systems have relatively the same pricing.
But, it’s the cost of just the software itself. It you also count in the cost of time that people on your team will spend discussing how things should be done and actually implement the new processes, the cost will be much higher. If you also count in the cost of missed opportunity (e.g. a CEO focusing on this instead of focusing on growing business), the cost will be even higher.
The analogy would be the situation where you have multiple offices and you want to put everyone into the same building. Using a universal off-the-shelf product would be similar to moving from renting several furnished offices in different parts of the city for each department, to renting a patch of land and hiring a contractor to build an office from prefab pieces for you — you don’t have to deal with the intricacies of the construction, but you have to organize and plan everything, furnish the office, organize access control, clean the territory etc. You can have your custom office and bring everyone together, but it will be an effort and you will be limited to what prefab pieces are available
In my personal opinion, it’s a great option if you are just starting out, have a rather small team. It will also help if you already have people with a technical mindset and systems and process oriented way of thinking on the team, otherwise external help might be needed.
That’s the approach we are using for our compan. We use a different tool, Fibery.io, because it has a slighly different concept from Notion. While Notion is document-based, in Fibery you can create custom apps and design them however you want, add all the fields you want etc. It’s mostly the difference in UI and data model that makes it work better, but overall it’s the same approach — a single flexible system that can be tailored for each specific use case.
The Hybrid approach
This changes though as the company evolves. For example, as the QA team grows, it becomes hard to train every engineer to use all the custom fields we have in Fibery, the amount of manual work to track the test runs becomes unmanageable, and it starts to make sense to use a dedicated TMS system. Same process happens with product management — using Fibery becomes unproductive, so we’ll likely start using a dedicated PMS soon.
Yet, it makes a lot of sense to integrate those dedicated systems back into one place, for multiple reasons. For us, the main reason is to be able to track who does what in a single place, to have a single place of communication and decision making, to collect information on the time spent on specific tasks in a unified format and again, in a single place, and to have trackable history of work across departments.
So, we’ll be switching to a hybrid approach between using a single universal system for all teams, and using dedicated systems tailored for specific tasks. We’ll integrate the main system with external ones and sync them with each other. In case of QA, every time there’s a new feature that gets implemented by developers and needs test cases created, it will be synced over to a TMS accordingly. Creating bugs will work the other way around — if a test run had some failed steps, a bug will be created in the main system mirrioring the one created in TMS, and its status will be synced between the two.
Challenges of intergration
Integration of these systems is a challenge of it’s own. We simplified the task for ourselves, because we just integrate every external system with one central system. So each intergration is essentially one-to-one sync. But that’s not the only way to do it, and often times companies make the problem even harder by trying to integrate up to ten systems between each other, which is exponentially harder.
It often starts with reading an article on integration with a no-code tool like Zapier. With Zapier you can intergrate virtually any systems with each other if they have public APIs. Yet, it’s a task that has to be carefully planned, and for some reason it’s what those articles on no-code don’t tell you.
As Fred Brooks wrote in his classic book on software engineering and project management, “The Mythical Man-Month”, there’s a big difference between a program that works just for the programmer, a product that works for any user, and a system of products that work together.
Integration of multiple systems together is essentially a software development project, with all the caveats and problems, and has to be approached accordingly. It doesn’t matter that you don’t need to write code — the no-code tools abstract away a lot for you. But as much as it simplifies the task for simple cases, it makes the task even more complex for complex cases.
We used Zapier and Make for integrating the systems together, but ended up switching to writing code for this. Otherwise there’s no way for example to write unit tests to make sure the integrations are working reliably for different situations. Also, version control and applying changes became a problem — when you have a hundred no-code automation scenarios and need to update them, going and clicking a few things in each one of them is just too much.
As companies scale, software needs evolve. What works early on often hinders growth later. Rigid unified systems turn inefficient. Disconnected tools breed misalignment. There is no one solution — different paths suit different teams.
Carefully weigh the trade-offs and remain adaptable. Integrate thoughtfully, value end-user experience, and recalibrate when needed. With patient strategy, you can harmonize cross-functional workflows as you grow. But software overload will constrain potential if left unchecked.
The journey to the perfect workflow is long, but each step compounds. Whether you unify tools or connect a best-of-breed stack, build a strong foundation. Empower your people through software that fits like a glove, not a straightjacket. The companies that will thrive long-term are those that grow their tools alongside their teams.
Originally published on Medium.com
