Lessons learned from talking to 100s of Engineering Leaders

Klarissa Fitzpatrick
6 min read

Eiso Kant is currently founder and CEO at Athenian. His work at Athenian helps engineering leaders improve the productivity of their teams. After speaking to hundreds, if not thousands, of engineering leaders, he developed mental models to help engineering leaders evaluate themselves in key areas. He shared them with us at the CTO Forum.

Balancing out product and people

Eiso has spent a lot of time discussing and thinking about the dual responsibility of technical leaders. The pressure is on to deliver value to the users, but technical leaders are also responsible for the product that is the engineering organization, composed of its people and culture.

One characteristic common to the best engineering organizations is a culture of continuous improvement. Oftentimes, Eiso encounters a common dream: that if you add people to a team, there will be a linear increase in output.

But in reality, the changes tend to look more like steps. Having more team members doesn’t automatically translate to gains in productivity, or a culture of continuous improvement.

Instead, Eiso says, tapping into that culture requires the capability and willingness to iterate constantly. Eiso likens it to a muscle you must consistently exercise, and finds that the best engineering organizations practice consistently.

In order to help find areas of iteration and challenge yourself, Eiso has created eight mental models. The models help engineering leaders evaluate themselves in different key areas so they can manage in a more informed and successful way.

Tech-oriented vs. people-oriented

Cliché or not, determining where you land on this spectrum is useful not only for your own professional development but for your company’s overall health and success. Do you prefer thinking about the people of your organization, or do you get more excited about architectures, libraries, and languages?

For an early stage startup, the technical leaders will be quite technical, as the company needs to create a product as soon as possible. A larger organization, however, requires more maintenance, and thus interest in the people, their roles, and team structure. So engineering leaders must find their own balance, as well as adjust to the needs of their business.

Confidence vs. competence

Demonstrating both an in-depth knowledge of the technical details and being capable of giving an executive summary is a key skill for engineering leaders.

In meetings, Eiso suggests that you make a sandwich. You begin the meeting with confidence, demonstrate competence during discussion, and end with a confident executive summary. He notes that honesty is the best policy: Don’t be afraid to ask for support if needed, so the work can move forward.

People, process, or product?

Do you spend more time thinking about people, process, or product? How much time you spend on each of these elements is also a function of the maturity of your company.

If you're a tech leader in an early-stage startup, product is pretty much the only thing that matters. But as the organization grows, people and process become more important.

Eiso encourages leaders to take an honest look at how they are splitting their time between these three topics. He often finds that engineering leaders are not necessarily as aware of how they split their time between these three topics as they would think. Understanding that time spent on these topics is time invested in the present and future success of your business is key.

How strongly held are your opinions?

On a spectrum from adaptable to dogmatic, opinionated sits in about the middle. Being opinionated as a leader is important–especially in young companies. Being able to make decisions like choosing the coding languages quickly is necessary for the company to advance as fast as it needs to.

But as soon as your company begins to scale significantly, having alignment in the organization becomes key to its success. At that point, engineering leadership must present a certain level of adaptability.

As for being dogmatic…There is no place for that in an engineering organization, Eiso says. Engineering leaders need to maintain a level of curiosity and openness because technology evolves so rapidly.

Short, medium, or long-term?

How much time are you spending on short-, medium-, and long-term decisions? This is an obvious point that is often repeated among founders. The real surprise, according to Eiso, is how most organizations really only think one or two quarters ahead–if they even have the space to do that.

But there are tradeoffs that need to be made, Eiso says. Decisions made in the early stages of a business can lead to obstacles and pain 10 years down the line. So bringing a balance to those questions of build and run is very important, so that down the road you can maintain exterior and interior quality as the company scales.

Engineers, customers & non-engineers

Are you spending more time with engineering, customers, or non-engineers? In most cases, engineering leadership spends time solely with the engineering organization. According to Eiso, this is one of the most limiting things you can do.

Outside of leaders at small startups, who likely speak frequently with all their colleagues, engineering leaders at all levels of an organization should make a point of having regular meetings with peers in other functions. When you have a more global view, you can spot and understand bottlenecks in the business outside of the engineering organization–and begin understanding which problems are urgent and which are less of a priority. Not to mention, speaking to leaders outside your department allows you to grow. In fact, Eiso says getting exposure to other functions is a key step for engineering leaders to move from being able to manage dozens of engineers to managing hundreds of engineers.

Coaching vs. setting expectations

Should you be coaching or setting expectations? Eiso makes no bones about his position on this question. Setting expectations is one of the most important things that must happen as a company scales.

Because we come from a culture of consensus-seeking, and engineering leaders in particular have such a respect for the knowledge of their peers, coaching is the default. Eiso says it is a comfortable space to be in, nudging people toward the direction you want to go in. But setting clear expectations empowers teams, because they know how to succeed. This is one real need Eiso has seen across many engineering organizations.

How do you balance quality, customer impact, and velocity? Having the perfect balance to ship fast, with perfect quality, and fix the bugs is a holy grail. You have to communicate well, both with yourself and your team, to set the right expectations within the organizations.

For example, SRE should be oriented toward quality and application focused on velocity, but you can’t forget to align with business objectives too. Eiso refers once again to those meetings with fellow leadership in your company. You won’t know that you need to move fast to capture market share, or deliver high quality for an important client, if you aren’t in contact with leadership from other departments.

Final thoughts

  1. Your growth stage matters–the needs of your company evolve depending on its maturity
  2. Great engineering leaders find the right balance…
  3. But you don’t have to be everything at once! Make sure you find balance within your team.
  4. Engineering leaders are builders. Your goal is to provide impact to the end user by creating a great developer experience and creating a culture of continuous improvement.

In addition to using these mental models, check in on your perspective. Developers get into code because they are excited to build something and see it work well. Even though most engineering leaders aren’t coding at the office, you are still building. You are building the product that is your organization. This way of thinking can allow you to get excited about the work ahead, the same way you got excited when you began coding.

Share on
Other articles about:

Recommended articles