When working with some of my clients, it's common to observe some frustration with not being understood by other members of the executive team.

A typical complaint is that either the CEO or even the entire executive team fails to understand the importance of technological investments beyond pushing out new features: infrastructure work, paying back technical debt, security improvements, etc.

My general approach when working with Engineering Leaders with such struggles is based on two components:

1️⃣ Let them express their concerns and frustrations and empathize with their situation

2️⃣ Offer solutions that help them re-focus their attention on themselves and their actions

In today's article, I want to focus on the second part, specifically what I think a winning approach could be when facing a situation where you feel like you're not being understood.

As is often the case with my articles, I'll first start by providing some theory and concepts, and then move on to practical tips.

Let’s start with a seemingly irrelevant anecdote.

When I first started writing online - on Medium - I did it as a way to better learn the content of a book I was reading at the time, The 7 Habits of Highly Effective People by Steven Covey.

My original plan was to publish a dozen articles as I made progress on the book. Unfortunately, I stopped at 3, as back then I was still struggling to build consistency around my writing habit.

What's interesting, is that the last article I published on the series focused on a concept we're going to explore again in today's post: The Circle of Concern / Circle of Influence dichotomy.

If you're curious about the original article, you can find it here.

Let's now look at how this concept relates to the situation of Engineering Leaders complaining about not being heard or understood.

⭕️ Equanimity and The Circle of Concern / Circle of Influence Dichotomy

Stoic philosophers made the concept of Equanimity a keystone of their doctrine and way of living. One key principle of their entire construct was to focus on what is within one's power to change while maintaining equanimity towards what is not.

What is equanimity?

Here is a definition:

Equanimity is a state of psychological stability and composure which is undisturbed by the experience of or exposure to emotions, pain, or other phenomena that may cause others to lose the balance of their mind. The virtue and value of equanimity is extolled and advocated by a number of major religions and ancient philosophies.

Source Wikipedia.

In layman's terms, the Stoic approach can be broken down into the following two principles:

• 🎯 Focus your energy, attention, and actions on what you have control on

• 🧘🏼‍♂️ Don't bother with things that are outside of your control, and don't let them alter your mental and emotional state.

Covey took this concept further in the realm of modern Leadership and introduced the constructs of Circle of Concern and Circle of Influence

The Circle of Concerns encompasses all the things in life we have no control over: the news, the weather, other people's beliefs and behaviors, the laws of physics, etc…

The Circle of Influence on the other hand includes everything in life we have control over: our actions, our thoughts, our behaviours, and how we react or respond to whatever happens to us.

Covey's postulate is quite simple: depending on how you focus attention between these two circles, you get very different results.

😠 The more you focus on your Circle of Concern, the more you're adopting a victim's approach to life.

You are putting the locus of control of your life outside of yourself. That leads to a net reduction of your ability to influence your life. This usually leads to a life filled with anxiety, complaints, blaming, and a feeling of impotency.

💪🏼 Conversely, the more you focus on your Circle of Influence, the more you're taking a proactive approach to life.

The locus of control of your life is now internal, as you're taking control of it. Covey goes as far as to suggest that the more you focus on what you can control, the more your Circle of Influence will expand. This approach usually leads to a life of fulfillment, realization, impact, and a feeling of being in control of one's destiny.

Effective people focus on what they can control and are not bothered by things they don't have control of. This seems quite obvious, but it's only when you're able to fully internalize these concepts in the way you live that you'll uncover their full potential.

How is this at all relevant with my CEO and my executive team's inability to understand how building software works, you might be asking.

Let's take a look at that.

➡️ Applying these concepts to the reality of a CTO / Engineering Leader

Let's go back to the problem at hand: you are a CTO facing the struggle of not being understood by your executive team. Specifically, some or all members of the team fail to appreciate the importance of the technological investments that you are trying to execute.

We can look a the situation through the lenses of the Circle of Concern / Circle of Influence concept.

If you've been following along, you will now see how often the issue is framed in terms belonging to the Circle of Concern.

Language matters a lot here.

When someone is framing a problem in the following terms:

“They don't understand…”

“They don't care about….”

“They only care about…”

They are falling into complaining and blaming, a typical “victim's” approach. They are focusing their attention on their Circle of Concern.

You don't have control over other people's actions, behaviors, or beliefs. But you can influence them if you turn your attention instead to what you have full control over: your actions, behaviors, and beliefs.

In other words, you should not Ask to be understood. Instead, you should Make yourself understood. Don't expect others to solve the problem for you. They won't, as they're all too busy dealing with their load of issues and headaches.

Focus instead on what you can do differently to achieve better results.

It's your responsibility as a CTO to ensure your executive team understands and supports the work you're doing. I'd go as far as to say that this is one of your main responsibilities as a member of the executive team.

Once that idea has settled in, you might be interested in knowing how to make it happen.

Let's look at a series of tactics you can deploy to your advantage.

💪 A proactive approach to the situation

There is no magic recipe that will instantly get your CMO to ask you how impacted your company is by the latest CVE on TLS, or your CFO to suggest you invest more in paying back technical debt.

What follows isn't a 30-day satisfaction guarantee sequence of steps.

It's a list of recommendations based on what I've observed working well in diverse situations. Not all of them will apply to your case, and not all of them will lead to observable improvements.

The key underlying theme is that these are all actions that are in your control.

The first one might sound obvious, but it's often easier said than done.

🙈 #1 Do your job very well

I believe this is the foundation for everything else. Before you even consider influencing people around you, you need to make sure you have your act together and are building up a reputation as someone who delivers.

Cal Newport would refer to this as “Be so good you can't be ignored”.

As a CTO in an executive team, this often involves a combination of keeping your promises, being fully present in discussions, holding yourself and your team accountable, consistently deploying very high standards of quality in whatever you're doing, etc…

This will require you to deploy a high level of personal organization and discipline that will allow you to prioritize what matters, and not drop balls.

I can't stress enough how this part is important. It's always tempting to look at other people's shortcomings, while we tolerate or ignore ours.

Think of yourself as a role model, and act accordingly.

🤝 #2 Build rapport with your peers

Don't expect people to show interest in you and what you do if you're not willing to do the same.

As it's in your interest to improve the relationship, you should take the lead on building a rapport with your peers.

Schedule recurring sessions with other members of the executive team. Show genuine curiosity and interest in what their life is both at work and outside of work. Invest time and energy to understand what's keeping them up at night, and how you can help them.

By doing this you'll gain two key advantages:

On the one side, you'll get to understand their reality, and that will allow you to present your ideas and suggestions in a way that will connect with them.

Secondly, the principle of Reciprocity suggests that individuals are more likely to trust and feel closer to those who show interest in them.

This is a great opportunity to lead by example, rather than waiting for others to take the proverbial first step. Remember that it's in your interest to improve the situation.

🏛️ #3 When in Rome, do as the Romans do

The lingua franca of any executive team is the Business Language.

This is a language where key terms include: Revenues, EBITDA, Gross Margin, Time To Market, Net Present Value, Valuation, etc…

You will rarely encounter words such as latency or eventual consistency in there. These are terms that belong to the Engineering Language.

Imagine you are an Italian going to Beijing and expecting people to speak Italian with you because that's the only language you know. You won't make a lot of friends, and you'll be left with the frustration of not being understood.

That's essentially what happens when you insist on only speaking the Engineering Language with your executive team.

When you do that, you are putting the burden of communication on them.

You are implicitly saying: I don't care what your language is, and I expect you all to make the effort to understand mine.

A great way to end up being ignored, as few people in that team will have the incentive to put in the effort. Especially as they'll observe a lack of effort from your side.

Different companies will have different levels of familiarity with the Engineering Language at the executive level. Yet, technology is a means to an end. Desired outcomes should always be expressed in business terms, even then they require technological investment.

This leads us to the next point.

🤑 #4 Frame technical investments in economic terms

Though it's not always possible, you should strive to put a dollar value to every major technical investment you're proposing or executing.

In some cases, especially with investments in tech debt or security, it can be helpful to frame the implications in negative terms: this is what it'll cost us if we don't make this investment.

When the benefits cannot be easily or accurately quantified in dollar terms, you should still be able to clearly articulate qualitatively what will be the benefits for the business.

Here are some completely made-up examples to illustrate the point:

• By paying back technical debt in this part of our systems, we'll be able to dedicate 10%-20% more capacity to building value for our users as we'll reduce the amount of maintenance work required.

• By making these changes to the way we deploy our infrastructure we can reduce by 15% our annualized cloud costs.

• If we don't invest in fixing these X vulnerabilities we're exposing ourselves to a very high risk that within the next 6 to 12 months an attacker will be able to gain access to sensitive data. That can lead to fines amounting up to Y million, and reputational loss in the order of double-digit millions.

• If we don't upgrade the major version of our database we risk outages that will not receive support from the vendor as the current version is no longer supported. That means we could be down for multiple days in a row, with an estimated loss of X dollars per day.

💡 #5 Use analogies and metaphors

Analogies are an extremely powerful tool that every engineering leader should master. They allow you to express complex and often abstract concepts in very concrete terms that relate to aspects of reality familiar to people around you.

You can find analogies within the natural world, the business world, the world of noteworthy news, etc. There is potentially an unlimited supply of analogies you can choose from.

Using great analogies is more art than science, and you'll get better the more you practice.

One important principle to follow is to choose analogies by affinity to the reality of the people you're talking to. Don't use Star Wars based metaphors if you're the only Sci-fi nerd in the group. That would be perceived as just a dialect of the Engineering Language we spoke about earlier.

These analogies should be accessible, rather than expressing your closeness to certain cultural niches. In other words: use them to be understood, not to look smart.

One example I've recently used with a client felt appropriate as it related to something they're very familiar with.

We were talking about the need to make constant investments in infrastructure and cloud setup to keep them operating in a healthy state, and how it's often difficult to convey the importance of such maintenance tasks to a nontechnical audience.

That’s when I offered the analogy of an event that they were all very familiar with: the collapse of the Morandi bridge in Genova.

Though investigations are still ongoing, there is a lot of evidence showing how outdated design decisions combined with a lack of proactive maintenance might be among the causes of the tragedy.

The event can serve as a great illustration of the importance of making recurring maintenance investments, and the potential implications of not doing it.

🎓 #6 Educate without patronizing

Once you've made progress building rapport and trust with your peers in the executive team, you can also start investing some of your time in educating them on technical topics that are relevant to your business.

What's important here is to make sure you do it with the genuine intention of upskilling, rather than patronizing or showing off.

You can do this in individual sessions with selected members, or you can even organize group sessions where you offer those explanations in the form of informal lectures.

In my experience, I've done both types of sessions successfully. Some notable examples have been:

• An almost 2 hours lunch with the CFO on the benefits of CI/CD, Cloud, Observability, etc, using the back of our paper tablecloth as a whiteboard.

• Sessions with the entire executive team in Mexico, aptly named Tacos de Bistech, where I would illustrate foundational tech topics while we all enjoyed some tasty tacos.

Be flexible, and adjust your approach based on people's interests and preferences.

🏁 Conclusion

In today's article, we've been looking at the problem that many CTOs face: the feeling of not being understood by their executive team.

We looked at the theory behind the constructs of Circle of Concern and Circle of Influence, and how they relate to this situation.

Finally, we looked at some practical tips on how you as a CTO can take ownership of the problem by focusing on what's in your control.

I often work with engineering leaders to help them face such challenges, shortening the path from problem to solution.

If you think you could benefit from external help, feel free to head over to my website and schedule a free 30-minute discovery call. I'd be delighted to get to understand your situation more in detail and explore opportunities for collaboration.

And if you have successfully leveraged other approaches to build a deeper relationship with your executive team, please share in the comments section below! I'm sure many people will be interested in hearing about your experience!

See you next week!