Managing work from the front

Being a frontline manager is a hard job.  Those of us who transitioned from being engineers as part of a so-called promotion discovered that it was not a promotion at all, but a completely different job.  Some of the most difficult parts of this transition are understanding the perspectives of engineers without being an engineer anymore, and learning to be the person who represents the business.  These two challenges are represented most succinctly in managing the team backlog and in organizational alignment activities.

The backlog

Everyone in the organization should understand the needs of the business.  While the frontline manager may represent the business to the engineering team, they are not the only ones responsible for thinking that way.  Engineers are not paid to write code; engineers are paid to solve business needs.  We know from the State of DevOps Reportthat organizations that are better able to deliver software are “twice as likely to meet their organizational performance goals.”  Having this mindset of serving the needs of the business must be pervasive.  But what if the business has a lot of needs?  What if there is a lot of work to be done?  How do we know what to work on first?

For teams practicing agile software development, the answer can be found in the backlog.  The backlog is a task list of all the possible work that a team will commit to delivering for a given time period or rate of delivery.   Any ideas that we have for improving work go on the backlog.  Any tasks related to product development go on the backlog.  The outcomes from retrospectives, learning reviews, postmortems, all go on the backlog.  The backlog can be very, very long!  What can we do about that?

Give up

No, “give up” doesn’t mean you should throw up your hands in defeat and walk away. It means you and your team should give up on the idea that you will get every item in the backlog carried through to completion.   Every idea an engineer has, every project that is started, will all have items in the backlog.  But priorities change, technologies change, initiatives change or evolve.  Unless we have unlimited resources and/or unlimited time, we will never be able to complete all the items in the backlog.  So your first step is to give up on completing everything, and instead focus on the most important items for the business and for the team, which should generally be one and the same.

Prioritize

Just as “no one ever got fired for buying IBM,” no one is ever going to get fired for always working on the things that are most important for the business.  It is often the job of the frontline manager to do the exercise of prioritizing the backlog.  This means talking to your boss, finding out about the business needs, and prioritizing the work in the backlog accordingly.  This means that engineers never need to ask what they should work on next.  The answer is always there, transparently for all to see, whether they are engineers on one of your teams, or your boss.  This focus on transparency is a fundamental part of agile development. 

As we discussed in Make it a Spreadsheet Problem, when we’re always working on the most important tasks, if the business needs to get more work done, then our spreadsheet can demonstrate whether we need to hire more resources or change something about the nature of the work.

What is prioritized can change for many reasons.  Dr. Mik Kersten in Project to Product talks about the four different kinds of work:

• Feature
• Defect
• Risk
• Debt

If the business is preparing for a major launch, perhaps we will prioritize features more.  If the business is preparing for a major audit or certification, perhaps we will prioritize risk.  If we’ve been having stability problems with the website, perhaps we will prioritize defects and debt.  The priorities of the business can change from week to week, or year to year, but it’s the responsibility of the frontline manager to ensure that their team is aligned with the business.

Negotiate

While it would be advantageous for frontline managers to know everything that is happening below as well as above them in the organization, we are human.  We have limits, like Dunbar’s number, that make this essentially impossible.  If, as the information iceberg theory states, that team leaders only see 74% of problems, there is going to be a lot of information that is missing about the most valuable work if we only rely on information coming from above.

That’s why it’s essential in planning meetings with the team that the manager listen, discuss, and negotiate what the true prioritized backlog should look like.  That is not to say that leaders should not show up to these meetings having done all the hard work of examining the items, checking with other leaders, etc.  That is a requirement in order to come to the meeting prepared with the information necessary to answer questions and keep the meetings on track, as engineers do not like to spend time in meetings.  Just as in agile chickens and pigs, the leader needs to approach these meetings with flexibility, as only the “pigs” know the true state of the system.

Alignment

We’ve discussed how important it is for both engineers and leadership to understand the needs of the business and make decisions accordingly.  But how can we create an environment where this understanding is a normal part of doing business?

Many companies have some form of alignment activity.  These have many different names like OKR, V2MOM, or MBO, but their purpose is to drive this alignment throughout the company. For example, when I worked at Salesforce, we had V2MOM (Vision, Values, Methods, Obstacles and Measures).  At the start of each alignment period, Marc Benioff would publish his V2MOM and then leadership below him would publish their own, demonstrating how their methods were in service of Benioff’s vision.  Then the folks below them, then below, etc.  By the time the V2MOM process had reached the lowest-level staff engineer, there was evidence from the top on down demonstrating how the entire company had their vision and methods aligned in such a way to best serve the direction of the company.

Regardless of which method you choose, or the size of your company, this ability to create alignment allows for leadership to set the direction and empowers each employee to use their unique perspective based on their position of observation to create an organization moving forward in unison.

Therefore, it is the job of the frontline manager to work with their staff on these initiatives.  Not only to publish their own goals, but to work with team members to ensure that they are also aligned, and also understand the priorities, so that they can make the best decisions possible with regard to their own goals for that alignment period.

Conclusion

Being a frontline manager is a challenging role.  Not only are they often in their first leadership position, but they are in a role close to where the actual work is done.  Being able to juggle competing priorities, interruptions, course corrections, new initiatives, etc., can be difficult without a clear direction from the company.   If these managers focus on always delivering the most important needs of the business, they will always be doing the right things and will have a better chance to succeed in their role.