In school, I majored in Information Systems. I also taught Management Information Systems at my alma mater for a little while. One of the main concepts of this discipline is the process of choosing the best systems and processes to solve business problems, whether it’s pre-built or you need to hire a team of programmers to develop and maintain something. The process for that is as follows:

1. Identify and analyze the problem that needs to be fixed. (Don’t try to solve problems that don’t exist.)
2. Design a solution to the problem.
3. Evaluate all possible options and choose one.
4. Implement the chosen option.
5. Collect feedback from users. Re-evaluate how much of the problem has been fixed, if any. Return to step 1.

Now, I have to admit that this process comes straight out of a business textbook, but I can’t say that it’s wrong. (Although I modified it slightly.) Solving problems and finding solutions is not a one-time event, and it involves many different people and lots of research and introspection. Finding the right processes and systems is more like owning a house in that it’s a continuous, involved process by which the organization should be constantly improving. Additionally, performing cost-benefit analyses as part of more than one of these steps is crucial in figuring out whether or not a process or system will be worth the time/money investment. If the current process or system is working well enough and the organization decides at one or more of these steps that a new solution isn’t worth the risk, don’t fall for the sunk cost fallacy. Cut your losses and move on.

I’m a firm believer that change can be great for teams and the organization. The past should be left in the past, but we should always learn from our mistakes. This is where re-assessment comes in. Make small changes and iterate over the processes that you already have. If something isn’t working, change it. Perhaps most importantly, teams should keep their minds open about these changes.

This goes for the tools and systems we use too. Every team’s definition of what makes a system successful is going to be different, but some general questions that you might want to answer include:

• Has the system been fully tested and signed off by the required stakeholders?
• What is our plan for transitioning to the new system?
• Does this system make our work/lives easier?
• Is this system easily maintainable/cost effective?
• What are the risks if this system is unavailable?
• What does support for this system look like? Are there enough people dedicated to it?

As tech workers, there are so many tools in our toolboxes. If you’re trying to get a screw into a wall, you can’t keep trying to get it there with a hammer; you’re going to ruin the wall. The better tools are either an anchor and a screwdriver or a power drill and a stud finder. The best systems serve as few purposes as possible and focus on being great at solving the problems they aim to solve.

I’m not endorsing microservices, but I am saying: Use content management systems to manage content and customer relationship management systems to manage customer relationships. Don’t try to shove those two (unrelated) things into one huge monolith. If a system is fantastic at solving a major business problem, then it’s the right system for the job. If something better comes out and looks like it could solve the problem even more efficiently, go ahead and try it out.