Most innovators don’t have a technical background, so it’s hard to evaluate the truth of the situation. We hear them explain that their current software development is expensive, deliveries are rarely on time, and random bugs appear. The explanation from software leadership is often unsatisfying or unclear. And unless they have a tech background, they can’t look under the hood themselves.

What does a business leader do in this situation? The reality is that it’s not a hard problem to address. The answer is to engage a trusted outside source for a Technical Review – a deep-dive assessment that provides a C-suite perspective. At TechEmpower, we’ve conducted more than 50 technical reviews for companies of all sizes, industries, and technical stacks.

Technical Review Defined

A technical review is a deep-dive assessment of your software, infrastructure, team and processes. It provides findings and recommendations intended to foster a mutual understanding between business and software leaders, shedding light on the current state of your technology and your team. It also provides concrete recommendations for improvements.

Common Signs You Need a Technical Review

We’ve already mentioned the most common signs that you might need a technical review:

• Slow or late delivery: “I’ve authorized two new developers, and we’re still behind.”
• Random or persistent bugs: “The menu bar has been fixed three times now!”
• Sleepless nights from strategic worries: “Am I building the right tech, the right way?”

But everyone’s situation is unique. Your reasons for needing a technical review will depend on your business goals. Think ahead to tomorrow, to the next six months, and to next year. Are you preparing to expand, take your business in a new direction, or take on new partners? Even if you’re happy with your tech team, a review can ensure your business is in a good place before you take your next big step.

Other common scenarios that we’ve seen:

• Scaling and new markets: Your company and product are established, and now you’re scaling or going after new markets. These are classic inflection points for a development  team. It’s important to ensure that they’re on a strong footing as significant changes occur. Otherwise, the downstream technical debt created can be overwhelming.
• Keeping up with the competition: You’re a market leader in a fast-growing field. Newer, nimbler competitors keep introducing new features before your team can catch up. A technical review can help your development team adopt new processes and strategies to maximize their speed and efficiency.
• Outgrowing your stack: Your tech stack was just right for your startup. But as you’ve grown, it’s become cumbersome and constraining. Your tech team is suggesting a costly, time-consuming overhaul. But is that the right strategy for your business? A technical review can answer that crucial question.
• Changes to the tech team: You need to make changes to your tech team to meet your business goals. But what does the right team look like? A technical review can help you decide what team will work best both with you and for you.
• Due diligence prep: You’re coming up on a funding round or looking at a potential exit. Your investors and buyers will be doing a technical review. Are you ready? Do your own review first so you can be confident and better positioned.

There are almost as many reasons to do a technical review as there are software-enabled businesses. If you’re a CEO, product leader, investor, or a founder looking for investors, a technical review conducted by a neutral, experienced third party will help you discover what’s really happening and what’s needed to make improvements.

How it Works – The Review that’s Right For You

We know what a review can do for you. But only you know what you really need. That’s why it’s important to discuss your specific situation early in the process, ideally before the review even begins. This allows us to shape our approach to your unique needs. Then, at the start of the review, we speak with other key stakeholders to understand where they’re at and what they need.

So, how your review might work depends a lot on your situation – there’s your standard tech person caveat! 🙂  But at a minimum, any good review should include:

• Straightforward Analysis: A straightforward report that grades aspects of your technology, processes, and team. It’s written for a business leader, not an engineer.
• Pragmatic Assessment: An in-depth evaluation by working engineers who understand what it takes to deliver in different development situations. This part of the report can go deep on how your software stacks up with respect to feature delivery, security, reliability, and scalability.
• Expert Recommendations: Concrete next steps that working engineers believe would be appropriate to consider.
• Findings Sessions: A review meeting to decode findings, gauge their business implications, and chalk out a roadmap for the future.

Let’s look at the process in more detail. Here’s what a typical review looks like, step by step.

Background Information Review

Our first step is to review existing background materials. Our goal is to build a decent understanding of your business, your product, and your technology.

This might include business-side materials like your product roadmap, business plans, and competitor analysis, as well as technical materials like requirements documentation, screen comps, and project/process systems like Jira and Confluence.

Discuss Pain Points

To borrow the famous quote, all successful software projects are alike; every struggling software project struggles in its own way. To help you, we need to understand your specific concerns.  What’s keeping you up at night? Understanding your pain points shows us where to focus our review. We keep these pain points at top of mind throughout the review.

Questions and Conversations

We provide the tech and product teams with a list of questions that cover a wide variety of topics including software architecture, hardware/software technologies in use/planned, hosting, external services and dependencies, deployment strategy, development process and tools, testing approach, data science, security, and other relevant topics.

We then review the answers with the technical and product teams.

An interesting side note: During our Q and As with dev teams, we often end up having conversations around issues that they haven’t even thought about. It’s not because they’re inexperienced or incapable – it’s because they’ve been so focussed on shipping features that there hasn’t been time for anything else. This is exactly the sort of thing that a technical review can help address.

Here are some questions that can trigger those kinds of conversations:

• What areas of the applications are the most difficult to work on? And what causes that?
• What amount of time is spent on bug fixes and maintenance versus development of new features?
• How would your product perform if your user base were to scale up by a factor of 10? By a factor of 100?
• How are you monitoring your systems and applications?  Who responds to alerts?

Architecture Review

We meet with your tech team to review the overall architecture of your systems and applications. Our goal is to get a big-picture understanding of your systems, including how complex they are. We also begin to assess how well the architecture fits with your business needs.

Targeted Code Review

In this step, our senior engineers review the source code that drives your business. Does the code follow best practices? Are there repeated bugs or security holes? Our goal is to make sure your team’s code is appropriate for the situation.

Why a targeted review? It’s not practical, or even worthwhile, to examine every line of code. We provide value by targeting our review towards key components across your application stack.

Process and Team Review

It’s easy for development teams, especially startup teams, to cut process corners in the name of shipping features. However, short-cuts on process can lead to problems downstream. It can also lead to a software team that looks ill-equipped.

To head these off, we start by reviewing your team’s overall methodologies, and then drill down to details like source control workflow, ticket management, and code review processes. This step helps us identify why development priorities get stuck or abandoned, determine if the right people are working on the right tasks, and identify development hurdles and roadblocks.

This step can include a review of each team member’s contributions, down to individual commits. If you’re concerned that some of your developers are not allocated wisely, a contribution review can help.

We also assess the makeup of your dev team. We check out the team’s makeup, skill sets, and past work to ensure they align with what your business needs.

Findings and recommendations

This is what you’ve been waiting for! We provide you with a report, written for a business audience, that includes:

• Executive Summary: We grade your architecture, source code, process, and teams, and provide a brief rationale for each grade.
• Detailed Findings: For each of the areas in the executive summary, we provide the details. Honestly, this often doesn’t get more than a skim from business leaders, but certainly gets a thorough read from the technical team.
• Recommendations: Specific recommendations based on your pain points, the findings and what we believe are pragmatic choices for your business.

Review Meeting

Once the business and technical teams have had a chance to review the findings report, we conduct a meeting, or series of meetings, to discuss the results and next steps.

Getting Buy-in from Leadership

Business leaders are often concerned about how their tech teams will react to an external technical review. Will they resent scrutiny from the outside? Will they refuse to cooperate or push back?

While this can be a challenging conversation, it’s not as hard to get technical leaders on-board as you might think. Let’s assume that you’ve already expressed your frustrations with technical leadership. In our experience, the tech teams generally welcome the review. They’re often frustrated by the same problems that trouble the business team – or different problems that the business team doesn’t even know about, but should. They are happy to share their concerns with us, and generally agree with our conclusions. After all, they want you to succeed too!

It’s important to get buy-in from product leadership as well, so we make sure they are also involved in the process. That said, we find that most of the time they are expressing the same concerns as business leaders and getting their buy-in is much easier.

All of that said, we highly recommend discussing your specific situation with us prior to getting too far into the conversation. It’s easier to secure buy-in if we know where everyone stands.

Why TechEmpower?

Choosing the right partner for a technical review is important. You need a team who’s well-versed in technology and capable of translating that know-how into pragmatic options. It’s also important that they have experience in technical evaluations and in building real-world systems. We can’t emphasize that last part enough! If you bring in a consultant who spends all their time doing technical reviews and hasn’t built a system since the dot-com boom, you’re probably wasting your time.

At TechEmpower, we’ve done over 50 technical reviews for budding startups, scaling enterprises, discerning investors, and ambitious companies seeking investment or acquisition.  Our professionals bring expertise, neutrality, and depth to the process, and we approach each review with a unique blend of technological prowess and leadership acumen.

Bottom line, if you’re a CEO or founder, ask yourself these questions: Am I getting my money’s worth from my development team?  Do I really know what’s going on under the hood?  If the answer isn’t an unqualified yes, then email us to discuss a technical review.