Agile and the Engineering Manager Identity Crisis

When organizations make the move from waterfall or ad hoc approaches to Agile, they must make sure to communicate clearly what this means, what will be changing, and how it will improve value delivery to customers, stakeholders, and executives.?The way these important external partners are invited in to forge more collaborative ways of working together are highly varied, but everyone agrees that they are critical to future success.

However, there is a critical role that straddles the boundaries of Agile teams and must master profound changes to its job responsibilities that is often painfully neglected: the Engineering Manager.?Many of their traditional responsibilities now belong to the team, some of whom likely report to other leaders.??They frequently are not provided with the impressive list of new responsibilities they must shoulder, the coaching they need to master new skills, or guidance on how their performance will be measured as a people leader in an Agile world.?Add to this, the mythology of dabblers and purists that people leaders are no longer needed once an organization moves to Agile and it is easy to see why many Engineering Managers are left feeling lost and alone.

Who Am I?

There are several common and unfortunate role identities that Engineering Managers and their leadership often assert in response to this confusion:

“The buck stops with me”

Engineering Managers assert that devs, architects, product owners, and scrum masters might consider themselves the “pigs”* on the team with self-organizing authority, but EMs can override any technology choice, vendor selection, feature prioritization, customer communication, technical debt mandate, dev assignment, DevOps practice, etc. if they deem it “good for the business”.?The rationale is that they will be held accountable for the success of the products being delivered by the teams, so they must have veto power over what the team does.

Consequences: This is the most destructive identity to choose.?It subverts everything that makes Agile a velocity-driving, quality-enhancing, customer-satisfying mechanism.?Team members will constantly second-guess their choices and try to make sure they don’t trigger the veto power of the overlord.?Customers, stakeholders, and executives will shift back and forth between the EM and the product owner trying to figure out who is calling the shots and, in the worst case, will consciously play them against each other to get servicing those outside interests always put at the top of the list.

“I’m just another member of the team”

Engineering Managers assert that they are a “pig” on the team, not a “chicken”*, and that they should point user stories, vote on admitting user stories into sprints, take a leading role in sprint demos, and participate actively in retrospectives.

Consequences:?This is often the first role in disguise, though the EM may genuinely feel they are giving the team more power by just getting the same vote weight as everyone else.?Unfortunately, when the person who is going to deliver your performance reviews asserts a position in a ceremony, you are more likely to vote with them to improve their impression of you.

“I’m the product architect”

Engineering Managers are frequently business or technical domain experts, and they assert that they are the best able to design the right solution for the team to subsequently execute on.?They warn that waiting for the team members to master the domains will create delivery delays and the devs on the team will be glad to have someone to take care of the “non-technical” domain stuff they don’t understand.

Consequences: This has some reasonable-sounding assertions going for it, but it is still a subtle variant of the first role.?Agile demands that all team members focus on outcome values as the guiding principle of their “whys”.?Understanding the domains involved is critical for high-functioning teams.?It is the basis of the conversation between the product owner, the architects, and developers on the team.?Exercising the discovery and debate methods to determine why something needs to be done, how it is best accomplished, and whether it is working is a critical feedback loop to strengthen team effectiveness.?If one person asserts ownership over that process, the team never learns how to do it for themselves.?(As an aside, this is just as true if a non-people-leader “Product Architect” claims ownership over all design choices.?Good architects help frame the research, analysis, and design problems and guide the team in it’s search for the answers together.)

“I’ll take care of efficient team resource administration”

Engineering Managers assess strengths and weaknesses of team members.?They capture vacation and training schedules.?They put together available team hours.?The decide which resources are most appropriate for which user stories and deliver efficient team resource utilization.

Consequences: This is one of the more insidious decisions.?It has the appearance of desirable servant leadership by having the boss free the team from boring statistics and staff allocations.?The problem is that it weakens the team’s accountability for how it chooses to tackle problems.?If the boss administrator doesn’t interpret the signs of a training gap, a product owner/technologist communications failure, a loss of motivation, etc. then the team doesn’t take action as they’ve ceded that responsibility to the boss.?Worse, the metrics of “efficiency” often presume static team capabilities, while Agile calls for constant improvement and changes of methods to improve team flow and output.?Scrum masters (or other Agile process guides) are tasked with helping the teams identify when they’ve?become stagnant and shake things up in new ways.?If the team’s way of working is proscribed by an efficiency process managed by the Engineering Manager, then the wisdom of crowds is lost.

* If you’re not familiar with the “chickens & pigs” metaphor in Scrum, a common Agile methodology, a good overview can be found here.

A Little of This, A Little of That

Sometimes Engineering Managers take on some combination of many or all these identities in various proportions.

All these assumed identities reflect the lack of quality coaching on the role of people leaders in Agile that I described earlier.?More worryingly, they express a profound lack of trust in team self-organization and bottom-up continuous improvement.?Teams always sense this, and it negatively impacts their belief that they are actually the owners of their ways of working and responsible for driving improvements in those techniques.

Who Should I Be?

Engineering Managers are frequently told about some or all the role identities above and that they are undesirable.?They are often told that they are not members of the product teams, but outsiders with some “other” thing to do.

In the absence of training on the essential and positive responsibilities they should take up in an Agile organization, it is easy to understand the common fear that Engineering Managers are to never say a word about what teams their reports are on are doing and just take care of hiring, budgeting, and performance reviews.?This can often spawn concerns over job security or anger that their expertise is not valued.

Fortunately, there is a substantial list of critical tasks necessary for Agile team success that Engineering Managers must deliver to create product teams that deliver legendary outcomes:

Agile Coaching

It is frequently believed that developers, architects, and other technologists today arrive at the workplace already knowing what Agile principles are, value them highly, and are skilled at executing using them.?Even for senior technologists who have had many prior jobs where agile was purportedly in use, agile mastery is frequently very weak.?Most have worked in cultures that “do agile”, but never learned to “be agile”.?The most frequent cause of this is leaderships that have been unable to let go of some or all of the negative identity roles I outline above.?Technologists know that “Agile” is how organizations are expected to create modern software but are often quite cynical about whether management is really serious about it.

The only people in an organization that can make it real under such circumstances are the people leaders.?They must ally with the scrum masters to educate their reports on what Agile is and the foundational value that is placed upon it by leadership.?If the task of Agile education is left solely to the scrum master or what folks can find for themselves, then it will almost certainly fail.?If the people leader values Agile highly enough to make educating their reports on it a priority, then it creates a powerful incentive to walk the walk for real.

Celebrating Continuous Improvement

Agile asks that team members actively engage during team ceremonies.?Is asks that technologists challenge their product owners as to the value outcomes offered by user stories.?It asks that team members take up user stories that may not be in areas where they are currently technically strong.?It asks that they hold themselves and their team colleagues accountable to the agreed teams ways of working.?It asks that they identify challenges to team functioning in retrospectives without blame and contribute proposals for how to improve things.?It asks that they master new business and technical domains to increase the fungibility of the team.

Engineering Managers who actively recognize team members who report to them for delivering on these principles improves commitment to continuous improvement.?Product owners and external stakeholders also more easily perceive the relationship between healthy team culture and high velocity, high quality, high value outcomes when the people leader is making it clear what they celebrate as it happens and at opportunities for recognition throughout the year.

Rewarding Agile Excellence

Teams that release superior products get morale boosts from positive customer, stakeholder, and executive reactions.?However, those reactions are communicated at a relatively low frequency.?Continuous improvement of agile practice is a leading indicator of superior results.

Recognizing team members who model positive Agile behaviors is critically important but backing that up with material rewards seals the deal.?Engineering Managers should structure performance goals around Agile best practices (interleaved with Product Mindset and DevOps ones).?Bonuses, stretch assignments, merit increases, and executive exposure should be clearly tied to improving in these areas.?The classic mantra “What is measured is what is done” most certainly applies here.

Reinforcing Roles and Responsibilities

Agile methodologies typically divide participants into Engineering, Product, and Team Process groups.?There are often further subdivisions of architecture, development, UX, product ownership, business analysis, scrum master, planning leads, etc.?I’ve stressed the need to call out Engineering Managers as having a critical collection of responsibilities to empower high-functioning teams.?The specific ways in which teams define their ways of working can be highly varied, but clearly identifying who is responsible for what and championing bottom-up collaboration across domains of expertise instead of command and control from the top is universal in Agile.

Engineering Managers who are confident in the importance of the distinct role they play in making their organization successful don’t feel in the least disempowered when they redirect folks asking them to make decisions that our outside of their area of responsibility to the colleagues that are.?Team members need to know that the responsibility and authority for things is well understood and mutually agreed to.?Engineering Managers who consistently honor this as servant leaders message to team members and external parties that what is said is what is done.?This avoids conflict and greatly improves efficiency.

Providing Tools, Training, and Resources

At first glance, this responsibility is shared between Agile and other organizational methodologies.?The difference in the Agile setting is that it is driven by retrospectives (or other Agile iteration review types).?The team is encouraged to continuously identify what is blocking their progress, both in daily standups and in retrospectives.

Engineering Managers should be using retrospectives as a primary source of what they need to secure for their reports on each team when they interact with the layers of management above them.?Most retrospective decisions can be acted upon by the team members themselves without help from people leaders.?However, when something requires resources from the outside, this is an opportunity for the Engineering Manager to reinforce the retrospective as a ceremony that actually delivers the goods needed for continuous improvement.

Obviously enough, EMs get lots of great feedback during one-one-ones and that should be the source of many decisions as well. However, the team is an animal unto itself and needs thoughtful care and feeding as also.

Rare Cases of the “Bad” Stuff

Sometimes a business imperative cannot be fended off and the Engineering Manager may have to impose something on his reports.?This could mean stealing resources from one team and giving them to another or letting folks go.?That said, product feature priorities, release rollbacks, ceremony schedule changes, etc. are things that belong to other members of the team and an Engineering Manager should never be doing those things.

An Engineering Manager with deep business and technical domain knowledge is incredibly valuable.?They should share that knowledge as much as they can.?Frequently, teams will fervently seek it.?However, the people leader must always understand that the team owns how often they wish to hear EM advice and always makes the decisions about how that information will be used.

The EM’s bosses or other interested executives may demand statistics about how the team is performing.?The EM can certainly take the lead at facilitating that visibility into how teams their folks are on are performing, but it must not be perverted into a control mechanism that subverts Agile team self-organization.

Your Mileage My Vary, But...

As with all Agile processes, when teams have a generative culture and are high functioning, the tolerance for exceptions to the EM being hands-off in many areas may grow.?However, this should never be interpreted as an invitation to institutionalize top-down, command and control decision-making and call it “Agile” because “the team said it was OK”.

Embrace the New

I hope I have helped folks better understand the poorly understood, but essential, role that Engineering Managers need to play to drive a continuously improving adoption of Agile best practices in the organizations they serve.?If organizations want to be successful in their Agile journeys, they must actively coach their engineering people leaders and reward their successful handling of these new responsibilities.?Instead of being a source of angst for Engineering Managers, Agile opens an exciting new vista for career growth in people leadership.

Until next time.