Leadership Essence v2: Clarity, Environment & Architecture

the 3 Legged Stools of Engineering Leadership

This is the 2nd revision of my reflection on engineering leadership, the first version is here written 2 years ago, time flies!

The question behind this topic is — how to be a good engineering leader? or — how would you evaluate an engineering leader? Every person is unique and leadership is a high dimensional vector, if we want to project leadership into a few pillars to focus on, what are those?

I asked this question to more leaders around since I initially thought about this problem two years ago. Surprisingly, very few gave me very methodical answers, many gave me very short answers, a lot struggled to give an answer. Leading by guts is not wrong, but I think with clarify on the framework, it is easier to identify and grow future leaders. There is absolutely no correct answer to this topic, and it is gonna evolve as we learn in life. In this post, I will explore my latest framework on the key areas of engineering leadership one can explore!

Clarity

My one line version of “describe leadership” is to consistently inspire people with different perspective to march towards the same objective and deliver results.

Ultimately you work for some purpose, and you want to achieve some objectives for yourself, your team, your company, your investors, and the society. If you can not bring absolute clarity for your objective and the connection between your objective and your projects (what is our mission? why is this project related to our mission?), it is gonna be extremely challenging for you to inspire your team.

After you have clarity on the objectives and figure out a set of projects you need to do to achieve your objectives, next thing is to bring clarity to priorities. I think you are half way through the execution after setting the right priorities. We all have constraints (a project without constraints is unlikely to succeed), personally, or as a team with limited number of hands. It is critical to define the priorities for your team at various levels (categories of work, phased rollouts), so the team can resort to the priority to decide what to do next in an autonomous way.

One thing I gradually realized is, as far as the direction & priority are clear to the team, you are building a team that is gonna deliver values consistently, slow or fast. On the other hand, if you are not being intellectually honest with yourself and set the team with a dozen top priorities, you can barely make any progress.

Environment

After you established clarity on your objectives and priorities, it is time to build & foster a rock star team! By environment, I mean culture and values of the team. Culture is the common behaviors we encourage in the team, values are how the team make decisions when you’re absent. In most cases, you either start a team from scratch, where it is extremely critical for the first few hires, or you inherited a team, where it is important for you to immerse the team with the culture you intend to build and have the team practice the culture everyday.

One thing I have a contrarian view is, successful hiring is a byproduct of a great environment. The first few hires to set the tone for team culture is absolutely critical, nonetheless, I think once you have built a strong culture for the team with a great environment, your team is gonna be a talent sink and everyone wants to join. Note — I don’t mean you can just sit and wait for talents to join, but you don’t have to over-sell your team. You still need to hustle but the reputation & deliverables of your team will propagate across the company and industry.

How to tell if you have established a great environment? Pick a random guy in your team and ask what is our team’s culture, can they articulate on behalf of the team? :)

Architecture

A previous leader suggested “technical architecture/vision” as the 3rd stool of the essence of engineering leadership. After a lot of observations and thinking myself, I think technical architecture is only one aspect of the architecture. It is not technical architecture but organizational architecture.

I am a strong believer of Conway’s law:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Org leaders is the architect of their organizations. I have learned the lessons hard from my personal experience working with suboptimal org structures, it had been super frustrating. The most frustrating point is, if you feel your team is not in the right place, there is little you can do to address the broader organizational issues, especially if it is an issue spanning across multiple organizations.

Organizational architecture requires the org leader to have a deep understanding of the business context, technical layout, the people inside the organization, and then you can lay out the most effective organizational architecture to reduce frictions in information flow and make each sub organization as autonomous as possible.

• Business context. As engineers, we often get the privilege to focus on tackling the technical challenges without really understanding the business rationale behind the stuff we are building. Nonetheless, as an engineering leader, it is more than necessary to grok the reason why this team exists from business perspective, in the end, that is why a team is funded. Equipped with business context, you are much more likely to steer your organization towards success.
• Technical architecture. Understanding the core technical architecture is also very important for a few reasons. You want to reduce the communication between two teams as much as possible to create autonomous teams, that means a clear API interface between these two teams, that requires the org lead to be able to understand the technical architecture (tho not proposed by the management), but the management POC must understand the architecture with enough insights so they can structure the organization in a way that doesn’t hinder the interface designs.
• People. People is another critical factor to consider in org design. In How Google Works, Eric also suggested to design organizations around people. Everyone is different, it is just important to put the right people in the right place. Talent is always the top 1 priority for any company.

In the end, there is never a perfect org chart lasts for ever. Technology evolves, people change, and business pivots, you have adapt your org chart to best facilitate the information flow in the company. Another challenge of org design is, the cost of re-org is often quite high — you can always eat the bullet and refactor your code base with a known impact and cost, however, re-org a team has a lot of risks and unknowns.