Beyond Numbers: Embracing Contextual Intelligence in Engineering Leadership

The realm of engineering excellence hinges on the elusive concepts of cohesion and alignment, weaving together stakeholders, cultures, and goals. Yet, amidst this awareness, a perplexing gap persists between engineering teams and their leaders. The crux of the matter resides in the sense of mutual alienation, prompting the question: are we still overlooking essential aspects of the engineering culture?

In this article, we uncover the factors behind this gap using eye-opening statistics. According to a recent Uplevel survey, one-third of developers believe their engineering roadblocks go unnoticed by leadership. Imagine the consequences: 56% of CTOs make strategic decisions without realizing the negative impact on their team, 51% reassign people without knowing the full implications, and 44% end up overworking developers. Shockingly, 96% of developers say not knowing their own leadership's focus hampers the larger team.

So, what steps can we take to address this situation? First and foremost, we must delve into the root of the problem by examining the patterns and attitudes that contribute to the growing divide between developers and management. As someone who has successfully fostered collaboration between engineers and leaders, I hold my own ideals that I am willing to share without imposing them on anyone.

Fragmented Forces: Disunity vs. Engineering Power

The impact of disunity on engineers goes beyond mere practical implications. On a human level, it profoundly affects them and leaves unanswered questions about the company's policies. Engineers desire to be active participants in the decision-making process but often find themselves hesitant to take on that role. Instead, they rely on their managers to address these concerns, hoping for resolutions that align with their interests. However, when an engineer's voice holds no weight within the company, decisions are unlikely to be in their favor.

As a delivery representative, I was acutely aware of my team's interests. My focus revolved around three core pillars: the client, my people, and top management. With this perspective, my objective was to find the best possible outcome for everyone involved. The underlying relationship is clear: without a cohesive team, there will be no project tomorrow. Similarly, a team in disarray and chaos will lead to the same outcome. People form the foundation within this framework.

Subjectivity Holding Back the Truth

In most cases, top management tends to rely heavily on numbers as their primary perspective. Unfortunately, these numbers lack a crucial element — objectivity. Default statistics are inherently subjective and fail to accurately reflect the company's true market situation. While large companies prioritize margins and financial performance, they often overlook the factors that contribute to their current state.

As a result, top management frequently finds themselves detached from reality. Maintaining a connection between engineers and leaders becomes increasingly challenging. This challenge becomes even more pronounced in larger companies with hundreds of employees, where hierarchical communication is unavoidable. Each layer in this hierarchy adds its own subjective interpretations, resulting in distorted figures and opinions that deviate from the actual reality.

Developers naturally encounter critical challenges, both with projects and clients. The problem lies in the fact that managers, driven by personal motivations to appear favorable in the eyes of their superiors, tend to withhold the true extent of these challenges from being conveyed upwards.

This miscommunication not only gives rise to various risks but can also lead to project failures. Upon closer examination, management discovered they were unaware of significant challenges that should have been escalated. When questioned about the lack of escalation, managers often justify their actions by claiming a desire to solve everything on their own, only to realize that such an approach is ineffective.

Red Tape Regime vs. Transparent Alliance

In 2019, I joined my current company as a lead and architect with a clear stance that disregarded the notion of subordination, especially in the tech realm. Instead, I emphasized the importance of respect. Unlike my previous bosses, our CEO grasps the fundamental truth that engineers drive the company's profitability. This starkly contrasts organizations where developers or internal staff are seen as cost burdens.

To foster a strong connection, several key points come into play.

• Firstly, management needs to exhibit openness and a willingness to look beyond numbers and margins.
• Secondly, they should genuinely engage with business matters, even if they personally don't handle them directly. Top management can appoint representatives, such as a chief delivery officer or chief operating officer, who immerse themselves in the company's affairs.

When leaders establish a culture of care and inclusivity, this mindset permeates throughout the managerial chain. I can confidently say that my managers are fully committed and engaged, going above and beyond.

I have witnessed executives who initially approached our company with a bureaucratic mindset. However, their flexibility led them to embrace a more humane approach, becoming understanding, attentive, and open. Directness became the norm, allowing for the defense of their teams' interests without sugar-coating the truth.

Maintaining this connection requires individuals who are willing to represent their engineers. Additionally, proactive leaders among the engineering ranks should fearlessly express the realities of the situation. It is through this alignment that true synergy is achieved, enabling decisions that genuinely consider the interests of both parties involved.

The Dilemma of Metrics and Context

To be honest, I'm not a fan of metrics. There are countless metrics out there today measuring efficiency, technical aspects, and delivery features. But here's the thing (I always tell my team and those seeking advice in other companies): when it comes to performance, none of these metrics truly determine efficiency. Metrics can be manipulated, and every tracker can be circumvented. You can create the illusion of work. Comparing previous sprints to the current one isn't practical since tasks, environments, and performance factors can vary.

There are technical metrics that indicate "good" or "bad" outcomes, such as production issues or errors. However, even code quality metrics are subjective and based on configurations. Regardless of the metrics in your toolkit, you still need a leader, a manager who considers the human factor. Someone who understands the reasons, motivations, and, most importantly, the context — the intangible aspects beyond the control of mechanisms. I advocate for a balance of metrics and managerial insight. To achieve this, we need to trust our people more.

As managers, we are responsible for providing numbers to upper management, from financial indicators to statistical data. It's the foundation of our work because, at the end of the day, it's business. However, if we only present numbers without context, the overall picture will always look rather bleak.

Metrics may not be applicable to every project. They're not universally fitting. Metrics can be useful if a team performs the same tasks under the same conditions and requirements, following a constant stream with consistent content. But metrics have limitations in an agile environment with numerous blockers and variables, where projects are as changeable as the weather. Planning is often short-term due to shifting business priorities. The market is flexible and unpredictable, and we must be highly adaptive.

We have a multitude of diverse projects with varying requirements, access levels, and different coding standards provided by clients. In many cases, we rely on the client's team, which has its own manager. When there is complete control over the product, both technically and from a product perspective, everything falls into place easily. Before fixating on any metric, it's wise to ask yourself, "What will it truly provide?" And it's not a bad idea to follow up with another question, "Will this metric be objective in this particular case?" Armed with these answers, we can proceed.

Culture of Responsible Freedom

We’ve already figured out the way subjectivity is not helping present a valid picture. When it comes to objectivity, I believe it stems from having trustworthy leaders in key positions. Additionally, hiring individuals with the right mindset is crucial. By "the right mindset," I mean a combination of openness and proactiveness. Personally, I value an active employee over someone highly intelligent but less proactive. In our engineering culture, getting things done is paramount. Timely reporting of issues leads to timely solutions, ultimately preventing phenomena like high staff turnover.

Let's consider a scenario: a project experiences a significant turnover rate. While the metrics might not indicate a problem, ten people leave, and ten new hires join within a year. Engineers often discuss this issue informally but fail to escalate it to their managers, who, in turn, don't take the initiative themselves. The lack of action is the root cause of the unresolved problem. It brings us back to the importance of hiring individuals who align with the established culture, or else we risk the absence of an engineering culture altogether.

When building an engineering culture, metrics alone won't enhance performance; they can even complicate matters. For me, culture thrives on creative freedom, although this may not be universally agreed upon. The right people, in the right roles, know how to leverage this freedom alongside their inherent sense of responsibility. I simply don't work with those who don't. They understand the importance of attending meetings and delivering results while having the flexibility to work remotely, be it from home, Bali, or their grandmother's farm. It's about responsible freedom.

Сatalyzing Team Chemistry

When forming a team, I typically choose individuals who align with my values, the existing core team, or myself as the lead. I also prioritize selecting team members from similar time zones and cultural backgrounds. Generally, I prefer straightforward personalities who are easy to interact with, as they are less likely to mesh well with rigid bureaucrats bound by conservative principles. However, I acknowledge that other companies may appreciate things that I personally reject.

Regardless, if we treat soft skills as secondary, it can spell doom for both the leader and the entire business. Hard skills can be measured through metrics, but it is the soft skills that provide context. It becomes clear that in order to fully tap into and harness these abilities, one must possess a natural perceptiveness and a genuine desire to bond with people.

I want to emphasize once again: communication is paramount. As managers, we must actively listen to our team members and be attuned to their challenges. It is our responsibility to maintain a strong connection with them and clearly understand what's happening in their lives. Observing their engagement in meetings, their responses, their departures, and even their silence are essential. We must be ourselves, encouraging our teams to do the same.