Context is King

In the technology space, there is a lot of emphasis on the importance of adopting best practices or implementing proven strategies. But such approaches, when applied without adapting them to the specific context or situation, often fail to yield the intended results. Blind adherence to something that worked for someone else somewhere else, without a critical review, will most likely lead to disappointment.

Working in a variety of technology roles across organizations of varying sizes and operating in different industries, I’ve witnessed firsthand how decisions or approaches that proved effective in one setting have fallen short — or worse, failed miserably — in another.

For senior technology leaders to make the most effective decisions regarding technology, people, and processes, they must develop a deep understanding of the context in which both the technology function and the larger enterprise are operating. This context should encompass not only the internal workings of the organizations but also the ecosystem in which it operates, its market position, and other relevant external factors.

Why Context Matters

I’ve found in-depth analysis of environment and circumstances to be helpful in almost every major decision a technology leader can make. Following are a few examples illustrating the crucial role context plays in enabling a technology leader to make better decisions in key areas:      

Architecture choices: In recent times, the popularity of microservices has skyrocketed as a method for building loosely coupled, easily maintained, and deployable services in a distributed system. Does this mean every technology leader should jump on the microservices bandwagon? Not necessarily. If the company has a small number of developers or is in the early stages of finding a product-market fit, the complexity of building, deploying, and running microservices would be a bad choice. But for a company with a large, globally distributed development team, a microservices-based approach could increase speed to market by minimizing dependencies between teams and their code bases. I like the practical advice offered by software architect and author Chris Richardson on when to use microservices versus a monolithic architecture.

Migrating workloads to the cloud may also seem like a no-brainer on the surface; everyone has been doing it. But the company context is critical here as well. In my current organization, we had been running workloads on aging hardware in 15-year-old data centers with knowledge limited to a small number of people who had become single points of success or failure. Additionally, the reliability of the technology systems was less than our goal. So, migrating to AWS cloud using standard technologies for running, deploying, and building software has served us well. But I am aware of multiple well-documented cases where companies have shifted their workloads from the cloud back to on-premises data centers, based on cost and other specific factors relevant to those organizations. 

Technology strategy: The choice between developing in-house software and leveraging market services — build vs. buy — should always align with the specific organization's priorities and capabilities. I have worked in a division of a large technology company where our approach was to be the first customers of the technology that another division built, which made sense based on our overall company strategy. That would be a mistake at my current company, Shapeways, where we focus our technology teams on developing mission critical services for our customers and using proven services in the marketplace for everything else.

Cultural transformation: Culture cannot be copied and pasted! Learning from others is beneficial, but it must be grounded in what is authentic to your organization. I once saw the new head of a business group write a culture guide for employees which turned out to be heavily influenced by the culture guide of a market-leading company. Without much consideration for the organization’s history or people, the approach did not drive any significant change. Learning from that experience, when I had an opportunity to lead the creation of a culture guide for an engineering group, I made a point to build upon what was great about the culture, using that as a base from which to drive incremental changes. 

Organizational design: How senior technology leaders design their organizational structures should depend on a number of factors: how the business teams are organized, the size of the technology teams, the mission for each of the teams, their relationships and interdependencies, and the capabilities of team leaders. The result won’t always look like a cookie-cutter org chart. In one of my senior roles, in fact, I had multiple individual contributors reporting to me directly due to a transition that was taking place as well as the nature of the work being done. In another organization where I had a similar level role in the organization, there were multiple levels of hierarchy between me and any individual contributors. 

Agile processes: While technology organizations of all shapes and sizes have adopted Agile processes, misalignment with business or IT realities can limit its impact. Agile is not a one-size-fits-all methodology; its success depends significantly on how well it is adapted to the specific context of a company. 

I had an enriching experience with Agile, implementing it within small, co-located teams. We adapted elements from Extreme Programming (XP) into a customized version we called “fleXP”, specifically designed to suit our unique environment at that time. In another organizational setting, we emphasized the transparency benefits of Agile by encouraging teams to openly share their experiences and satisfaction levels as part of the retrospective process. This approach allowed leadership to identify and address issues that were most impactful to team members. 

Prioritization of work: As a senior technology leader, do you prioritize addressing tech debt or introducing new features that address customer pain points? Do you focus on work that will generate future growth or current revenue? In making decisions like these, the context of the company and the business is crucial. In one organization where we were building a platform to replace a number of legacy systems, we often prioritized addressing technology debt in order to get the foundational capabilities of the platform ready. In another organization with tremendous business focus on growing revenue, we prioritized features that had the most potential to drive revenue growth. Generally speaking, I personally strive to make progress in priorities across buckets of existing customer and sales needs, expanding business in new areas and addressing technology debt, recognizing that there will be times when one area gets more attention than the others. 

Technical acumen in leadership: How technologically hands-on a senior leader needs to be will vary based upon team size, skills, and company needs. A larger team might require more strategic focus from the senior tech executive, while a smaller team may benefit from a more hands-on approach. I have held senior technology roles where my primary focus was on aligning technology, people, and processes with the business strategy. I have also held leadership positions where I wrote and deployed code or jumped on calls to help resolve outages as the team members found it helpful. Feedback from technology peers and mentors have helped me dial my involvement up and down based on the context. No matter the environment, though, technology leaders have to stay plugged into the ever-evolving landscape of technology in order to lead effectively, especially with the breakneck pace of AI development. 

The Joy of Creating Impact 

For technology leaders, there are few textbook answers, shortcuts, or out-of-the-box solutions that work perfectly across all situations. Context always matters in making decisions critical to running a technology organization. It's essential that we not only stay attuned to the evolving technological landscape but also continually evaluate how to align our key decisions with organization's unique context and business objectives. 

But that’s part of the fun, isn’t it? As technology leaders, we get to use technology to create real impact for our customers, businesses, teams, and other stakeholders.