Engineering Leadership

Copyright © 2023 Kilton Hopkins

We have all had great team environments and crappy team environments over the course of our careers. It's tough to keep a team of engineers working together effectively... when they are talented individuals. The dynamics of a mediocre engineering team are very different from those of a high power group.

"I don't care how the work gets done. I care how the team is run."

Talented individuals are looking to apply their unique problem-solving abilities wherever they have an insight. That's because a natural motivation to solve problems is part of what drives someone to become a talented engineer. Every high power engineer is a refined representation of their accumulated experiences, plus a lot more. Given that, every engineer is like a different algorithm or function that produces unique results when applied to a problem.

In a perfect scenario, it is best to run a problem past every available engineer because viewpoints are additive. In daily practice, we can't always do that but all of us need to remember at all times that viewpoints are always additive.

I personally believe that every engineer has more talent in reserve than they have on the surface. A well-operated engineering team environment will help bring everyone's talent up toward the surface.

What makes it difficult

Most of us are accustomed to being in environments where the loudest voice wins or where the most senior team member eventually pulls rank. Some of us feel that we have frequently been the smartest person in the room but not the most trusted.

Because we have not had optimal work environments, all of us have developed habits that we need to investigate and possibly adjust in order to match sustainably with other top talent.

I remember when I first began to work on teams with people who were smarter than me and better at some things. My first impulse was to show that I belonged. I often did that by pushing my ideas strongly to make sure they got heard. What I didn't know at that time was that a well-operated engineering team has "being heard" already built into the structure, which frees the engineers to focus on their contributions and skip the struggle to have their contributions heard and respected.

I learned that a good amount of the effort needed to wrangle and navigate team dynamics can be offloaded to a clearly defined process. It was cool.

When we encounter people who are really talented, we often feel one or more common discomforts. One example is feeling that the talented person might leave the team or become tired of carrying more than their share of workload. Another example is feeling that the talented person will branch over into our specialized area and eclipse our ability to be respected and heard.

These feelings are much easier to handle when I remember that I am talented, too. The other team members probably have the same feelings bubbling up for them when they interact with me.

Being able to trust each other as team members takes time and requires some "trials". There is no way to trust something that hasn't been tested.

So every team member needs to lean into the hardest part of being around other talent - the difficult stuff - and get it out in the open so the structure of the team can be tested until it is genuinely trusted.

Engineering Management versus Engineering Leadership

Engineering management is all about measurement and course correction. It is goal-oriented. The measurement part consists of tracking if the team is achieving a stated goal. The course correction part is when the measurements are not looking favorable and someone needs to "manage" the situation by making changes.

Engineering management asks questions like "What do we do this sprint?" and "Are we hitting our targets?"

Engineering leadership asks "Are we living up to our agreed upon team culture?" and "Is every engineer growing more and more trusting of the team?" The process of defining, refining, and defending the engineering team culture is part of engineering leadership.

Engineering leadership is also the following:

• Focused on how we work together both as humans and engineers
• Oriented around growing the technical skills of the team and its members
• Ensuring the team will attract and retain talent
• Focused on guiding instead of correcting or commanding
• Growing new leaders within each team member

The more that engineering leadership is embodied within everyone on the team, the more sustainable the culture will be over time. Senior team members ideally are able to teach newer team members engineering leadership by example and direct coaching.

Breakdowns in team culture

Even a well-operated team will suffer setbacks and breakdowns. Team culture is alive and it can become ill or die. It is fed and kept healthy by regular care in the form of culture review discussions and structure that assumes self-correcting change will always be needed.

Here are a few things that tend to break down engineering team culture:

• New team members added to a team that has already solidified but does not have a clearly defined culture and onboarding approach
• Converting duties that used to belong to one or more existing team members into a new full-time position
• New management that does not understand team leadership
• Mixing management and leadership (the result is that neither can be done properly)
• Pressure of any kind that causes the culture sustaining structures to be ignored, such as tight deadlines or reduced budget

What talented engineers want

All talented engineers want similar things as a "bottom line" and usually these things align very nicely with business goals and the desires of the other team members. Stating them explicitly can help ensure their manifestation.

Here's what engineers want (this is not a comprehensive list):

• Solve meaningful problems using their most trusted skills
• Learn new skills and try them on real problems safely (note that the new skills may just be a personal interest)
• Avoid repeat work or unnecessary work
• Have a seat at the table (this must be an actual voice, not just a token representation)
• Be part of something bigger
• Be recognized for their ongoing efforts
• Be applauded for notable achievements
• Trust their team and be trusted in return
• Be fairly measured, guided, and coached
• Have the opportunity to be amazed by others and learn from them

Brainstorming and group problem-solving

The favorite part of the day for many engineers is when a challenging problem arises and they get to kick their abilities into action to find a solution. For the engineers on the team who don't feel this way, it is often because they are not given the space to shine and they don't find these situations enjoyable.

Situations that call for open problem-solving, which includes brainstorming sessions, should be operated using a set of rules. This makes it possible for any group session to "have the same energy" even if some of the usual people are missing or there are new people present. It also makes it possible for sessions to get back on track quickly when the rules are violated because everyone can call out a rule and have the team help adjust the energy of the session.

Here are some starting rules for group engineering sessions. Each engineering team should review them together and make their own version. It can be an excellent first group engineering session in which the rules support the fine-tuning of the rules.

• Follow the rules of improv comedy - the answer is always "yes, and..."
• Respond with questions instead of judgments until you fully understand the idea being brought to the group
• Let every person naturally finish speaking before responding (just because ideas have been aired does not mean the group is going in that direction all of a sudden)
• Acknowledge time pressure if it cannot be avoided, and gently remind team members to "keep it tight" while still following the rules
• Reduce the number of people in the group engineering session in favor of taking more time or holding additional sessions (the sacrifice is having fewer engineers give their perspective but this is a very good way to work with scarce resources such as time)
• The improv answer of "yes" doesn't have to be an actual "yes" but can simply be holding space for an idea and listening genuinely
• Remember that some of the most innovative solutions can come from the least immediately attractive ideas - all perspectives are additive

Code review

One of the best ways to spread good engineering practices throughout the team is to perform code reviews. Not all code has to be reviewed all the time. Any amount of properly structured code review practice is a benefit to the team over time.

A properly structured code review practice has rules that are documented and agreed upon. Anyone should be able to perform a worthwhile code review after being trained on the rules and shown some good examples.

Strong QA

The best engineering teams have the best QA teams working alongside them. Strong QA isn't harsh QA. It is collaborative when designing testing procedures. It is authoritative when executing planned tests. It is suggestive and advisory when executing unplanned tests.

Work schedules, support duties, and being on call

Remote teams are common now. And working across time zones and geographies can be very challenging. Each team member is responsible for defining the working hours that are acceptable for them. Every engineer should make it clear to the rest of the team when they are available and when they are not available.

It is difficult for individual engineers to defend their "end of day" when an issue is in progress or when team members need their contribution. To the greatest extent feasible, team members should support each other's start and end times by actively acknowledging and occasionally defending them to show the boundaries are seen and understood. Nobody wants to be the one in a group to "duck out" when everyone else is still working. Every team member should try their best to push a team member who is "timing out" to a conclusion of their contribution and encourage them to close their work day. This makes sustainability a team effort instead of an individual struggle.

Structure and process save lives... specifically the non-work lives of the team members. The more structured things become, the more likely it is that every person will achieve the same quality of results. And when everyone delivers similar quality, then everyone is free to enjoy their time off when they are not on call or not working.

Spread unpleasant or repetitive or disruptive things across the whole team. One of the most common things is coverage for support and being on call for system outages. Until everyone knows how to cover it and feels the pain, the team won't reach an optimal solution. Make support coverage into the common enemy of the whole team. It will get resolved faster with more permanence.

Lack of preparation for handling time zones, work schedules, and being on call will result in the loss of team members over time.

The positive results of automatic assumptions

It is generally a bad idea to make assumptions and apply them automatically to situations. But that isn't true for certain assumptions. Positive assumptions can lead to new behaviors that support a sustainable team culture. If every team member makes the following assumptions and applies them preemptively before interactions with others, the culture should strengthen. If a team member does not feel that they can do this, then a breakdown in the team culture is already present.

• I assume that everyone has the right incentives and may sometimes just need some help with their approach
• I assume that everyone on my team will be genuinely interested in learning my personal preferences
• I believe that positive change in the team is not only possible, but that it is the default path
• I assume that if I say what is on my mind boldly but with kindness and patience, I will be heard and accepted even if someone does not agree with my perspective
• I assume that when I feel something isn't right about the team culture, I am noticing something real and worth expressing
• I assume that when someone has feedback for me or challenges my perspective, they are trying to be helpful and I should fully listen to their contribution

The inevitable loss of the oracle

Most engineers end up becoming the "oracle" for one topic or another. Or perhaps a system, application or process becomes their sole responsibility. When this goes unchecked, it is disastrous. The very reason we all rely on that engineer is because they know what to do... and chances are pretty good that they will want to leave the situation in which they have become an oracle who gets "pinged" constantly.

Most teams do not want for this to happen. So how does it always end up happening? Here are a couple of contributing factors:

• No single colleague or team member has the understanding of how frequently the engineer is being asked to help or asked to weigh in.
• Without a belief that team members will take matters into their own hands, the engineer may stop trying to get the weight off their shoulders and resign themselves to being an oracle.
• Every request is small and usually quick to handle, so the engineer doesn't realize they are trapped under 1,000,000 pebbles until they are already trapped.
• There is no time or place or person for the engineer to lean on for expressing their situation and getting change enacted so they just keep their head down.

Engineers build replacements of themselves

Every engineer wants to solve new problems. One of the best ways to do that is to transform their knowledge into self-service tools or documentation or cheat sheets or program code. The highest scale of problem-solving can be achieved by turning one's own brain into these types of tool sets and letting people use them in a do-it-yourself fashion.

If engineers take the time to "create themselves" in the form of materials and tools, the team and those outside of the engineering team must take advantage of those tools, or the motivation to make them will die out.

It takes a bit of effort for colleagues to learn how to use documentation and tools, but it must be part of the team and company culture. Without this effort, the result is that people take the "easy road" and simply rely on the engineer in perpetuity. If necessary, implement a tools and materials training program, and hold everyone accountable for finishing the training and using what engineers make. Those engineers are trying to implement organizational learning, which is the only way a company can scale while retaining quality and healthy culture.

Unified front backed by a brain trust

A well-operated team of talented engineers should be able to present a truly unified front. Decisions that have been made should either be supported or at least passively accepted by every team member. Each team member should refer back to the team when they find themselves in a discussion with an outside party and they do not know for sure how to handle requests for schedule changes, etc.

The backing of the unified front is a "brain trust". The wisdom of the team can only emerge when trusted working relationships have solidified.

Cheat sheet for engineering leadership

It can be difficult to get started with structured engineering team culture. Lead engineers have the responsibility of making sure the culture structure gets off the ground and stays in the air long enough to stabilize. Try the following ready-to-use activities to set the tone and open the team to a collaborative environment. If it's working, the team should begin to contribute.

At first the team members will most likely contribute concerns and grievances. This is good. If the culture structure is still working, these will transform into suggestions and ideas. It should feel like a natural close to the first phase of culture building when every team member is far more in support of the co-created structure than they are dissatisfied with any particular aspect.

• A lead engineer always opens a group problem-solving discussion with the phrase "Ok, team. How do you all think we can solve this?" and then waits to provide their own ideas until everyone else who wants to contribute has finished.
• When a team member makes a good contribution, a lead engineer draws out the essence of the contribution by highlighting the technique or approach that was used. Then they explore and discuss the approach with the team so everyone can see how they might apply it to their own domain.
• Gently but firmly defend the brainstorming rules in real time if there is a violation.
• Proudly and succinctly praise a team member for use of the brainstorming rules in real time.
• When a group problem-solving session is needed, the lead engineer can ask the colleague who has the problem (such as a product owner or business executive) to join the first portion of the discussion. Have each team member briefly explain one of the brainstorming rules to the non-engineering colleague. Then kick off the session.