Tech Strategy?
Tech strategy describes how an organization should use technology to meet its objectives. This includes considerations of engineering, data, and product. Good tech strategy guides decisions and focuses effort in ways that support the organization’s business strategy. It is often simple, acknowledges trade-offs, and creates clarity. Great tech strategy is all of those things, plus they’re written down, well executed, and constantly scrutinized.
In our experience, great tech strategy is rare. We’ve seen most organizations make tech decisions guided by norms, opinions, and preferences instead of having a well-articulated and thoughtful strategy. This lack of strategic clarity often creates disparate approaches and a heavy coordination burden amongst software teams.
Investment Tenets?
There is no shortage of investment opportunities. However, developing and executing a winning investment strategy takes a lot of skill. Great investors develop a strategy first and then evaluate opportunities that align with their strategy. Over the years, certain shared aspects or tenets have been identified amongst winning strategies. The list of tenets we’re going to go through in this article have proven their value throughout the history of financial markets. Our goal is to analyze them and find potential tech strategy corollaries.
Helpful Tenets to Consider
Avoid Emotional Decision-Making
It’s valuable to perform a high-level cost/value analysis when evaluating potential investment opportunities, much like investors in the finance world do. They run analyses on the investments they’re considering, armed with an idea of what an ideal investment looks like from various standpoints: cash flow, payback period, cost, and more. They delve into fundamentals, macroeconomic trends, and other factors that could impact the expected performance of the investment opportunity. This level of analysis is a common practice in the financial investment world and for good reason.
Translating this to tech strategy, evaluating options with cost/value in mind is useful even though the underlying figures (cost and value) are estimates. Saying no to one idea means saying yes to another that might be a better fit. Doing this safeguards against personal preferences, overshadowing objective decision-making.
A word of caution here: we often overestimate the short-term value and underestimate the cost of large-scale refactoring investments or efforts to pay down large chunks of technical debt. Take, for instance, projects focused on porting an old app into a new one or rewriting an application. In our experience, it’s usually the case that enhancing the existing system (even if it’s “legacy”) might have been a quicker and more efficient route. There are exceptions, but they’re not as common.
When working with clients to improve their software teams’ technical capabilities, we run a cost/value analysis on all coaching techniques / subjects we could focus on. Whether running a workshop on Git or Test-Driven Development, introducing a new pattern, or adopting a new tool, we analyze them all using the same process. We use a simple scatter plot, with the x-axis representing the potential value and the y-axis representing the cost or difficulty. We aim for high-value, low-hanging fruit but consider high-value, high-effort activities if they justify the investment. This tool has been invaluable in prioritizing efforts alongside our clients to improve the efficiency of their teams. There’s never a shortage of opportunities, but selecting the most valuable one can make the difference in a project.
This analysis method should be an integral part of every tech strategy, providing teams with a clear path for decision-making. And as we delve into the other investment tenets in this article, this cost/value analysis process will help identify exceptions to any rules we outline. Articulating how these decisions are evaluated is a crucial aspect of an organization’s tech strategy, setting a solid foundation for the subsequent investment tenets we’ll explore.
Leverage Compounding Interest
Long-term minded investors are often looking for opportunities where the value they earn compounds over time. Compounding interest is when you reinvest your interest each period such that your principal grows over time, generating progressively larger interest payments.
Translating this financial principle to tech strategy, the quest is to identify investments that continue to provide value repeatedly, without necessitating additional effort to realize that future value. A prime illustration is the quality of code. Investing additional time in forging robust abstractions might extend the code-writing phase, yet the payoff is substantial. Each line of code, though written once, is typically revised multiple times, and read many times more. If the cost of reading/comprehending the code is lowered by increasing the quality of the code, the time savings gets earned each time the code gets read. High-quality software, therefore, epitomizes a compounding interest type of return, where the initial investment reaps benefits in easier maintainability down the line.
The same principle applies to investing in developer experience. By creating an environment where developers can thrive, learn, and become more efficient, the initial investment in good practices, tools, and training compounds over time, leading to faster development cycles, fewer errors, and products that stand the test of time.
The crux of leveraging compounding interest in tech strategy is to sidestep the allure of big-bang gains, and instead, embrace incremental victories that keep on giving. By making strategic investments that compound in value over time, tech leaders can steer their teams and products towards sustained success, mirroring the prudent patience and foresight exhibited by seasoned investors in the financial domain.
Don’t Try “Timing” the Market
A common adage in the investment realm states, “time in the market beats timing the market.” This principle cautions against the lure of short-term market swings or trending fads, advocating instead for a long-term, steady approach. The concept emphasizes that investors are likely to see favorable returns by staying invested over a longer horizon and focusing on long-term strategies.
Transposing this tenet to tech strategy, the advice morphs to: avoid chasing the latest tech trends or hot new frameworks merely for the allure of being on the cutting edge. It’s not a decree to avoid exploring AI, blockchain, or any emerging tech. However, it stresses the importance of ensuring a tangible value awaits on the other side of such explorations. It’s a common pitfall for enterprise organizations to go all in on a trending tech, only to discover later that the current implementations are not yet battle-tested. A related and common tech strategy is, “have the courage to use boring tools.”
This doesn’t just ring true from a technological standpoint, but extends to product strategy as well. In this context, “time in the market” translates to an enduring commitment to understanding customer problems. It’s about consistently pushing to grasp these problems more profoundly than any other competitor and building a rich expertise over time. This long-term engagement ensures that the technology you develop aligns with real-world problems that customers are willing to pay for.
So, rather than being swayed by every new tech wave, the focus should be continually striving to unveil customer issues and address them with reliable, proven solutions. By doing so, you build technology that stands the test of time and cultivate a deep-rooted understanding and expertise in your domain, which in the long run is a strategy that pays off well beyond any fleeting tech trend.
Invest In What You Know
Investing in financial markets often resembles a zero-sum game, where winners celebrate at the expense of the losers. It’s a competitive arena where embarking on ventures without adequate knowledge can set one up for failure.
When transposed to the realm of tech strategy, this tenet underscores the significance of leveraging the collective expertise within your organization. It isn’t about the personal knowledge of a single individual, but about harnessing the collective intelligence and capabilities of the team.
A tale from a client engagement illuminates this principle. The large enterprise client harbored a 50-person developer team treated like an internal startup. This team, enjoying a high degree of autonomy, embarked on a cloud-based microservices approach, adopting a myriad of languages and frameworks—a strategy whimsically dubbed the “taste the rainbow” strategy.
As the user base burgeoned, the task shifted from creating greenfield applications to maintaining the existing complex system, laden with bugs and code in unfamiliar languages. This shift diluted the fun and saw the team dwindle from 50 to merely six developers over a few months. The lack of constraints led to a system which manifested in insidious issues that were hard to untangle. We were added to the team in an effort to stabilize the system, but it was no easy feat. Throughout the process we had to throw out entire services and drastically simplify the system. It was a process fraught with risk, but there were no good options given the constraints.
The crux of the problem was an oversight in aligning personal expertise with organizational knowledge. The leadership failed to take stock of the collective technical expertise, leading to a sprawl of tools and technologies that eventually became a maintenance nightmare.
The lesson is clear: while exploring new territories is exciting, grounding your tech strategy in the realm of your organization’s collective expertise can spell the difference between a sustainable tech ecosystem and a chaotic, hard-to-maintain construct.
Rebalance Your Portfolio To Match Your Appetite For Risk
In the investment sphere, the essence of diversification and active portfolio rebalancing alters with the size of the investment. Large investors, with substantial sums at stake, often adopt a more conservative stance, aiming not just for returns but significantly, to avert any substantial loss. On the other hand, their smaller counterparts may harbor a higher risk appetite, given the lesser magnitude of loss and a zealous drive for value capture. The latter may find themselves gravitating towards riskier ventures, while their larger counterparts spread their bets across a range of investments, continuously monitoring and rebalancing to ensure their risk profile remains within acceptable bounds.
Drawing a parallel to the tech domain, startups, much like small-scale investors, often thrive on focused endeavors that have high risk / high reward profiles. Their journey is typically about championing a singular vision or solving a specific problem, which doesn’t leave much room for diversification. Contrarily, larger enterprises, akin to large-scale investors, have the luxury and the imperative to spread their endeavors across multiple fronts. This dispersion not only hedges against potential failures but also paves the way for uncovering diverse avenues of success.
A while back, I collaborated with a large enterprise with an eCommerce arm. The architects there were enamored with Micro Frontends and had a clear vision for its implementation, which entailed crafting a plethora of in-house tools. Our team was brought in to co-develop this platform and upskill their teams in the process. As we delved deeper, it dawned on us that the juice wasn’t worth the squeeze. Despite our meticulous evaluation of challenges and a plethora of alternative solutions, the architects were steadfast in their approach. They had staked their internal reputations on this approach being followed to a tee. Eventually, they replaced our team with the industry frontrunners in Micro Frontends. Post a hefty investment of time and money over six more months, the enterprise retraced their steps to the path we had suggested.
This narrative is a stark reminder of the perils of placing all eggs in one basket, especially for large enterprises with a broader operational scope. The lesson here is to diversify – spread the bets, experiment across multiple fronts, and ceaselessly monitor and adjust the course as you learn more information.
However, diversification doesn’t imply a scattergun approach. It’s about calculated dispersal of resources, continually monitored and realigned to ensure that the risk profile remains balanced, and the tech endeavors resonate with the organizational objectives.
In essence, the financial wisdom of diversifying and active monitoring transcends the money markets and embeds itself within the tech strategy realm, urging organizations to spread their bets wisely, monitor the play, and be ready to recalibrate as the game unfolds.
Example: Initech
Fictional Scenario
You’re the new CTO of a financial services company, Initech, that manages a system that finds and tracks the resolution of compliance issues in accounting systems.
Any software directly operating on sensitive client information is baked into a Java monolith that runs on-prem. There have been availability issues, but it’s secure and the data back-up strategy is solid.
There are a myriad of cloud-based microservices that operate on less sensitive meta-data and provide key functionality for your clients. Most of the services are written in TypeScript/Node.js, with some of them being written in Rust, GoLang, and Elixir. All front-ends are written in TypeScript/React. These systems have become unreliable and complicated. The team has been slow to deliver new features in a timely manner because of the tech debt in this microservices tier.
Potential Strategy
Following the advice outlined in the tenets, a tech strategy could look like the example below. Pay no attention to the format or structure we’re using in the example. Remember, tech strategy is meant to guide decisions and focus effort in ways that support the organization’s business strategy. So as long as that’s accomplished, there are no formatting rules or structures that separate good strategy from bad.
Customers chose Initech because they know their data is safe and they know we’ll efficiently and effectively find their compliance issues. At Initech, we use technology to:
- Securely store sensitive financial information
- Automatically find compliance issues
- Track the resolution of compliance issues
- Customize reporting
We build fit for purpose custom software systems when they’re either: (1) handling sensitive customer data or (2) codifying our company’s secret sauce. Required software outside of those areas should be bought off the shelf.
The software system we maintain to handle sensitive customer data is designed to first and foremost be secure. As such it will be a monolith, it will run on-prem, have a robust back-up strategy, have access restricted to a smaller pool of team members, and will serve tokenized data via internally accessible APIs. We accept that this will create limitations that we need to manage system load and pace of change actively.
The software system we maintain to find compliance issues is designed to first and foremost be easy to change. Compliance is a world where the rules are always changing, so we need our software system to be able to keep up. As such we will follow the service oriented architecture and each service will have a reliable CI/CD pipeline, be deployed to the cloud, have open access settings to the whole team, and will leverage Typescript/JS for the front-end and back-end to encourage full-stack development. We accept that this may increase the likelihood of introducing bugs. We expect they will be detected and fixed quickly, minimizing any customer impact.
The software system we maintain to integrate off the shelf vendor tools is designed to first and foremost be easy to change. Our needs and vendor relationships are expected to change over time, so we need our software system to be able to keep up. As such we will follow a similar strategy as the one our compliance system follows.
For all of the custom software systems we maintain, we strive to pragmatically and incrementally improve in the following areas: (1) code readability, (2) code flexibility, (3) quality of test automation, and (4) level of observability.
Any exceptions to the aforementioned strategy (and we fully expect there to be exceptions) will be granted or denied by the architecture review board. Be prepared to present the estimated cost (time and money), the expected return on investment (time and money), and the time horizon in which we expect to start getting a return.
Tying It All Together
The example tech strategy aligns itself with the needs of the business and applies lessons from the financial tenets we covered. There is a clear process that evaluates the cost/value of new opportunities. There is an emphasis in areas that provide compounding value throughout time. All tech investments have been aligned to the continued growth of customer value. The suite of tech has been focused on areas aligned with organizational knowledge. The risk of failure is managed appropriately.
Furthermore, it provides the clarity teams need to start making progress towards a more coherent vision. Armed with this clarity, a leader can get a plan in place to better align their system to the strategy. They can do things like:
- Reduce the number / complexity of microservices and port them to a unified stack
- Bring in co-dev coaches to reinforce code quality and improve the dev experience
- Replace select in-house systems with off the shelf products
- Restructure the teams to be stream-aligned
- Etc
Taking inspiration from these helpful tenets, tech leaders can craft a tech strategy that sets their organization up for lasting success.