This chapter covers

• Setting team goals
• Setting up a work intake system for your team
• Handling unplanned work
• Deciding what to work on

The power of an organization is centered on the idea of a group of people coming together to complete a task that would be impossible to complete as individuals. Organizations have the ability to direct a group of people toward a single objective, and they use priorities to do this. Creating a skyscraper would be incredibly difficult without a group of people, skills, and disciplines coalescing around a set of prioritized goals.

But many teams tend to not coalesce around the overall goal, but instead around their specific slice of that goal. That slice gets prioritized above the overall team goal. As the slices become more specific, so do the ways in which you measure them. Before long, you have a bunch of different means of measuring the performance of the teams, and those means may incentivize behavior that detracts from the overall goal. This is the too many yardsticks antipattern.

Goal setting and the process of prioritization are extremely important in DevOps cultures because they set the groundwork for putting energy behind work that has traditionally been neglected. The reason you release 30 features a quarter but can’t find time to patch your servers is that one task has been prioritized and the other has not. Prioritization isn’t just saying yes to a task, but also saying no to another. The time you have is finite, so simply saying something is important isn’t enough. At some point, you have to say that something is more important than something else. This can be difficult and a bit painful, but the reality is, you’re implicitly making these choices by not making the choice.

But where do priorities come from? They come from the goals and objectives you’ve set for yourself based on the goals and objectives of your team, department, and organization. Even though you have a to-do item to upgrade that OpenSSL library your program uses, it never gets done because you haven’t prioritized it. You haven’t prioritized it because it probably isn’t part of a goal or objective that you’re being measured by. Instead, you let other items shove their way into the front of your consciousness; because of the way tasks are packaged and presented, you accept that one task is more important than the others. This chapter aims to look at that process and force you to evaluate a task for its objective importance.

12.1 Tiers of goals

Goals are typically tiered, with one set of goals flowing into the next tier of goals. The organization has a set of goals for the year, whether it be revenue growth, the launch of a new product, or retaining customers. Knowing the organizational goals is necessary to create the next level of priorities, which are departmental.

Each department needs a set of goals that support the organization’s goals. This gets repeated right down to the individual, whose goals are influenced by their department’s goals, which in turn are influence by the organization’s goals. This relationship is depicted in figure 12.1, noting the cascading nature of goals.

Figure 12.1 Goals cascade from the top of the organization.

Knowing your goals and how they factor into the larger set of organizational goals is, for many people, an influencer of job satisfaction. When your work is off on an island and nobody appreciates what you do or why you do it, you can become disconnected from the rest of the organization. As everyone marches on toward goals that get talked about in company-wide meetings, you’re on the sidelines, wondering why you’re doing what you’re doing and if it matters at all. Understanding the organization’s goals and tying your work to one of those can go a long way to helping fight that feeling.

12.1.1 Organizational goals

Unless you’re on the executive leadership team at your company, your organizational priorities are largely beyond your control. Because the executive team is many steps removed from the tactical details of how things get done, organizational goals are high-level and strategic in nature.

Mapping your tactical, engineering-specific work to these higher-level objectives can be difficult. It can require some outside-the-box thinking. Often this work is done for you by the technology senior leadership team, as they map the departmental goals to the organization’s goals. Some examples of organizational goals might be as follows:

• Reduce operational spending by 15%.

• Achieve 20% year-over-year growth in subscribers.

• Increase the spending of existing customers by 10%.

From a technology standpoint, mapping your work to these goals might not be immediately intuitive, because your work is often not a straight line to the goal. For the first goal of reducing operational spending, you might be able to reduce the number of servers you’re using in the infrastructure, thereby reducing your operating expense for the platform. Maybe you can identify some low-hanging automation that you can develop to assist other departments in their tasks. Achieving year-over-year growth in subscribers could be supported by tackling key features that some subscribers want, but you haven’t had much luck getting into the work queue. The new features are delivered to the product team, which goes to the sales team, and the sales team dangles these new features as enticements for potential customers who have been on the fence. The same thing goes with increasing the spending of existing customers.

The point is that when you start looking at organizational goals, you can begin to look differently at your pile of work. Your team’s to-do list can quickly become filtered through the lens of the organization’s goals. But this is just one of the levels of goals. Your department will most likely have a specific set of goals that leadership wants that focuses on and prioritizes the things that you should be working on.

12.1.2 Departmental goals

Departmental goals are going to be a little closer to your immediate day-to-day work because they’re created with an engineering context in mind by the leadership team. Mapping your team’s or even your personal goals should be a pretty straightforward task.

Depending on your level in the organization, you may be involved with setting department goals. If you are, you should consider how the department goals roll into the larger work of the organizational goals. As mentioned previously, not all technology work is a straight line to an organizational goal. But being able to connect the path to the goal still has value for seeing how work is connected. This sense of connectedness for work can be a key factor in team members’ job satisfaction. Table 12.1 shows how departmental goals can be defined and mapped to organizational goals.

Table 12.1 Departmental goals mapped to organizational goals

Departmental goals	Organizational goals
Launch 2.0 version of sales software	Achieve 20% YOY growth of subscribers
Rearchitect data pipeline process	Increase existing customer spending by 10%
Improve billing process performance	Reduce operational spending by 15%

Knowing that their work matters and affects people outside the organization can be an enormous team motivator.

12.1.3 Team goals

The team goals focus on what the individual teams inside a department will be working on. Just as departmental goals link up to organizational goals, team goals should map to departmental goals. This should be easier than mapping directly to organizational goals, because the department’s goals should have been created through the lens of technology. In fact, when you look at the team goals, they are versions of the departmental goals, but with more specificity.

Team goals are more tactical versions of departmental goals. Team goals offer the specific ways that departmental goals will be achieved. “Improve billing performance” is a strategic goal set at the department level that doesn’t lay out anything resembling a plan for how to achieve it. Team goals help provide the high-level strokes of how the department is going to execute on improving billing performance.

The goal might not be a single team effort, either. The goals might spread across multiple teams. Development teams might focus on different parts of the code that are known to be particularly slow, while operations teams might focus on tuning the existing hardware to squeeze out more performance. Table 12.2 gives a few examples of how team goals map to departmental and organizational goals.

Table 12.2 Multiple teams focused on a departmental goal

Team	Team goals	Departmental goals	Organizational goals
Dev team #1	Rewrite calculations billing module	Improve billing process performance	Reduce operational spending by 15%
Dev team #2	Move billing to a queue-based, multithreaded process	Improve billing process performance	Reduce operational spending by 15%
Operations team	Tune billing database server to match workload type	Improve billing process performance	Reduce operational spending by 15%

With the team goals mapped out, you can get a sense of how an individual contributor can not only have a clear understanding of what to work on, but also how it fits into the larger organizational goals. Now you’re all rowing in the same direction.

12.1.4 Getting the goals

If you’re not part of the leadership team, you might be confused about what the organizational and team goals are. Your company may not have strong communication around goal setting and planning. I assure you, though, that every company has some understanding of the organizational goals.

They may change and shift frequently, but someone at the senior level knows what they want the company to focus on. This information may just be bottled up and failing to trickle through the organization. The easiest way to solve this is simple--just ask!

Asking for goals seems overly simple, but the reason it works is straightforward: goals are one of the core tasks of any management team. Asking a manager to identify the goals for you or your team is a reasonable request. Even if your direct manager doesn’t know, they certainly won’t respond with, “I don’t know, and I don’t plan to find out.” That’s a completely unreasonable response. If you do get that response, a gentle prompt of, “Well, maybe you can find out for me?” should be enough to set the wheels in motion. If your company has any sort of feedback that goes back to the senior leadership team, it would be invaluable for them to know that the company’s objectives and goals are not being filtered down to the individual contributors of the organization.

Some of you might be thinking of how horrible your boss is and how they’ll never give you an answer on goals. For that I’d say, ask someone else’s boss. The beauty of organizational goals is that they’re universal for the company! I doubt that any of you risk being terminated for trying to identify the most important things to work on.

That’s essentially what you’re doing when you’re asking for goals. You’re looking to get an understanding of the most important tasks that you can be working on for the company. If you’re extremely paranoid about your boss, you can phrase the question to other leaders as a way of understanding how your work connects to the larger work of the organization. Understanding how your work touches, impacts, and enhances other teams is an innocent question that will provide you with tons of additional context from other leaders.

If you’re still having trouble, you could consider getting in touch with your culture chief. As described in chapter 11, a culture chief is typically well connected and respected throughout the organization. Chances are, they can help you understand how your work supports the larger goals of the organization.

With the goals properly defined, you can begin to look critically at the items that you and your team have been assigned to work on and be much more conscious about the way you spend your time.

12.2 Consciousness around what you work on

You have a countless number of demands on your time. Teams consistently have more work to do than they have the capacity to perform. To keep from being pulled in multiple directions, you need to be able to defend your choice of what you’re currently working on. Your goals and priorities are the shield you use to defend your current work. Any task or item that comes into your team’s work queue must be able to pierce that shield to get your current attention. Your shield is strongest when you have a clear understanding of goals and your tasks related to those goals.

Being conscious of what you work on is rooted in this idea of commitments. You make commitments to coworkers and to your boss. Your department makes commitments to the organization, and so it goes up the chain. When it comes to individuals, commitments are the currency of credibility. When someone commits to something, you instantly do a calculation on that person’s credibility. Do they frequently deliver when they say they will? Or is this person or department consistently underestimating the time it will take to complete a task? This credibility is heavily determined by how well you manage the number of commitments that you make and their impact on each other. Once a commitment is made, it needs to be delivered or renegotiated. Once you understand that, you can begin to say yes to the important work, and no to the unimportant.

12.2.1 Priority, urgency, and importance

Many people confuse importance and priority. A priority takes precedence over other actions. But if a priority takes precedence over other actions, how can there possibly ever be multiple priorities? It can be difficult to reason about, especially as an individual contributor who is being handed multiple tasks, all of which are deemed a priority.

It is my assertion, though, that an individual can have only a single priority at a given time. That doesn’t mean you don’t have other important items in your to-do list, but only one of them is the most important thing to do. If you have an important board meeting, but right before it starts you find out a loved one was involved in a horrible accident, do you juggle multiple priorities? No, you must choose one as being more important than the other.

If you can have only one priority, you still need a mechanism for being able to categorize other work. Incoming work has two other characteristics: urgency and importance.

Urgency defines how soon a task must be performed. It might have an external deadline or may be needed as input into another process that’s stuck or blocked. Importance relates to the significance or value of the work. A piece of work that makes life easier for a developer’s workflow may be considered less important than a feature change that impacts thousands of customers. Neither item may be urgent, but one has more importance than the other.

DEFINITION Importance of a task is its relative value or significance to the organization. Urgency is related to the time horizon in which a task needs to be completed. Urgency requires an objective deadline, not just the requester’s preferences.

It’s important to recognize that both urgency and importance are tainted by the context in which they’re looked at. The requester will look at a task as important based on how it relates to other work that they need to perform. The implementer of the request may not have that same context and view the request differently. This is another reason why it’s important for you to understand the goals of your team, department, and organization. The goals provide an objective lens through which to view these requests.

When a task given to you is the priority, it should become the default that you turn to when you have time to perform work. All other commitments should be looked at as it relates to the priority that you’ve been given. When you look at any other time commitments, the commitments should be examined through the lens of the priority. If the new commitment can impact your priority, your options are to defer the new work, attempt to elevate the new work as your priority, or renegotiate your existing priority’s deadline. Consider the following:

• Will this commitment impact your ability to deliver the priority on time?

• Does this new commitment have the potential to become your new priority?

• Is this new commitment important enough that you should renegotiate your priority’s deadline commitment?

These questions will help you assess whether you can take on this new time commitment--whether it’s a meeting, a new project, or even just a new smaller task. If the task isn’t going to impact your time commitment to your priority, accepting the new commitment is OK. If it will impact your ability to deliver on your priority commitment, you have to evaluate the relative importance and urgency of this new task. Is it important enough to become my new priority? This is a decision that you’ll probably want to make in tandem with your manager or supervisor.

It is possible (and common) that a new, unexpected item that comes up is important enough to become the new priority for you. Evaluate it with your manager and decide. If it’s not important enough to become the new priority, maybe it’s important enough for you to renegotiate your deadline for your existing priority. Again, you’ll want to have this conversation with your manager.

But enter the conversation understanding how much time this is going to add to the delivery of the priority. You can’t decide on delaying a priority if you don’t know how long the delay is going to be. If you absolutely cannot measure the delay, you’ll want to make sure that you tell your manager. The uncertainty of the delay may impact the decision on whether to accept this new time commitment. If you cannot successfully navigate any of these options, you should reject the new time commitment.

For some of you, the idea of refusing work may sound alien. But the truth is, you and your team are already refusing work. The difference is, you tell whoever is requesting the work that you’ll do it, but consistently prioritize other activities over it. If you look in any work queue, you’ll find work requests that have been sitting for quite some time and have no realistic chance of getting prioritized.

Not only does this work act as an attention thief, but ignoring it is also incredibly unprofessional to the requestor. The person who requested the work probably has some hopes, dreams, or plans around what they’ll do when this ticket is finally completed. But if this ticket has no hopes of every getting prioritized, you’re robbing the requestor of the ability to properly plan for that reality. They could be making alternate arrangements or gaining more executive support for their tasks. Instead, they’re waiting on you with the misguided belief that their work is happening soon.

Pro tip Refusing a task is more professional than accepting it and never doing it.

12.2.2 The Eisenhower decision matrix

In the previous section, I discussed an evaluation mechanism for interpreting whether a task should be accepted. This process is an informal version of the Eisenhower matrix. The Eisenhower decision matrix is a tool that was used by Dwight Eisenhower, the 34th president of the United States. Eisenhower was known as a shrewd decision-maker who often leveraged this tool.

The purpose of the tool is to create a four-square decision matrix and to place each task inside the matrix to determine the best way to deal with it. Figure 12.2 depicts an Eisenhower decision matrix. The y-axis boxes are labeled as not important and important. The x-axis boxes are labeled as urgent and not urgent. The four boxes inside the matrix are labeled as do, decide, delegate, and delete.

Figure 12.2 The Eisenhower decision matrix can be used to evaluate incoming work.

As each task comes in, you can classify it for both urgency and importance. The task is either urgent or not urgent, and it is either important or not important. Based on those assigned values, you can place the task in your matrix and know what to do with it.

I’ve modified the context of each box slightly to account for the fact that you may not have complete decision authority on the tasks you work on. If you’re an individual contributor, you may need to clear some of these actions with your immediate supervisor or manager. The goal of the matrix is to aid you in your decision-making on what you should and shouldn’t be working on.

12.2.3 How to say no to a commitment

Saying no to a new commitment can be difficult, but necessary. Commitments are the currency of credibility. When you accept a commitment, you’re putting your organizational credibility on the line. Saying no to new commitments that you can’t meet is just another method of maintaining your credibility. Sometimes a request for a commitment isn’t presented as a request but as a demand. But the work that you’ve done up to this point is setting you up to make saying no to new commitments not only possible, but entirely defensible. Your goals and priority are a shield against new commitments.

If your work is aligned with goals and your priority is set, then new commitments can be run through the Eisenhower matrix to see whether they should be performed. If they do need to be performed, you can run them against the following three priority questions discussed earlier:

• Will this commitment impact your ability to deliver the priority on time?

• Does this new commitment have the potential to become your new priority?

• Is this new commitment important enough that you should renegotiate your priority’s deadline commitment?

With these questions answered, rejecting the new commitment is straightforward. You state that you cannot accept the new commitment because it interferes with your current priority. If the commitment aligns with your goals (hence, it is important), you can defer that work to be performed later. Confer with the requestor, and if necessary, your manager, and come to an agreement on when the task might possibly be scheduled to be worked on.

If you’re an individual contributor, I highly recommend that you do not commit to a deliverable date at this point. Remember that your commitments are your credibility, and you don’t set the priority; your manager does. You can commit to bringing the request to your manager for prioritization, but that’s about it.

pro Tip Unless you have complete control over how your work is prioritized, you never want to offer commitments that you may have no control over honoring. This is important not only for the requestor, but for your own personal reputation in the organization.

When a requestor is adamant about the commitment being accepted, remember that declining the work is about honoring a previous commitment, and you don’t break commitments. If the requestor continues to be adamant, refer them to your manager.

You can say something simple and gentle as, “I’d love to help, but I have previous commitments that I have to meet. If you want to talk about prioritization or make a case for this being more important, you should talk to my manager, Sandra. She sets my priority and other tasks.” This simple way of saying no to a time commitment is unarguable. You don’t set the priority; your manager does. Just keep in mind that you’ve already made a commitment. You should never feel bad or pressured about accepting a new commitment that violates that.

Your manager may not have the same sense of work prioritization that you have. If your manager asks you to take on the commitment, regardless of the impact, be sure to clarify the new due date for your priority. It must be renegotiated.

You must be clear that accepting the new commitment conflicts with your ability to deliver the priority on time. You should also ensure and verify that the priority has not changed. Sometimes a manager may think that because they told you to do task A instead of task B, this implies a reordering of the priority. You should always clarify: “Just so I’m clear, does this change my priority?”

You’ll be surprised how often a leader may not recognize that they’re asking the impossible. Forcing them to choose between tasks that are competing for your priority may make them reevaluate the new commitment. Always make sure you have a clear understanding of your current priority. Also remember, you can have only one priority. Force your manager to choose a single priority for you. It can be helpful to iterate the newly negotiated priority in email as a reminder and clarification of the new expectations for everyone.

The following is an example interaction between Brian, the employee, attempting to renegotiate a priority with his manager, Sandra.

Brian: “Hey, Sandra. Joanne just asked me to work on this ticket for the recruiting team to fix some SEO issues with the careers page. But you’ve got me working on the calculation module for the billing project. I can’t do the SEO work and deliver the calculation changes by Thursday.”

Sandra: “Hmm. The SEO thing is pretty big because of the recruiting push behind this conference we’re sponsoring. Go ahead and work on the SEO page.”

Brian: “OK, but then I can’t deliver the calculations module by Thursday. The SEO work is probably going to take me a week, so I can deliver the calculation work two weeks from Thursday. Is that OK?”

Sandra: “Oh, no. We need the calculations before then to make the deliverable date for user acceptance testing.”

Brian: “Ok. Which is my priority? The billing work or the SEO work?”

Sandra: “Definitely the billing work.”

Brian: “OK. That means I’ll work on the SEO stuff after billing. But that might mean the SEO work won’t be done before the recruiting event.”

Sandra: “Well, the calculation work ties into our departmental goals, so you better stick with that. The recruiting event was never part of our goals or our priority, so if something has to suffer, it should be that. Maybe I can find someone else to take the SEO work.”

Brian: “Ok, sounds good. I’ll just send a quick email summarizing what we decided. Thanks!”

This dialogue shows how knowing the goals, priority, urgency, and importance of tasks and the work that your team is doing aids in deciding what to work on. Sometimes there is no easy way out of a task. There will always be a time when your attention must immediately shift to the new task on your plate. But how you manage and control that work will help relieve the sense of powerlessness you feel against it.

12.3 Structuring your team’s work

You and your team need a way to track both the work that you’re currently executing and the work that you’ve made previous commitments to. I won’t prescribe a specific technical solution. Your organization likely already has some sort of tool in place.

If there’s wide acceptance of a tool within the organization, but your team specifically isn’t using it, just adopt the tool that everyone else is using. Accepting the tool that’s widely in use creates less friction; it’s already approved, and makes interoperability and collaboration with other teams much easier. Something is most certainly better than nothing.

You might not have a technical solution, instead opting for pen and paper. That’s fine too. The only requirement is that all outstanding work must be captured somewhere and made visible to the team. Work cannot be an ephemeral idea inside people’s heads. Regardless of the solution you use, I’ll refer to it as a work queue system.

DEFINITION Work queue systems are tools or practices that help document a team’s current work. Each piece of work is known as a work item and is represented via a ticketing system, sticky note, or other physical or digital manifestation. This allows team members to visibly see the outstanding and in-process work for the team.

The remainder of this section discusses techniques for how to look at all the work you have before you. I’m addressing these steps to you as an individual; know that if you’re a manager, these same techniques apply, just across your entire team instead of to yourself.

12.3.1 Time-slice your work

If you break out your list of things to do, you’ll quickly become overwhelmed by the number of tasks. You always have more work than you have the capacity for. Looking at the list in its entirety is a recipe for disaster. The human mind can’t focus on that many variables at any one time. A to-do list of 50 items can instantly put you in a state of analysis paralysis, preventing you from making progress on anything.

The first thing you need to do is time-slice your work. Time-slicing is a technique that is often used for smaller work iterations. You may sit down to work on something in 30-minute increments, giving yourself time in between to stretch, get some water, take a break, and get back into the task.

Here, I’m taking the idea of time-slicing and expanding on it. When confronted with many work items, it’s best to choose a time-slice, during which you’ll focus on a subset of those work items. I call these time-slices iterations. In the Scrum approach to the Agile methodology, this is called a sprint.

DEFINITION Iterations, or sprints, are time-boxed periods during which a person or team commits to deliver a defined set of work.

Many companies don’t use the Agile methodology and instead opt to work in a style that breaks projects into sequential phases, with each phase providing its outputs as inputs to the next phase. This style of working is called the waterfall model. Either model is supported by this process, however.

For our example, I’m going to assume you’re working with two-week iterations: you’ve committed to completing the work that you’ve been assigned within two weeks. In the real world, you’ll need to come up with your own iteration length. It’s better to keep the iterations relatively short, to allow you the ability to add or remove items without throwing off a lot of dependent tasks. You can also consider choosing your iteration length based on the cadence of project-related activities.

Do you have a status meeting every three weeks? Maybe having three-week iterations makes sense to line up with that. Maybe your company is a bit nimbler. Maybe one-week iterations make sense in that case.

The primary benefit of using iterations is it allows you to ignore the other work items that you’re currently not working on. This is key, because the clutter of other work in your work queue system can serve not only as a distraction, but as a sense of anxiety for people who are overwhelmed when a lot of unfinished work is out there. You know you can’t do it all at once, so it’s better to create a laser-like focus on the items that you can do something about.

12.3.2 Populating the iteration

Now that you have defined a time-slice, you can begin looking at populating the items you plan to commit to in your time-slice. The total number of work items you commit to will be based on a mixture of factors: the number of work items on your team, the complexity of the work items, and any work that comes to your team in an ad hoc fashion. Ad hoc work is sometimes unpredictable and can force you to reevaluate work items in the current iteration. This work is referred to as unplanned work and is discussed in detail in the following section.

DEFINITION Unplanned work is new work that interrupts your current set of tasks, forcing a disruption to your previously scheduled work. Unplanned work may force you to switch to the new task immediately or to complete it in the short-term, potentially jeopardizing previous commitments. An example might be a bug from a previous sprint being flagged as urgent and needing an immediate fix.

Your list of items that will influence the number of work items you can commit to will look like the following:

• The number of people working on work items on your team

• The complexity of the work items

• The amount of unplanned work that your team experiences

The number of people working on your team will be a strong influence for the maximum number of work items you should commit to. In a two-week iteration, my rule of thumb is no more than four work items per person. This number will vary from team to team, depending on the team’s productivity. For the first few months, track how many work items you commit to per iteration and how many get done in that time span. Use this as an input to adjust and refine the number of work items you can realistically commit to per iteration.

The complexity of work items needs to be considered. You can have a work item count as multiple items in your iteration. This allows you to account for a task’s complexity. For example, if you have a task to automate database restores, but you know that process is extremely complex, you may count it as four tasks instead of just one, leaving less room in the iteration for other tickets.

If you have a work item that simply won’t fit into a single iteration, try breaking the task into smaller subtasks and scheduling those small subtasks. For example, if you had a ticket that said patch all servers to the latest version, and that’s a manual task, you might not be able to do it in a single iteration. You could break the task into smaller subtasks like “patch the web servers” and “patch the database servers.” Then just schedule those style of tasks across multiple iterations until you’re complete.

Unplanned work is an unfortunate reality for everyone. You need to account for unplanned work your team encounters, because when it happens, it’s not uncommon for those tasks to jump straight to the top of the work queue. You should continuously strive to eliminate unplanned work by applying some of the techniques mentioned earlier in the chapter. But you should keep a watchful eye on the amount of unplanned work you receive so that you can track and understand its sources.

The goal is to complete all the tasks you commit to for an iteration by the deliverable date. Sometimes that’s not possible because of unforeseen circumstances, but that’s OK. You’ll always be confronted with unplanned work, and sometimes that work will take precedence. Sometimes a task will appear easy, but balloon into way more than you could ever possibly get done in an iteration. Just continue to strive for improvement in the accuracy of your commitments, and continue to try to reduce unplanned work.

Once you have the iteration scheduled, you now have two distinct piles of work. The first pile is iteration-planned work that you’ve committed to getting done during the next iteration. The second pile is a collection of work items that you’ve accepted but haven’t yet scheduled when that work will be done. I’m going to borrow a term from the Agile community and refer to that work as the backlog.

DEFINITION The backlog is a collection of work items that have been accepted by a person or team as work under consideration, but the decision for if or when that work will be done has not been made yet.

The backlog can be a sort of mental trap for many teams. Seeing the unending pile of work items can nullify any sense of progression. Therefore, it’s extremely important that teams try to focus on the current iteration of work as much as possible. The backlog can be reviewed for planning purposes for the following iteration, but the backlog itself should be hidden from the current work view. The team should be focused solely on the work that’s been committed to for this iteration.

The iteration queue also has the added benefit of potentially being viewable to everyone, since your work queue system represents work either physically or digitally. This allows you to have transparency around the things you and or your team are working on.

12.4 Unplanned work

Occasionally a colleague will stop by unannounced and ask you for assistance with something. Trying to be a good coworker, you agree to help them out. What seemed like an innocent 30-second task quickly spirals into a web of misunderstanding and confusion that ultimately consumes way more time than you could have ever possibly imagined.

Once the magnitude of the intrusion settles in, you realize that your entire schedule for the day has been completely ruined. You’ve become the victim of unplanned work. Unplanned work is corrosive in its demands on your time and attention, forcing you to switch gears and focus on a brand-new task.

The problem with unplanned work is multifaceted. To start, your attention is immediately pulled away from the task you’re working on. Regardless of how big or small the new task that you’re presented with, there is a penalty for having to switch from one task to another. Getting back to the state of focus that you were in on your previous task is not fast or easy. This disruption is known as a context switch, and it can be very disruptive to the working flow of an engineer.

Context switching, and by extension unplanned work, is extremely expensive cognitively because of the amount of time it takes a person to get back into the flow of the previous task that they were working on. If you’ve ever been deep into a problem and then pulled away from it, you know how difficult it is to get back into the rhythm. It can take an engineer 15 to 30 minutes to get back into the previous mental state before the unplanned work.

Imagine an environment where an engineer is working on a problem and being interrupted once per day. In a five-day work week, that’s at least 75 minutes per week of lost productivity! On a team of four engineers, that’s almost five hours per week! You’ll never eliminate unplanned work, but controlling it is extremely important.

12.4.1 Controlling unplanned work

Controlling unplanned work requires a few high-level steps:

1. Evaluate the work coming in.

2. Make a note of the sources of the work.

3. Determine whether the work is truly urgent. If it is, do it. If it’s not, defer it.

4. When you’ve completed your focus work, evaluate the work deferred in more detail and decide when it will be worked on.

Before you can control unplanned work, you must first understand the types of unplanned work that exist in your environment and its sources. First, I’m going to talk about the kind of unplanned work that is easier to maintain: the cubicle drive-by.

Coworker unplanned work

Your coworkers are one of the most constant forms of unplanned work in the office. If you’re not careful, their problems can become your problems without any regard for the work that you currently have on your plate. People don’t do it to be rude, but in this hyperconnected world, people are accustomed to quick access to resources, information, and other people.

For some reason, many people have bought into this unofficial social contract that you always need to be available. But this mentality just makes you less productive for more hours of the day. The best way to handle human unplanned work is to make yourself less accessible during times of deep focus. Turn off your email, close down chat, put on your headphones, and just try to get deep on a task.

The idea of turning off chat and email might make you a bit nervous. You might have a fear of missing vital communication or an emergency chat that’s going to require you to spring into action immediately. Chat and email exist and are leaned upon because they’re easy, but they’re not the end-all method of communication.

Setting expectations is another method to curtail coworker interruptions. You set up open time slots in the day for anyone who has a nonurgent need of your time. Blocking time on your calendar and making it known that you prefer ad hoc meetings to occur between 10 a.m. and 12 p.m. Monday, Wednesday, and Friday lets people know the best time to interrupt you. The key is to stick to those hours! If people visit outside those hours with nonurgent issues, gently decline, inform them of your open hours, and suggest they come back then or schedule a meeting on your calendar.

In an actual urgent situation, people will exhaust methods of communication, including but not limited to phone calls and actual desk visits. Urgency and importance seldom occupy the same space.

I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.

--Dwight D. Eisenhower

Address at the Second Assembly of the World Churches, Evanston, Illinois, August 19, 1954

If turning off chat and email are unacceptable in your work environment, you can try turning on your out-of-office automatic reply and setting your chat status message to Away. Within these messages, you can provide an alternative method for getting in touch with you in case of a real emergency. I suspect that most people will recognize that interrupting you isn’t completely necessary and can wait until you become available again.

At smaller offices, the chat and email message might be skipped entirely, and people will go directly to the desk visit. The best way to solve unplanned work at your desk is to be honest with the visitor. When people stop at your desk, they often break the ice with a question like, “Hey, Kaleed. You got a second?” An honest “no” is the best response. Let them know you’re deep in a problem and that you’ll catch up with them in 30 or 60 minutes.

You’ll be amazed at how often this works! Remember that they’re asking for your time, which means unless it’s a true emergency, you can set the terms. Sometimes the interruption is warranted, and you just have to pay the context-switching cost. But being able to eliminate half of the unplanned work you experience in a given week will give you a lot of time back.

The key with this response, however, is to honor your commitment! If you said you were going to follow up, make sure you follow up. If you don’t, the next time they try to interrupt you, they may not be happy with waiting until later.

System unplanned work

Sometimes the systems themselves generate unplanned work for you while you’re working. That system unplanned work might be something as complicated as a system outage or as mundane as an event that requires just a little bit of live investigation.

Either way, system unplanned work can be hard to ignore. It’s important that you understand where your system unplanned work is coming from. It can become a constant nuisance to your overall productivity if you must frequently context-switch to deal with an automated alarm or system message.

Tackling system unplanned work starts with categorizing the sources. Any sort of automated system unplanned work should be categorized by a few axes, such as the following:

• What system generated the alert? (For example, did a user-generated action, a monitoring system, or a log aggregation tool create the alert?)

• What service or system is experiencing the problem?

• What was the date and time that the issue was detected?

As time goes on, you’ll see many other bits of data that you want to be able to report on, but this is the bare minimum of datapoints you need to collect. You want to ask and answer these questions to generate more information about the alerts for classification purposes, and attempt to solve the underlying issue behind the unplanned work. With these points, you can begin to get a sense of any patterns to the unplanned work:

• Is the unplanned work coming from a system at a specific time frame?

• Does one system generate more unplanned work than the others?

• Is there a common time of day that generates a lot of unplanned work?

Chapter 6 provided a lot of tips and advice on alert fatigue, and Chapter 3 offered some ways to approach creating metrics. Once you’ve identified a pattern to the unplanned work, you can focus your energy on the most egregious interrupters.

This is also another opportunity to apply the Pareto principle. In this case, it would mean that 80% of the unplanned work by systems is probably caused by 20% of the systems. Finding the 20% in your unplanned work generation can lead you to massive productivity savings.

Do it or defer it

Regardless of whether your work is human-driven or system-driven, your ability to stay on task will be determined by how fast you can figure out whether you need to handle the unplanned work immediately or can defer it. The time horizon for later might be hours or it might be days, depending on the situation. But the key is to avoid getting too deep into the weeds of understanding the new task, forcing you to context-switch from your current task.

Quickly assess whether the task requires your attention immediately. If it doesn’t, defer the task to a later time and get your attention back on the task at hand. Once you have a clean break, you can take time to examine the task more closely and understand its impact and level of importance.

It’s common for a casual desk visit to turn into a much larger request than can be handled in one easy conversation. Larger work will come in for your team from many sources. For the work that can be deferred to a later date, the next section covers how you manage all the work you’ve put off for later.

12.4.2 Dealing with unplanned work

Dealing with unplanned work will be an ongoing effort and struggle. There’s no easy way to get rid of this type of work if you’re working with other people and computers. In the previous section, I said that you should consider how much unplanned work you may receive throughout an iteration’s time period.

The first thing to establish is the urgency of the unplanned work. Sometimes after minimal examination, you can determine that the work isn’t nearly as urgent as it may seem. If it’s not urgent, you can put the request in the backlog for consideration in the next iteration.

In some cases, it may not be urgent, but still has some time sensitivity. At that point, you can just guarantee its placement in the next iteration. This gives the requestor the peace of mind that the task will be addressed soon, and it allows you keep your previous commitments.

But this doesn’t always work. Sometimes work shows up and it’s urgent. With any luck, the buffer you’ve created for unplanned work is enough to absorb this work without impacting the commitments you’ve already made. But what if this unplanned work is going to take considerable effort? You must fall back on your principles of being conscious about the items you work on and commit to. This means you need to renegotiate some of your commitments.

If people are dependent on your work and potentially blocked by you failing to deliver on your commitments, you need to restructure your commitments. I suggest you always start with the person delivering the unplanned work. If they’re the requestor of other work items in your queue, it makes sense to make a commitment swap. You offer up the other work items that they own in your iteration and ask them which one they’d like to remove. This forces the person who is showing up with unplanned work to prioritize their requests.

But the requestor who has unplanned work might not have other work items for you in the current iteration. Now you’re forced to impact someone who isn’t involved with this new work item. If you have items that you know have scheduling slack, you can reach out to the requester and try to negotiate a new commitment date. If there’s flexibility in the schedule, this can be an easy affair. If there’s not, the situation may need to be escalated.

Sometimes nobody will willingly volunteer their work to be rescheduled. At that point, it makes sense to get the requestors together and have each of them hash out the business case for their request. By making a business case, all of the potential stakeholders have the context necessary to evaluate the competing tasks. The following are key areas to hit:

• Why is the request important? Does it roll up to one of the defined goals?

• What’s impacted by the request’s delay?

• Who are the other stakeholders of the request? (For example, who else is impacted by the request’s delay?)

With these three questions laid among the group, you should be able to negotiate a delay in someone’s process based on importance and impact to the business. This sounds like an extremely formal process, but it can typically be done in less than 10 minutes. The work item that gets bumped should be the priority in the following iteration.

NOTE You’ll be tempted to consider bumping your own work for things like maintenance, patching, security, and rearchitecting. Reduce the urge to devalue your work. As a technologist, you need to protect your time for dealing with these tasks. If you offer to reschedule that work, be sure that it gets prioritized in the following iteration.

The key to managing unplanned work is to be able to identify it and its sources. Is unplanned work coming from repeated manual requests for your team? Maybe you can automate that. Perhaps testing environments require more care and feeding than they should? Whatever the reasons, you need to be able to identify unplanned work so that it can be examined later.

You can do this in many ways, depending on what you’ve used to implement your work queue system. Many software solutions have labels or tags that you can apply to a work item for reporting purposes. Here are few options for software solutions:

• Jira Software (www.atlassian.com/software/jira)

• Trello (https://trello.com)

• Microsoft Planner (https://products.office.com/en-us/business/task-management -software)

• monday.com (https://monday.com/)

• Asana (https://asana.com/)

• BMC Helix ITSM, formerly Remedy (www.bmc.com/it-solutions/remedy-itsm .html)

If you’re using a paper-based work queue system, you might need to create a separate log or spreadsheet that tracks this information. Microsoft Excel or Google Sheets is a perfect solution for this, with many functions that can help you easily generate reports on specific fields.

Whatever method you use, just make sure it’s something that can be reported on so you can identify where the unplanned work is originating from. This will be your primary insight for reducing it.

You can easily confuse difficult work with the most time-consuming. You may have some unplanned work that is incredibly burdensome but happens infrequently. Compare that to work that’s easy to execute so it doesn’t feel painful and is handled quickly. But if you consider three or four team members are doing it multiple times a week, it begins to add up. Being able to report on the sources of unplanned work gives you objective visibility into where the work is coming from.

Having a solid approach to handling work is critical to a DevOps environment. A key part of DevOps is making the time for the automation, the permanent fixes, and the internal tools that have been neglected previously. Being able to prioritize your work and defend that prioritization process is a must-have skill.

Iterations are a solid way to block out as many of the excess tasks as possible and to put focus on a small subset of tasks. When you’ve planned your work, being able to identify unplanned work becomes easy. When unplanned work comes to you or your team, you need to be objective about its urgency. Is this something that’s truly urgent, or is it merely important? Important tasks go in the backlog to be prioritized during your next iteration. Having a firm handle on the work that you’re committed to allows you to be intentional about accepting, and sometimes rejecting, new work.

Summary

• Goals cascade throughout the organization.

• Work needs to be classified and prioritized to ensure that the right tasks are getting done.

• Urgency and importance are two categories to classify work.

• Work needs to be organized so the team has insight into pending and in-process work.

• Unplanned work is disruptive and needs to be identified, tracked, and reduced as much as possible.

Wrapping it all up

You’ve done it. You’ve reached the end of this wild ride called DevOps, or at least the instruction manual. But now you have to go into your organization and put it into practice. A common question to ask at this point is, “Where do I start?” My advice is to start where it’s easiest.

Remember that a DevOps culture isn’t necessarily a prescribed path from A to B. Some organizations will struggle at parts that differ from the struggle that other organizations will face. Some companies don’t even have all of the problems that I’ve discussed in this book. I’ve taken great care to not dictate any path as the only path because every company is different and has a different set of problems.

One piece in this DevOps movement seems universally true: there isn’t just one thing that you need to do in order to unleash the power of DevOps. It’ll take several changes in several areas to get teams working closer together, solving common problems, and working toward a common set of goals. Start where it’s easiest--where you can deliver the most value with your own personal effort. For example, it might be easiest to start organizing lunch-and-learns to help foster and facilitate knowledge transfers. Maybe you can begin instituting the postmortem process after an incident, facilitating the conversations and helping the team to more thoroughly explore the nature of the failure.

It’s tempting to dive right into tools and workflows that are touted in conferences and tech blog articles. I beg you to resist that urge--not because tools aren’t important, but because they’re not as important as the soft skills outlined in this book. When your company has developed those soft skills in the organization, you’ll be better equipped to ask the difficult questions surrounding your technology choices, with open, honest dialogue about the needs and wants of the team members who will be using it.

Last, I recommend finding a community outside your organization to talk about DevOps with. Meetup.com is a great place to find like-minded individuals to share the burden, troubles, and triumphs of what it’s like trying to make this leap to a new way of working and interacting. Being able to meet with others and see how their approach can influence your own is a lifesaver. You’ll quickly find that organizations have similar personality types in them, and some knowledge gained could be widely applicable.

If there aren’t any DevOps groups in your area, start one! If you’re interested in DevOps, I can guarantee that there are others within a 20-mile radius who are also interested. Just start by meeting consistently, even if it’s only to network and talk. If things start to pick up, you can begin creating more structured meetings with presentations from members of the community. You’d also be surprised how many companies like Datadog, PagerDuty, GitHub, and many others will fly someone to your Meetup group to present lectures. Take advantage of these opportunities.

Our interactions don’t have to end with the final page of this book. I look forward to interacting with you and offering any advice I can give. The best ways to reach me are via Twitter, where I’m @DarkAndNerdy, or via LinkedIn. You can also find me at my website, https://attainabledevops.com. I wish you the best of luck in your DevOps journey!