Every six months or so, the team at Thoughtworks publishes their Technology Radar report, a guide that outlines trends and technologies that are making an impact in software development and IT. Developed by a group of senior tech leaders at the company, it offers key observations and advice on what engineering leads and developers should pay attention to, test, or even incorporate within their stack.
In the most recent volume, the core themes center around the rise of AI (unsurprisingly), the growing impact and usage of accessible practices, the misuse of serverless functions, and the evolution of machine learning tooling ecosystems. When it comes to the recommended techniques and technologies for engineering teams, we found ourselves agreeing with a lot of what the Technology Radar report put forward. In this article, we’re sharing our perspective on three of the techniques they proposed teams adopt alongside some other insights the guide elicited.
Applying product management to internal platforms
At the top of the report’s list of techniques to adopt is the concept of leveraging product management capabilities within your internal platforms. In other words, teams should take the same principles they use to build and deploy a customer-facing product when they create internal platforms. This can’t just happen at the surface level (e.g. by changing team structures or using different naming conventions). Rather, it requires applying a product-centric mindset to the work being done.
In practice this could mean incorporating new roles into the platform team, such as a platform product manager, and incorporating new skill sets, including requirements gathering and success measurement. This way, the platform team can work more collaboratively with developers to understand what they need and create a platform that works for them. Plus, it ensures that platform teams are more in tune with product developers, making them better able to adopt the right tools and processes to help them thrive. The overarching benefit? Engineering teams can then roll out new digital solutions faster and more efficiently.
This approach is something we heard about recently from Andreas Westendörpf, CTO at Emma Sleep, when he joined us on the Level Up podcast. When he and his team went through a replatforming exercise at Emma—one that dismantled their monolith and set out to establish ideal functions for each business unit—they opted to look at their internal platforms as products. This meant that each platform had its own set of product engineers that were tasked to create the best possible tooling for other developers. This not only gave the platform team more purpose and accountability, it also improved the overarching developer experience within the rest of the organization.
Dependency pruning
Agility and efficiency have become important metrics for product developers—carrying almost as much weight as quality. It’s why engineering teams are increasingly relying on starter kits and templates that help speed up the initial setup of a software project. The problem with this approach is that if they’re not designed properly, these templates can bring in unnecessary dependencies that make the code more complex and cumbersome. In addition, dependencies can also introduce vulnerabilities that compromise the product’s security posture.
Given the increasing number of attacks on software at various stages of the development cycle, the Thoughtworks guide recommends that teams take a renewed interest in dependency pruning. This means doing periodical reviews of dependencies and removing any that aren’t necessary. While this is good advice, we would take it further and suggest that teams need to adopt best practices when it comes to building, using, and maintaining templates. A lens to use here is that these templates should help speed up development time without introducing additional risk.
This is the approach we’ve taken in creating our service template offering. OpsLevel empowers platform engineers and SREs to craft templated services with all of their standards baked in so developers can get started without opening the company up to unnecessary risk.
Establishing run cost as an architecture fitness function
More and more, today’s engineering leaders are expected to look at their organization not just from the perspective of technical performance, but also through a financial lens. They’re expected to have clear insights into what it costs to run their systems, and to use that insight when it comes to making decisions around what technology to leverage and what to let go. This explains why the Technology Radar report has had this cost-centric recommendation in the adopt list since 2019.
Currently, many engineering leaders are at an interesting crossroads. Cloud consumption is growing, but tech companies are reducing costs wherever possible to respond to limiting macroeconomic trends. Decisions that were once made purely at an engineering level now also have to consider costs. As such, these leaders need easy ways to measure the cost impact of each architectural and design decision.
At OpsLevel, this need for visibility has been one of the driving forces behind some of our latest developments. For example, our newest domains feature offers leaders the ability to understand the overall footprint of their domains, the health of their business area, and how performance metrics are trending. As we continue to develop these features, we’re helping engineering leaders to make informed decisions and have apples-to-apples conversations with other executives in their business.
Tracking health over debt
This one comes from the Assess ring in the Technology Radar report, meaning the Thoughtworks team thinks it’s worth exploring with the goal of understanding how it might impact your organization.
For decades, engineering teams have observed technical debt as an important metric for their organization. It can help identify problem areas, support decision making, and ultimately define whether a team is being as effective as it can be. That said, it’s not an easy metric to define, let alone measure. Plus, it keeps teams focused on the problem area, rather than the solution.
As an alternative, the Technology Radar report suggests focusing on technical health instead of debt, as it helps teams work towards a better end state for their tech stack. This way, teams can link their initiatives to a set of health goals and objectives, and measure their performance to determine priority areas.
This is something that really resonates with us at OpsLevel and speaks to how we think about service maturity and health. Rather than taking a one-and-done approach to service maturity, we see it as a continuous improvement philosophy that should be at the foundation of how engineering teams think about their services.
The state of software engineering is always in flux
The reality of operating in an industry that thrives on innovation is that things are always changing. Teams are always introducing new technologies, processes, and best practices, and keeping up with evolving trends is a full-time job in itself. That said, one thing that we always like to remember is that regardless of all the innovation and digital tooling, software engineering is still an inherently human function. It is work being done by humans to make life easier, better, or more efficient for other humans. Keeping this in mind, we’re excited to be a part of software engineering changing for the better—and we can’t wait to see where it goes next.
Interested in learning more about how we’re making life easier for engineering teams? Check out our latest release update for info on our newest features.