The Human Side of Technical Leadership

There are several roles that require technical leadership over various teams of engineers. Depending on the context and the kind of company, we might be talking about a Principal Engineer, a Staff Engineer, a Solution Architect, or even the CTO in the case of smaller startups.

One aspect of these roles that I haven’t found much information about—and which I consider key to your success as a technical leader—is how human groups are a living part of your technical solution. Let me explain.

It’s clear to engineers that we need models to reason about complex systems. For instance, following the C4 model, you can define various abstraction levels: Context, Container, Component, and Code. These layers of abstraction are certainly important in technical leadership when developing, maintaining, and envisioning the target architecture of an enterprise.

However, there’s another layer that affects IT solutions at least as much as those mentioned above—one that is often overlooked by traditional diagramming tools and engineering-focused roles. I’m talking about the involved teams, roles, stakeholders, and how all these human aspects influence your solution. How do these people work together?

If you want your architecture to effectively fulfill its mission, this aspect is key. Over the years, I’ve realized that it’s unfortunately neglected far too often. Especially if you’re a Solution Architect or in a similar role, joining a solution that’s been in place for many years (which is usually the case), it’s important to understand not just the technology behind the solution, but also the “human system” maintaining and developing it.

There are various reasons why this is so often overlooked. In some cases, it’s because it has a lot to do with tasks typically carried out by other roles, like human resources and traditional management. Technical leaders might pass over a description of a profile that’s needed here and there, and maybe they’ll join the technical interview. But that’s not nearly enough to ensure proper human support for your systems.

As a technical leader, knowing only about tech is simply not enough to successfully fulfill your mission. The good news is that many of the tools we use to understand technical concepts can also be used to model how people work together.

Systems Thinking to the Rescue

As Peter Senge described in The Fifth Discipline, Systems Thinking is a discipline that integrates the other four disciplines of a learning organization: personal mastery, mental models, a shared vision, and team learning.

Organizations are complex systems, and tools from Systems Thinking can help you understand how feedback loops, delays, and non-linear effects impact an organization—effects that can have a noticeable impact on your IT systems. Leadership-driven decisions don’t act in a closed system, and having a model can help prevent unintended consequences.

Refining your model can, in turn, help you reinforce positive feedback loops and reduce lead times, facilitating a more optimized overall system where every actor enjoys the benefits of reduced frustration and a clear positive impact on the company’s outcomes.

This may sound a little too theoretical. What tools do technical leaders have to build models of the organizations supporting their systems?

Git

If we’re talking about software, chances are there’s a lot of valuable information about how your teams work in your version control system (nowadays, almost always Git, one of my favorite tools ever).

Are your teams verticalized? This is, are they enabled to build and deliver features end-to-end without dependencies on other teams? If they’re not, you’ll most likely be able to see this in Git. Long-lived feature branches, pull requests that take forever to review, and code that takes days or even weeks to reach production—this information can help you build a model of how your engineers are working together. It can also guide you in making decisions that will significantly improve how quickly and effectively your system evolves.

Event Storming

Event Storming is a technique popularized by Alberto Brandolini in the context of Domain-Driven Design (DDD). It consists of a workshop, typically spanning two to three days, where your technical teams are brought together with domain experts and stakeholders in the same room. The idea is to have representatives from each area that plays a significant role in your solution and follow a process to model all the domain events involved in delivering value to your customers. This is done by placing sticky notes on a wall that represents a timeline. This practice can be extremely helpful in identifying inefficiencies, allowing you to apply Systems Thinking to model the solution, including processes that might have been overlooked, and helping you make better long-lasting decisions.

Talk to Your Teams

Let’s not forget the obvious. Scheduling one-on-ones with engineers, stakeholders, or suppliers can fill in a lot of relevant gaps and help you better understand how your colleagues are working. Reading documentation and meeting notes from key events in the past can also shed light on potentially unattended parts of established processes.

Implementing Solutions

As with many other things, following Systems Thinking to model how your teams are working can lead to a Pareto-principle kind of situation. Some measures will be reasonably easy to implement and will have a significant impact quickly, while others will be challenging to implement, conflict with a well-established status quo, and require time.

The larger your organization is, the higher the chances that Conway’s Law will have a significant effect. Nevertheless, you cannot be a good leader if you’re impatient. Oftentimes, effective leadership requires a willingness to say the same thing time and again until your message—your vision—reaches the whole organization.

Also, don’t forget that you’re not alone. One of the lessons of Systems Thinking in an organization is that leadership is not so much about individuals but about the whole system. Try to influence the “human system” to create momentum so that positive feedback loops make your job easier each time.

So, what do you think? Have you successfully applied Systems Thinking to your environment? I’m looking forward to hearing your stories!

Back to the top ↑