Building Technical Capabilities

Should we adopt Kubernetes? Try using Acceptance Test-Driven Development? Immutable Infrastructure? There are many patterns, practices, and technologies you can apply inside of your organization. So many possibilities, in fact, they can be overwhelming. And you see organizations adopt tools without really understanding the "why" behind the tool – the capability needed for business success.

Instead of focusing on tools and technologies, think about the pain points you have and the capabilities you need to solve them, or a capability that is crucial for a strategic direction. Then identify and name the capabilities that are important to your business. Naming is critical because, without having shared names for technical capabilities, you’re limited in your ability to talk productively and plan effective action. Without a clear process for improving those capabilities, they won’t likely be addressed, or they will be addressed in an ad hoc way that limits their impact.

Once you have started naming your technical capabilities, you’ll need a continuous improvement loop to address the highest priority issues first. And these improvements must tie back directly to business pain points or identified needs because the most important reason to build capabilities is to improve business outcomes.

Here’s the high-level picture, which we’ll be elaborating on in further sections:

• Find business pain points or a strategic direction where there’s alignment on the need to improve how you operate
• Name and define the capabilities to build or enhance
• Create a team and incrementally reduce the pain or address the need
• Be deliberate about providing for reuse
• Design an approach for having this be part of a new way of working if that’s desired

Solve for Pain Points or Critical Needs

The technical capabilities you build should be those that directly address issues of importance to your organization; specifically pain points or needs you’ve identified for critical initiatives. A pain point is any place in which you are not effectively executing, and there are business consequences.

Here are some examples:

• One organization we worked with had so many challenges with scaling that the system was not performing as it had been sold, and clients were not renewing their subscriptions.
• In another organization, they had emergent businesses whose growth depended on fast customer feedback, yet they had a three-month release cycle and could not get fast feedback, which in turn impeded growth.
• In a completely different organization, their code and technical practices were so problem-ridden that they had difficulty attracting and retaining staff. Newly hired staff were quitting after a few months at a great financial cost to the organization.
• Another organization had many quality issues:
  • In production, it took up to 35 hours to find the source of a defect. Defects could be code issues, deployment issues, or inconsistencies across systems that were supposed to be identical.
  • Once the defect was located, it could take weeks or more to deploy a fix due to difficult-to-maintain code or their manual and error-prone build and deployment processes.
  • The Production Support team who deployed the fix wouldn’t always tell the developers what they’d done to fix a problem, and the same code defect might be re-deployed in a later release.
  • The situation was so bad that the highly paid business users often couldn’t fully do their job. They would refuse new releases because they were afraid of the impact of new defects.

These are examples of real business problems, and they are also pointers to places where technical capabilities could be added or expanded in your organization.

Solving for a key pain point has several plusses:

• It is easier to get funding and capture people’s time to address a pain point. The business case is simpler to make when there is a known problem that needs to be resolved.
• It is easier to get people in place to support the capability once it is defined, which might include hiring or training on new skills.
• People are more willing to make policy and process changes when there is something critical at stake.
• Once you’ve built capabilities to solve a pain point, much or all of it may be reused to address future pain points, lowering the cost and process barriers to adoption.

In some cases, you will be building capabilities to address future issues that will come about due to your business strategy; for example, closing your data centers and moving to the cloud will prompt new approaches and capabilities for security. These are good reasons to build a capability to enable a future goal, but they might be a harder initial sell because they’ll be more abstract. It is crucial for enterprise architecture to have a strong relationship with their business partners and be present from the earliest stages of business planning.

Once you have a clear pain point to solve or an issue to address, along with the willingness and resources to solve it, you’re ready for the next step.

Name the Capabilities to Be Improved

What’s a capability? In essence, it is what you do as an organization, not how you do it. Having shared names and an understanding of the capabilities you want to build enables you to have effective conversations. For example, if you sell to consumers, one capability might be “Test Alternatives in Production (A/B Testing).” You may do this in a variety of ways, including:

• Use tools that automatically vary fonts, font sizes, spacing, and colors to see what leads to the highest click-through to next steps.
• Implement infrastructure to direct a certain category of users to a particular set of features, or geographical areas for certain time periods.
• Present multiple visualizations for the same offering to see which ones get the best customer response.

As you get started with this process, you may ask, are there existing frameworks for talking about IT capabilities? Yes, extensive ones, including ITIL 4. However, if you want to have a conversation about building technical capabilities, you can start with names that make sense in your organization’s context. If you already use ITIL or a similar framework, it is fine to use their capability and service names. However, you can also be weighed down by a framework. If you can start simply and learn, that will provide faster results and learning.

Determine the Improvement: From What to What?

Let’s continue with an example from above – the ability to scale. Scaling is the ability to add or reduce capacity in a system to meet the demands being placed on it. For example, an insurance company or bank might have extraordinary capacity needs when severe weather causes widespread damage, as clients try to file claims and apply for loans. During that time – it can be as small as a few hours– the system must be responsive and customers to interact with the systems.

When you know what capability or capabilities need to change, describe and quantify what exactly the improvement is you need; your from state and to state. Here’s a sample of what that might look like.

While this is the core capability you are changing to address the pain point, there may be other related capabilities that also need to be created or enhanced depending on your organization. Here are some possibilities in this scenario:

• Creating containers
• Managing containers
• Deploying applications to the cloud
• Infrastructure as code
• Immutable Infrastructure
• Load balancing
• Service management (e.g., discovery, messaging, and security)

The key to improvement is to build and deploy small increments of value – in this case, small improvements to the organization’s ability to scale.

Delivering the Capability Incrementally Through a Multi-Disciplinary Team

Once you’ve decided what capabilities you want to build, you’ll need a few things:

• Someone to act as a Product Owner for the capability, deciding what to build and in what order (an architect, for example)
• People on a team (or teams) working to create the capability
• A roadmap and backlog for the incremental delivery of value
• An execution approach such as Kanban

Usually, the most complex thing about capability building is the composition and model for how the team or group of teams work. While you may have dedicated teams for most of your software development, capability teams can require people from across the organization to work together intensively for a period and then dissolve. Continuing the scaling discussion, the following groups would be represented on the team:

• The team who owns the server application that needs to be decomposed into services
• An infrastructure team to create the automation to build the new infrastructure, to deploy into it, to secure it, and to manage it
• Someone representing application, data, and infrastructure security
• Someone who can build scaling models and recommend where to start with converting the monolith into services

One approach we’ve used with our clients is using workshops to build capabilities. Twice a week, for four hours, over a period of months, the cross-functional team meets and uses a mob-programming approach to build the capability or capabilities they need. This includes the coding and configuration of the capability, as well as designing the processes and policies for how the capability will be implemented into production and managed. Not all the work must be done in these sessions – application changes, for example, can be done by the application team as part of their regular team process.

Another approach we’ve used is to have a temporary team comprised of people on-loan from across the organization’s other teams who work exclusively on getting the capability up and running. This can increase speed but can be detrimental to the work of the teams who are giving up people to this focused capability team. But if you need a capability built rapidly, this might be a good option.

Finally, the capability team should deliver value incrementally. For example, perhaps one or two parts of the monolith have the greatest need to be able to scale. Those pieces can be broken out from the monolith and run using the new approach. You have addressed a critical scaling need and can proceed then with the less critical parts until you have solved the pain.

An important job of the team is to document the parts of the capability or capabilities that are intended for reuse and make them available in a shared repository. They may conduct lunch-and-learns to advertise the new capability, and they may even work hands-on with others who want to reuse the capability.

There is also a cultural change that’s needed. New ways of working – as embodied in new capabilities – won’t be adopted without help and guidance. That cultural work isn’t usually undertaken by the team that builds the capability. Generally, the organization will need a broader approach to having new ways of working adopted, including change management. This is a big issue. If you don’t address this, nothing will change in your organization. If you build it, they will likely NOT come. Many organizations have capabilities that are not used as broadly as envisioned; these unused capabilities tend to atrophy to the point that it was a wasted investment. This is a topic we can only touch on here.

Recap

In summary:

• Find business pain points or a strategic direction where’s there’s alignment on the need to improve how you operate
• Name and define the capabilities to build or enhance
• Create a team and incrementally reduce the pain or address the need
• Be deliberate about providing for reuse
• Design an approach for having this be part of a new way of working if that’s desired

This overall approach is a powerful way to focus and move to the future.

Interested in getting support to build your technical capabilities and resolve your most pressing business challenges? Contact Eliassen Group today!