Evaluating software products and the teams that build them

Download PDF

Software is complex. There really aren’t many parallels in our modern world. Understanding a product top to bottom requires a skillset that is far broader than almost anything else we typically see in modern business. Software has all the immediacy of a manufactured product sitting in your customers home, with the unpredictability of a pure R&D effort, and the expectations of an in-person service. Even software built to never be exposed directly to customers is often connected directly or indirectly to the consumer experience. Add to this the inescapable reality of a 24/7/365 real-time interactive experience powered by technology outside your control and it’s easy to see just how difficult the environment can be.

When we think about how to evaluate a software product, it’s perhaps too easy to focus on what the customer sees and interacts with, but in the case of most software products that represents only a small part of a much more complex system that stretches all the way back to a team of people who build and maintain this system. That product is inextricably connected to the entirety of the system and its trajectory moving forward cannot be easily abstracted from the larger whole. Any evaluation of a software product and its future needs to consider the reality of modern software development. While it is getting easier and easier to start building something new, it is getting more and more difficult and complex to keep that same thing up to date, secure, and getting those critical next features in the hands of customers.

At the scale of modern software, almost every company has a software component. Even a simple system exposed to customers on a website might connect to dozens of other software components and almost certainly requires regular security fixes. Technology has the power to enable new businesses quicker than ever before, but the amount of complexity hidden beneath the surface is also unrivaled. At this point, to some extent every company is a technology company, at least in its responsibility to customers. Those customers have transitioned more and more to digital experiences, most of the success in the new software driven world will go to companies who have a deep capability in using technology to make their products unique and better.

Many aspects of a business can be defined by well understood, and transferable metrics. Standards for financial accounting and valuations allow evaluations to be at least conducted in a common and familiar language. In most cases a software product is more complex, and as if someone had created an entirely new and unique language to define it.

Before you make plans for what’s next with a business, you need to know enough about the software and how it works to answer a key question, will this product be able to support the future needs that will be placed on it. The technology and source code are important, but that tells you what it is right now, equally if not more important is what capability does the company have to change, advance, and innovate with this product, and for that you need to get beyond the code, and into all people, process, tools, and technology that makes up the larger system.

The ability to grow, improve, and change a technology product is governed by hard to observe elements. These elements are difficult to observe because they are only observable in the people and processes of the team building the software rather than the software itself.

Existing source code is not an asset, it’s a liability. Modern software needs near constant maintenance to stay viable. Much of that maintenance can happen in the process of advancing the software, but the second you stop working on something full time it freezes in place while the world keeps moving forward. This is why the first step to looking at the long-term viability of a software product is to look at the team’s ability, plans, and execution as they are working on the product. A team that has no plans for moving their product forward, is probably losing ground. Every software product has problems, it’s normal. Does the team understand the problem areas that exist in their product and have plans to fix, improve, replace them?

The fastest software development is often when you are just starting. Velocity slows the bigger your product becomes. Successful teams recognize this and build with it in mind. It’s possible to design your software to keep the components small enough that a single engineer can have a big impact quickly. Processes that keep the team flexible and responsive to change. When people talk about the future are they planning on moving their existing technology with them, or is everything lumped into a mysterious version 2?

Doing software development quickly is risky. More so once you have customers using your application. A good team de-risks speed with infrastructure and tooling that automates their path from keyboard to cloud. That tooling should enforce best practices, standards and quality in a way that makes going fast safe. How long does it take to move a bug fix into production? How many people need to be involved? What about a simple change to move a button? Does most of the team have a deep knowledge of how the product works, or are there a small number of people who need to be involved in everything? What happens when something goes wrong?

Engineers make a thousand little decisions a day. The more context they have about where the business is going the more of those decisions will be aligned with future goals. There should be a clear through line from customer to business to product development. Does the team understand the “why” behind the work they are doing, can they keep up with critical customer needs?

Hiring a talented engineer has never been harder and replacing one that leaves adds the loss of specialized knowledge about your existing system. Is the software team happy, motivated, and able to do their best work? Who are the key people? Are they signed up for the next several years or are the loose in the pocket, just waiting for someone to lure they away? Many engineers with multiple years of experience get constantly barraged with job openings, the culture of their existing team has a huge impact on their willingness to entertain them. An unhappy team will be hard pressed to hire and grow or replace the people who have left.

At the company level, a software organization can be seen as an afterthought or as a strategic asset. Companies who integrate it as a core competency of the business are aligned for success in the long run, because the need for technology enabled products will only grow as we live more and more of our lives online. People who understand how to apply technology to business challenges integrated throughout the company, will create more opportunities for the organization to take leadership positions in new markets.

Future Core is here to help you assess, understand and advance technology products and the teams that build them. Not every company needs to be a technology company, but everyone needs to have a core competency in applying modern technology confidently to solve their customers problems. Don’t get another expensive report on how a mythical software organization could be better. Start building better software today with the team you have with transformational guidance from experienced leadership that will meet you where you are.