3 questions for making better software decisions

I’ve worn many hats in my career: help desk worker, systems administrator, engineer, consultant, etc. I’ve made some great software decisions, but I’ve also seen things thoroughly flop. While working at WPEngine as a Solutions Architect I spent a lot of time talking with engineers and business folks about what headless WordPress was and whether it was the right solution for their team.

Ultimately I wasn’t the one making the decision, but I saw folks choose headless for good reasons and bad. During my time there I developed a mental model for how I would go about this kind of decision within an organization and used that to help give the best recommendations and advice to our customers.

Today I’m going to share that model with you. As an engineer, this will mostly be written to engineers, but whoever you are, I hope it helps.

Who are your stakeholders?

As an engineer, I’m very guilty of only thinking of the tools and software I use from the perspective of those who build. That is, my own. I may decide I don’t like a tool because of the DX (Developer Experience) or because it is not the latest cool stack I want to use. This perspective is not unimportant, but it is very limited. We have to figure out who is actually affected by this technology. This will change drastically with the size and nature of your org, but here are some ideas:

• Software developers (customizing the tool)
• Sys. Admins/DevOps (serving/hosting/deploying the tool)
• Creators (creating content, managing a database, etc)
• Consumers (reading, browsing, API users, etc)

But this list is limited to folks who actively interact with a given tool. It ignores another very important set of people. Decision makers.

• Managers
• Executives
• Finance

While these folks may or may not also exist in an earlier category, they also control budgets and make decisions. They must be on board from a financial and operational standpoint that this software will provide real value to the company. If they are not, the greatest DX in the world won’t make this project a success.

You may be able to write a list of these teams and people (be specific, write down names), or this might require some research with higher-ups to create this list. Spend the time, do the work, and start building relationships with these people. They will be important later.

What does your org need?

As an engineer, my goal is usually to create the greatest piece of software that the world has ever seen. I usually fail, and even if I do succeed, it does not mean the rest of my organization wants my software. I once wrote a PowerShell script that ran on every user login on a college campus that could modify the database behind a piece of software. This software managed printing and related costs for all of our users, staff, faculty, students, guests, etc.

I was helping set up the new system and received from my boss how each various type of student got print credits. Some received a lump sum in their first semester. Others a small amount each semester. Others were not in the traditional semester system. While the software had ways to give credits to new accounts, it could not handle the complex web of credits we had woven over the years of new programs. As a young engineer, I wrote a script that did in fact solve this problem.

In hindsight, I solved the wrong problem. The actual problem was the web we had woven. I should have worked with my boss (the IT Director) to recommend a credit solution within the bounds of the software and get this approved by the program heads across the university. This would have simplified so much chaos. Sometimes our job is not engineering solutions to perceived problems, it is eliminating the problem categorically.

To do this well, we can use the Needs Stack. If you’re unfamiliar with this concept, Jason Cohen (Founder of WPEngine) wrote a great article on the topic. For our uses here, a good question is how does your org make money? (or maybe “accomplish its goal” if you’re a not-for-profit org). If you are trying to sell widgets, then your E-commerce site is in service of that. Your business does not care about how that site is built, where it’s hosted, or any other techno-wiz-bang lingo.

Work with your stakeholders to define what their teams do with the software and how they need it to work. Put names to those requirements and make them defend them if needed. There will be compromises, make sure you compromise for things that matter. Getting to the actual need can be the hardest part of this process. Spend time here and do not be afraid to iterate.

How is this going down?

Whether implementing new software or replacing old, change is inevitable. New processes, changed interfaces, and even lost features all affect the organization. In working with all your stakeholders and defining needs you probably found some you just could not fulfill, or maybe you could not fulfill them in the way those teams wanted.

This is to be expected. The worst thing we can do is yolo the changes and tell teams to RTFM. As engineers, we tend to be curious folks who value learning. Our non-engineer colleagues might not share our love for fiddling with a UI. We must create learning opportunities for our teams to understand the changes and the value those changes bring to the org in order to get everyone on board. Teach them how their jobs will change and how to continue being productive with the new system. This is not necessarily the engineer’s job, but whoever is leading this project should be making sure this is happening.

Communicate. Over Communicate. Communicate a little more.

Conclusion

I have seen engineers drive software decisions at the expense of content creators. I have seen content creators drive decisions at the expense of the business. We are all guilty of seeing things from our own perspectives. The best thing we can do is talk with our co-workers, understand what they value, and figure out a way to move forward together.

This is hardest when you have to tell people no. When you are asked to do what your engineering instincts suggest even though it is the wrong move. Resist, step back, help your team/client to look at the bigger picture, and make good decisions.