Most organizations I've worked for haven't lacked for talent. I have had the benefit on working on very strong teams made up of talented people both on the development, and operation side. But if that talent isn't managed well, you'll still struggle with getting projects out the door. So, in this video lesson, we're going to discuss how to effectively manage workload with a DevOps mindset. After watching this lesson, you'll be able to describe methods for tracking work and creating feedback loops, and explain how tracking and working to improve eNPS, can lead to higher performing teams. All right. Let's dive in. Tracking work at the team level is really important because in most organizations, engineering capacity is the number one constraint in getting projects done. So, the more information you have about the work that's happening at the team level, the better setup you will be to optimize and remove that constraint. In my experience, often the categories used to manage work, are features, technical debt, operational work and then unplanned work as we discussed in an earlier lesson. At Nike, we're tracking all of these items, and using the data in a fact-based way to demonstrate what's being prioritized. I have a phrase I use called honoring and extracting reality. I believe that it's important to understand what is really happening, and also create an environment where teams are comfortable surfacing reality. The best way to solve a problem is if it's visible. When surfacing this data, try to connect it to the business outcomes too if possible. For example, if unplanned work is a high percentage of the work being done by the team, then it's likely business outcomes and value are not being fully realized. Depending on the ratio of these categories, they may also indicate a certain level of employee burnout. If teams are not getting the opportunity to focus on reducing technical debt, focusing on operational work, and or improvement activities, they will likely feel like they don't have the support to remove waste from the existing processes. I also use this information to check in with the teams and see if they're getting time, capacity and space to learn and improve. We also tend to go over improvement opportunities that they've identified at the team level. Getting once again at that DevOps value of sharing. The collection of this data is intended to reduce burden on the teams. One trap that organizations can fall in is trying to be too prescriptive about the definitions of the work. It's important to let the team define it for themselves. What's important is that it's being tracked, reviewed and leaders are engaging by being curious, and asking good questions about the data. It's about understanding the current condition, setting new targets and improving. The team can use Improvement Kata and A3 problem-solving to identify those opportunities, to experiment, learn and improve. The leaders role is to be supportive, and also it's possible that the team might surface a need that leadership needs to resolve. One example that I've encountered is that if teams are having a challenge with focusing on operational work, sometimes they need their leaders to help within influencing the stakeholder community to make sure that we've got the right balance and the right ratio. Another important aspect of managing work is implementing feedback loops, especially if a product is considered unhealthy. Unhealthy could mean; poor performance, lots of errors, crashing or high incident counts or reports. One reason could be that the workload ratio is off, too many features and not enough operational work. At Nordstrom, we discovered that one of the reasons our crash rate was high on our mobile app was because the Development Team was 100 percent focused on features. This was not anyone's fault, it was just how the system had been operating for years. The system was set up so that one team focused on features, and a separate team worked on production support. That production support team was often primarily focused on service restoration. A feedback loop did not exist back to the dev team to allow for prioritization of operational work. In the digital space though, we needed to adjust how we were delivering this product. We did two things; we changed the expectation, and had the team build, own and improve the entire product. We also clearly communicated that resilience, performance, essentially the health of the product, are actually features. We also made the data visible to our stakeholders so that they could see that we were having a lot of operational challenges. That was a way to get support, to balance the workload, to include the investment and reducing the crash rates of the app. We did that work, and improved crash rates. The team felt more ownership and accountability for the entire product. Our stakeholder community was happy as well because our customers were happy. We saw show up in our app reviews, and we minimized calls to our contact center with complaints about the app experience. At Starbucks, I had a similar situation. I had a dev team focused on features, and a separate production support team focused on incidence and service restoration. To improve feedback loops, we tried an experiment where we embedded one of our production support team members into the dev team, and almost immediately the dev team learned about a feature they were about to deploy that would've created a production incident. The team was able to adjust, and not only was that a huge win because the team caught a potential future incident, but the team also had shortened an important feedback loop. Instead of waiting to release and discover this issue, which would likely have been four to six weeks later, they learned about this within hours. This model is a way for us to bridge to a full product model because our architecture was not in a position yet for the teams to fully build, own and improve the product. Overall, having the shortest feedback and or learning loop possible is a good thing, and will help as you continue to adopt these principles and practices. Finally, it's also important to consider your employee net promoter score as it relates to managing workload. Remember, we introduced eNPS in an earlier lesson, and it generally asks two questions to help evaluate team health. Would you recommend your organization as a place to work to a friend or colleague? Would you recommend your team as a place to work to a friend or colleague? So, when someone gives a score of nine or 10, they're considered a promoter. Scores of seven or eight are considered passive, and scores of zero to six are detractors. The score is calculated by subtracting the percentage of detractors from the percentage of promoters. For example, if 40 percent of employees are detractors and only 20 percent are promoters, the eNPS is negative 20 percent. At Nordstrom, the mobile app team I was talking about before, became the highest engage team after we made the adjustments to enable them to build, own and improve the product. They had an eNPS of 89 percent. The next closest score in the organization was 40 percent. The mobile app team also understood the business outcomes they were driving, and felt very connected to the organization's values and goals. At Nike, we're also tracking eNPS. I used that data to dig deeper into the why behind the scores. If a team has a low eNPS, I seek to understand the contributing factors to the low score. If a team has a high eNPS, I also go talk to the team to learn and understand what is working well. In either case, it's a learning opportunity for me. If there are leadership actions that can be taken to help the teams, I use that information to help problem-solve with my extended leadership team. The most recent state of DevOps report indicated that employees in high performing teams are 2.2 times more likely to recommend their organization as a great place to work, and 1.8 times more likely to recommend their team. This is statistically significant, and businesses are reaping the benefits of high eNPS scores. Companies with highly engaged employees grew revenue two and half times as much as those with low engagement levels. So, employee engagement is not just a feel good metric, it actually drives business outcomes. It's also been found that eNPS is significantly correlated with the extent to which the organization collects customer feedback, and uses it to inform the design of products and features. This is yet another version of a feedback loop. The ability of teams to visualize, and understand the flow of work through development all the way to the customer. The extent to which employees identify with their organization's values and goals, and the effort they're willing to put in to make the organization successful. When employees see the connection between the work they do and its positive impact on customers, they identify more strongly with the company's purpose, which leads to better software delivery and organizational performance, and perhaps most importantly, it also leads to happy teams.
