Engineering management is a critical role for a team of engineers and programmers.  The responsibilities of the engineering manager are varied.  An engineering manager is responsible for the delivery of work, the quality of the work delivered, the personal needs for their team, and the professional development of the individuals within their organization.  All the while, the Manager uses their communication skills to report out progress, concerns, external roadblocks while keeping their strategic initiatives in mind.  Unfortunately and fortunately, many individuals that become Engineering Managers are first engineers themselves.  Often these folks are selected based on distinct pseudo factors that demonstrate that they can deliver work and that they show engagement.  The problem is there is a big difference between an individual that can effectively contribute as an individual by closing tickets and a professional that understands leadership.

This post aims to explore skills these professionals benefit from practicing to understand their new responsibilities as a leader.  This document aims to provide perspective for those that are seeking critical thinking that improves their team's performance.  We explore critical thinking around professional development and the importance of giving ownership away to a team of professional engineers.  We also explore how to implement ownership in meaningful ways and the role the Engineering Manager plays in creating opportunities and coaching Engineers towards their professional goals.

Myth: The Engineering manager is the best Engineer

If an Engineering Manager focuses on their programming skills with the rest of their team, they lose the opportunity to develop the skills and services their teams need.  Managers should have a fundamental understanding of the makings of the products and services their teams develop.  Engineering Managers should strike a balance to their learning, seeking technical vision while improving communication skills.  Often Engineers are given the responsibility or requested to accept the role of Engineering manager based on their performance as an individual contributor.  These candidates seem apparent, and they are measurably productive against the team's goals; they may have mentored one or two programmers; they have lead or owned projects before.  Perhaps this individual might be a subject matter expert or a go-to for on-boarding.

While these characteristics are excellent and should be encouraged, these traits are not the same ingredients that make a leader.  When a high performing Engineer of this nature is selected to manage a team, subconsciously, it is expected that by elevating the high performing engineer, those that report to them adopt the same behaviors.

I agree with the statement that Managers are first good individual contributors.  This statement makes sense, good individual contributors have a sense for what that means for their organization, what we then need to develop are the skills necessary to influence others to do the same.

Contrast American Football coaches

Great coaches have a vision of the subject matter they coach for but lack the level of refined or physical ability either due to genetics, interest, or measure of disability.  The football coach knows the rules and patterns of the sport, and the coach understands the mistakes that can happen and guides players on the team to understand what they are seeking to achieve together.  There are several limiting factors to the coach as well.  For instance, the coach cannot also be the best linebacker and center and QB.  Still, the coach needs to understand the roles of those individuals and help their professional athletes develop into the best versions of themselves in the context of a team.  If we stretch this metaphor out a bit further, consider the skills the MVP brings to the team and think about them as the coach.  While that professional operated well as an individual contributor, there are more skills that that professional athlete requires before they can be successful with leading a team.

The exceptional

By exceptional, we mean the Tony Stark of engineers.  Those of us that have found engineering skills come to us with ease while also discovering what it means to develop a healthy work environment that fosters good work and professional development.  While these people do exist, these are incredibly challenging achievements to accomplish for the majority.  It is up to the professional to determine what their most impactful skills that match their target responsibilities.

We stand to lose time and opportunity striving to become average at many things.

So what is it about engineering

The motivation to make our favorite Engineers the Engineering Managers is correct - our organizations wish more people performed the same way.  Picking our perceived most active Engineer for the manager role is not enough for what good leadership of modern-day engineering teams demands from their organizations.  Instead, work to synthesize the qualities that are working and identify individuals that can identify, understand, amplify, and develop the qualities necessary to build a team - one individual at a time.

What high performing engineers need

We may discuss how to develop Engineers at different points in their careers in future posts, but for now, think of how a Manager provides vision, ownership, and accountability.  The axis a Manager develops professional Engineers on is in the Engineer's abilities to make reasonable decisions autonomously while developing their ability to influence individuals to groups of engineering organizations.  Great talent should be scaled out, meaning, it is best used as an example for others to learn from not as a cannon to meet a deadline.  While many may push back on stretching outside of their comfort zone, Managers have to consider their team as a whole and think deeply about what unique talents are additive or subtractive from the overall culture of software development.

What modern Software Engineering teams need

What attracts sound engineering is typically interesting engineering problems paired with an environment that is flexible for making mistakes (learning) and understands the value of iteration (it does not have to be perfect).  While Software Engineers prioritize their exposure to learning and tackling challenging projects, a coach is necessary to help the Software Engineers understand how to solve problems as a team.   The Engineering Manager is a coach to help Engineers understand the broader role they may eventually play.

Teams of Engineers need a Manager that prioritizes their professional development.  The Engineering Manager needs to understand what their team's culture can withstand and connect their team's potential with the needs of its stakeholders.  The Engineering Manager has to be where their stakeholders are.   Present what is realistically possible for the betterment of the company and the team they represent.

Stakeholders and technical project planning

Engineering Managers need to have close involvement in how work comes to their team(s), for example:

• How many ways do requests for work come into the team of engineers?
• How does the team respond to outside requests? Is this acceptable? Do these requests add or remove from the team's morale, and how does it impact their ability to get real work into a done state?
• What is left unfinished?

The Engineering Manager has to keep an eye on the flow of tasks coming into their team.  The Engineering Manager is also encouraged to source meaningful work from the team of Engineers.  The process of seeking ideas from the team leads to real ownership, and there is nothing more powerful than a team that understands their role as owners of the products and services they develop (more on ownership later).  Engineering Managers need to turn unplanned work away as often as possible.  Hold their scrum masters and product folks accountable for respecting the engineering staff, and ensure good retrospective iteration is happening.

In Agile software development, it is recommended to exclude the Manager from the retrospective.  A team that autonomously engages in meaningful retrospectives is the goal.  Still, a critical part of the Managers job is to ensure that consistent quality communication is happening.  A Manager's goal should be to work their way out of the retrospective or find some means to measure the effectiveness.  Sometimes folks are not sure as to how to operate within a retrospective and could use some encouraging.

Communicate meaning

If the product owner, scrum master, and or the Manager have spent no time understanding a request, why should anyone expect that the engineering team would put as much care or effort into executing it?  Not providing care or meaning in making a request or developing a project goes exactly against the core of what motivates engineers to apply themselves.

Engineering Managers need to keep an eye on the requests that come into their team, that the requests provide context and meaning and that the work ultimately has some impact or value to the engineering teams' local or broader environment.

High performing engineering teams have ownership, means for developing themselves and vision.  The performance of engineering teams suffers under the lack of these attributes and rejects or resign under worse scenarios.  It is eventually leading to high potential folks disbanding from the organization leaving the team with programmers that cannot find employment elsewhere, ultimately rotting an organization of the depth or innovations that otherwise could have been possible.

Good Engineering Managers need to think about the challenges that are ahead of their team.   Engineering Managers build these stories and ask revealing questions to their stakeholders to understand more deeply what it is they look to achieve as the bigger story.  Give that story to the staff and yield control of the outcome to the team of engineers.

Protect Engineering hours

We have to practice rejecting work, and Engineering Managers have to practice rejecting the chatter that comes towards their team(s) while in the middle a cycle.  "No" sets the bar for the quality of communication that required before commitment.  Engineering Managers either set the standard or teach their teams how to set the standard for what a meaningful request is for themselves.

While the suggestion here is more natural for those that might be comfortable with conflict, it asks a lot of those that are not.  While we may discuss processes for managing outside requests in a future piece, for now, consider the benefits your team has with a manager that protects their time.

Time has meaning, protecting engineering hours is an uncommon practice.  Most of us treat our engineering teams as a service,

Just have the engineers look at this and get back to me.

People are just doing what they think is right, and we have to keep that in mind while working together.  While it is not the Engineering Managers' sole responsibility to make a good working culture happen, someone has to be accountable for it.

Personalized Coaching

Coach effectively using good listening, productive conversations, and follow up.  Engineering Managers have to prioritize their people first.  Schedule one on ones and tailor conversations to the needs of each individual.  Being present in a one on one takes practice, especially in technical environments where there are many priorities to balance.

Active coaches develop effective teams.

There are several great resources on developing coaching skills, one worth mentioning is "The Tao of Coaching," which describes the effectiveness of the asking versus telling models of coaching and conversation.

Coach Software Engineers for

Engineering Managers need to be ready for just about anything when it comes to working with many individuals.  Each Engineer is a different story, with a varied background, education, perspective of the world, and outlook on their contributions.  Earlier, we mentioned the axis in which Managers work with people to aid them in their professional development journey.  Behind every coaching session is a theme or target milestone to see the individual achieve.  If we could generalize for a moment, a good goal would be to develop teams of individuals who are respectable, motivated, fearless, and accountable.

High-level developmental philosophies

Being an assistant to someone's professional development can be daunting, so it is helpful to draw several principals out of the goal to help us focus.  Taking the previous characteristics, we may categorize high-level developmental philosophies.

Autonomy

First is an individual's ability to work autonomously within an organization.   People are sophisticated and capable of many things; coaching in the skills necessary to navigate foreign environments and establishing themselves in meaningful ways brings more perspective to how an organization does work.  People that understand autonomy provide invention and innovation.  Autonomous individuals are not afraid to provide meaningful feedback, and they make adjustments to their tact as they continue to understand their impact.

Craftsmanship

Some technology companies struggle to understand the quality of their software separate from the functions the software fulfills.  Engineers should understand what professional programming means and the role they play in owning how well something is made and maintained.  Engineering Managers can teach Engineering staff on how to connect the value of quality work with their stakeholders.   Engineers should also be encouraged to bargain for projects, whether it is an exploratory assignment or there is a bit of technical debt to overcome.  Managers play a role in helping a team along by giving them the space to do the work they deem necessary to be successful.  The Manager should be encouraging individuals to share their thoughts and provide consistent feedback to their colleagues and their Manager.  Craftsmanship is not optional; it is additive.  Craftsmanship saves time in ways that are not always obvious and often noticed as a side of the effect of adopting good programming principals.

Innovation

Stifling environments make innovation feel impossible.  Environments, where the term "investment" is used to describe how programmers spend their time.  It is obvious to think of engineering time as dollars and cents; unfortunately, that requires the one managing the investments to understand the value of every decision.  Innovations come in different ways, but typically the heart of innovation is adding perspective around a common pain point.  Innovation helps the days go by and the work simpler.  Innovation brings new thoughts into products and services and ideas that scratch an itch.  An Engineering Manager has to encourage their teams to find time to innovate on their work and coach individuals on how to identify an opportunity to make innovation happen.

The Engineering Manager helps to define means for measuring the effectiveness innovation has on their team and the productivity it creates and then connects these stories with stakeholders.  Sometimes, innovation reveals opportunities in places where no one was looking.

Influence

Influence is the ability to affect the development of people, their environment, and the products they create, in our case Software.  Some personality types have influence naturally, while others might need perspective and coaching to see how they can have an impact.   For instance, influence is not just the ability to speak publicly; influence can occur by sharing a piece of writing.  Influence is also occurring in places like code review and architecture discussions.   Vocal personalities may need coaching on their tone and positioning.  Quite or bashful types may need alternative means for having influence.

Good influence leads to better working environments and innovation, which leads to better quality and productive work.

Culture engineering

While not all Engineering cultures are the same, some common factors are appreciated.  For instance, engineering is a creative process, and good creative requires creative discussion and collaboration.  For individuals to be creative, open, and honest conversation is necessary.  Engineers should be comfortable with giving and receiving feedback regularly.

Engineers that develop ideas or patterns should be seeking feedback early and often.  It can become disheartening for many engineers to have change pushed upon them without having the opportunity to share their ideas as well.  Collaboration is an invitation to share ownership and coaching Engineers to work in this manner, fosters a healthy environment where ideas are celebrated and owned by a team.

Engineers should understand their quality and the process that invokes their philosophies.  An environment where writing unit tests is a separate task to the job is a sign that the Engineering staff does not yet understand their role as professionals.  A healthy group of Engineers naturally include their quality requirements into their estimations.  Stakeholders do not want to prioritize more than they have to, and it puts the ownership of the quality of work in the hands of an outside party that may not understand how to appreciate it.  We are not picking on stakeholders, but we have to understand that the world we live in and the work we do is fast-paced, and folks do whatever they can to keep the funds coming in to keep their companies moving forward.  Questions regarding throughput are the responsibility of the Engineering Manager.  The Engineering Manager has to talk about staffing directly with the organization while encouraging the safe and predictable practice of creating GOOD programs (not the best).

Ownership

Quite possibly, one of the most potent attributes a team of engineers can have is the ownership of the things they create.  While in product engineering, this opportunity is somewhat apparent, and the Engineering Manager may use these products as a consistent totem to build ownership around.  There are also Engineering environments that move resources around between projects quickly.   In these examples, the road to ownership is not always an obvious one, but getting teams to take ownership is achievable.   Engineering Managers set goals around ownership, provide opportunities for engineers to make decisions, and own the outcomes.  Managers encourage accountability and hold the line where a meaningful conversation is necessary for professional development.   Request ideas from the staff and use the asking model to guide their thinking into reasonable decisions that allow them to change their minds in the future.

It is in these moments that the Engineering Managers' technical skills can have a significant impact.  The Engineering Manager needs to think ahead of their team, and work back from an idea and provide thought-provoking questions for their teams to work out on their own.  The result might not be what the Manager would have decided, but what the Manager wants is not necessary because it is not the Managers to own.

Exploring where performance issues develop

Team performance is typically associated with their ability to complete their strategic objectives defined either by themselves or others.  The measure of a team's productivity is subjective when considering the individual making the statement.  The first step in identifying whether or not a team has a performance issue is to take measurements from the context of the team.  Establish a means for organizing and measuring the team's work.  Velocity, for instance, is an abstract value a team uses to communicate effort.  By using an abstract measurement like velocity and time boxing techniques - such as the sprint, problems with getting work over the line become apparent.  Being able to identify challenges with productivity provides a context for conversations and retrospective.

False positives arise when the people outside of the team measure the complexity of a piece of work.  Estimating the complexity of work outside the team's domain is doing both the stakeholder and the team a disservice.  Take the work to the team for open discussion for a clearer understanding of what is possible.  At the same time, talking about the goals begins to yield ownership of the outcome to the team - which sets expectations and creates motivation.

A driving culture

Driving cultures are also similar to a waterfall, but not as organized.  Some managers see it as their responsibility to take control of the decisions; they are responsible for the outcomes after all.  Typically this comes from a place of insecurity; I have been that Manager, afraid to let these seemingly important decisions go to the profession.

Driving cultures take creative control and ownership away from the teams that execute them.  Driving in this manner has adverse effects; for instance, a team forgets how to take ownership of work and expect for their Manager to tell them how to act.  The team is disengaged in design discussions and wait for their Manager to tell them what to do next.  The team requires the Manager to keep them organized, provide them with their team assignment, what work to do, and how to do it with what style and tools.

There is a classification of individuals that prefer driving cultures, and in some cases, make up the majority of a work force.  That does not mean that people cannot be encouraged to accept accountability and ownership, but they need the opportunity to do so.  Driven cultures tend to take the air out of the room for high performing individuals or teams.  Engineers are people first, and these days require a tactile association with the impact of their work.

It is a mistake to confuse authority with leadership.

Define principals

Principals are the foundation of the expected results of the output of an organization.  Good principals provide reference material to evaluate the actions of an organization while being flexible in implementation.  Principals give us both the framework and the flexibility we need to give ownership of execution to our colleagues.  While this document does not cover inclusion, understand the attributes of a strong leader includes the properties of every individual.

If possible, define the team's principals with the team.  Write them down and make sure everyone has access to these documents.  Add or remove principals as the team continues to evolve - good governance evolves with the self-governing group.

Principals are perfect for holding a team accountable for expectations.  For instance, if "Shipping Quality Software" is the principal of a team, the team has an opportunity to define what that means to them.  Allow the team to iterate on their implementation while the Manager seeks meaningful ways to track their progress and report back to the team on how effective they were.  A good Manager holds the team accountable to the promises they make for themselves and their stakeholders.

The Managers tech chops

Much like working with people, Managers can get away with looking at software in the same way.  This post is not an exercise in removing the technical know-how requirements from a leadership type person, but the technical skills are secondary and in several ways, directed differently.  For instance, and Engineering Manager should understand or be able to learn how to identify waste in the day to day work of their team(s).  Engineering Managers should carry a healthy perspective on code line management and collaboration.  Engineering Managers should be in a position to understand technical issues at a high level to ask tough questions about the impact ideas have.

Manager tip:  Listen to conversations in the environment and be honest with what you do not know.  Seek out introductory courses or "big picture" lectures on these topics.  Only dig deeper if you think a more in-depth understanding is required.

Summary

The impact an Engineering Manager has on a team of Engineers is immense, and Engineering skills are still relevant to the role but are secondary to the service a Manager provides.  Engineering Managers provide the vision of the types of products they are involved with while amplifying the skills of the people around them. Engineering Managers fill the cultural gaps in an organization in ways that would make an otherwise bleak experience exciting and fulfilling.  The work of the Manager has a long cycle, taking weeks, months, or years to see realized.  Managers need to be consistent and flexible learners that can adapt to many situations while forfeiting the glory to the skills and talent developing around them.

Take care of your teams, and your teams take care of you.

Credits

Cover Photo by Joel Filipe on Unsplash