Overstressed Data Teams
Introduction
At our last Data Captains retreat, we decided to set some time aside to read Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom DeMarco. The book offers quite a unique perspective: in an industry landscape dominated by organizations that are obsessed with efficiency and with doing more and faster, slack (i.e., time characterized by absence of work and lack of chronic busyness) is the lost ingredient for organizational agility, flexibility, and effectiveness.
While the book discusses the need for more slack in general organizations, it also evokes some very specific images in the minds of those who run, work, or consult in organizations that focus on Data Science (DS), Machine Learning (ML), or Artificial Intelligence (AI). And while the book is not recent (it was first published in 2001), the lessons that it teaches are all but outdated.
In this post, we describe some of the troubles that can arise in “slackless” DS/ML/AI organizations.
Your Data Captains at work (or slacking?) at their last retreat.
Data Science is still a relatively young field
Forget big tech companies for a moment. Obviously, they have had a great deal of success applying DS, ML, and AI to their products and services. If you take a look at what’s left, you will see that several among these companies
have comparatively modest resources when it comes to their DS/ML/AI endeavors
struggle comparatively more to make DS/ML/AI live up to the promise of producing useful insights, improving their products and services, and generating meaningful business value.
In many of these companies the hype for DS/ML/AI is high. Their senior leadership is also more likely to have an overly optimistic expectation that any investment made in DS/ML/AI will just automagically pay off (“Let’s just do whatever Google is doing. It’s working out great for them!”). Once these companies form their own DS/ML/AI team, considerable pressure is put on that team to work its magic: with such an expensive and highly educated group of employees in place, there are no excuses for not trying to solve all problems by just waving this new wand.
If you have ever worked as a manager in this space, you probably discovered that your excitement for the popularity of your team and for the number of interesting projects that are being thrown at you is only exceeded by the unreasonable size of the expectations that your senior leadership places on your shoulders.
Data Science overload
As a manager of a DS team, you obviously want your team to succeed. In the heat of the moment, when projects are coming your way from all directions, you are at increased risk of making the following bad decisions:
Accepting all projects that are coming your way.
Deferring or entirely ignoring the process of estimating and communicating the risks associated with the delivery of your projects.
Forcing your team to work harder or faster.
Assigning too many projects to single individual contributors in your team.
Micromanaging.
Taking on hands-on projects that your team cannot work on because all the individual contributors are at capacity.
All of the above decisions generally turn out to be poor. By making them, the result might be that your team will look or feel busy. But over time it will become increasingly hard for both yourself and your reports to actually generate positive results for the business. Let’s see why.
Good prioritization is the first step towards delivery
By accepting all projects that are thrown at you, you are not taking the necessary time to recognize that certain projects are substantially more likely than others to create a positive business impact for your company. In the extreme, you may even be taking on projects that are just impossible to execute at this particular moment given the current stage of DS/ML/AI maturity in your organization.
Project prioritization takes time. Saying “no” or “not now” to your senior leadership and turning down projects is uncomfortable. Also, you may be worried that every second spent evaluating the characteristics of a project before committing to it may look like wasted time. Especially if yours is one of those DS organizations that operates under the “hurry up” directive.
However, if you don’t give yourself and your team enough time to slow down and think about where the team’s energies are best spent at any given time (i.e., if you don’t build some slack in your team’s operations), you will be ineffective. You and your team will work a lot, but will fail to deliver.
Risk Management makes your team faster
When taking on a new project, you and your team may be tempted to jump into it right away. You (rightfully) want to be perceived as the “can do” manager of a “can do” team. But if you and your team do not take the time to evaluate risks and communicate expectations accordingly, you will sooner or later find yourself delivering too little and too late. Be consistent enough at this across multiple projects and, sooner than you know it, you may be asked to take your talents elsewhere. Your memory will be that of a “couldn’t do” manager of a “couldn’t do” team.
The time that goes into risk mitigation is time that may retrospectively appear as wasted in the best case scenario of risks that do not end up materializing. But it’s exactly the time that you invest in risk mitigation that - statistically speaking - makes you faster across multiple projects, more predictable by your stakeholders, and ultimately wins you their trust.
Risk management allows us to deliver consistently and on time across multiple projects, in exchange for some extra work upfront and a slightly lower execution speed. The difference between the time it takes us to complete projects at this “prudent speed” and the time that it would have taken us to complete them at “breakneck speed” is slack. And, as DeMarco puts it: “Slack is what helps you arrive quickly [not necessarily quickest], but with an unbroken neck.”
Putting pressure on your team will not make it more efficient
The obsessive and emotional “hurry up” culture that is antithetic to the strategic and rational culture of slack that DeMarco describes can produce very surprising side effects.
You - a DS manager - have the power to increase the pressure on your team. You can ask them to work harder and faster. You can design both subtle and not-so-subtle incentives to generate this response. What’s wrong with that? After all, isn’t being busy an implicit compliment and an indicator of the importance of the work that the team is doing? Unfortunately, increasing the pressure on your team doesn’t always lead to the results that you might expect.
First of all, people under time pressure do not think faster. Think rate is fixed. In the short term, your pressure may generate slightly higher efficiency. This is because your team is forced to lower the quality of its output, defer tasks that are not on the critical path, or work longer hours. However, as DeMarco reminds us, the long-term effects of prolonged pressure are not desirable: “The long-time effect of too much pressure is demotivation, burnout, and loss of people. The best managers use pressure only rarely and never over extended periods of time.”
Additionally, if you try to speed your team up by creating a context in which the people are all working furiously, you will actually end up slowing your team down. If everyone in your team is always working frantically, they may no longer feel very safe finishing their projects on time and waiting for you or somebody else to assign them more work. As a survival tactic, they might choose to purposely slow down just enough to keep themselves sufficiently busy, but not too much so not to start appearing to you - their manager - as bottlenecks. If this occurs, the pressure that you generated by eliminating all slack ends up slowing your team down.
It is important not to confuse bad pressure with good pressure however. For example, having periodic check-ins on DS/ML/AI projects can help make individual contributors feel more engaged and aligned with the company’s mission. Furthermore, inviting team members to have bias for action and deliver frequent intermediate results - as opposed to chasing final and perfect solutions from the get go - can be a healthy way of fostering a culture that values iteration and incremental delivery. Possibly, this is one of the areas in which DS/ML/AI still has much to learn from other software engineering disciplines.
Too many projects will break your team apart
All other teams in the organization want to collaborate with you and your DS team. Everyone has a project in store for you. You are overcommitted and you over-promised. You might have asked and obtained approval for a headcount increase, but hiring is hard and takes time. Since you can’t count on additional help coming your way any time soon, you are left with only one option: assigning each project to one member of your team and assigning each member of your team to multiple projects. Here are a few reminders of why pushing your team to this level of slacklessness is generally a terrible idea.
For starters, you are implicitly assuming that your team members are fungible resources: they can be moved around and their time can be split among multiple projects. As it turns out, Data Scientists and other knowledge workers are not fungible resources. DS projects are characterized by tasks that require immersion (e.g., research, analysis, programming, writing), and Data Scientists incur a cost every time they have to switch context. Time inefficiencies quickly accumulate because most of us are very reluctant to start immersive tasks unless we have enough time set aside for them. Furthermore, we tend to get frustrated when we interrupt one project to start another one because context switching makes us burn large amounts of mental energy.
Additionally, if you end up with a fragmented team in which team members are working in complete isolation on their own projects, you are limiting their ability to bond and form, well, a team. You are then severely damaging the functional learning environment that the team naturally provides to its members. If team members work in isolation, the quality, volume, and speed of the output that they produce will most likely deteriorate.
Control slack is as important as time slack
Something else may also happen as you get increasingly antsy because your team can no longer keep up with its workload: as a defense mechanism, you may start to increase the amount of control that you exercise over the team. Without fully realizing it, you may start micromanaging the work of your team members. In a desperate need for increased efficiency, you may even find yourself limiting the flow of information, pulling rank or over-leveraging your positional power, and adopting a much less effective communication style (“I am your boss and I committed to delivering X. You are the individual contributor and I expect you to deliver X.”).
If you start going down this path, rest assured that - at a minimum - your team members will begin to find you intellectually offensive. As DeMarco points out: to keep control of high quality workers, you have to give up control. And your authority should be used so sparingly that no one notices when it’s being used. On this topic, DeMarco also offers what is - for us Data Captains - a very inspiring image: “Like a gifted helmsman, who knows that all use of rudder increases drag and thus holds the vessel back, you have to steer with the lightest possible touch.”. Control slack is as important as time slack.
Picking up hands-on work won’t make you a more effective manager
Let’s say that you already spread your team thin. There is still one way for you to make things worse. Remember that project that you just can’t fit in any of your individual contributors’ plans? Well, why don’t you take that matter into your own hands? Sure, you are a team manager now, but maybe you were an individual contributor in the past and - rust aside - you can certainly still take on some hands-on work.
Congratulations. You have just pushed your team to the ultimate level of slacklessness.
We are not suggesting that a manager shouldn’t be performing the tasks of an individual contributor because of an intrinsic difference in abilities or because of some other matter of principle. There are many technically competent managers out there with a stellar past as individual contributors. The problem here is that a manager who is taking on individual contributor work is not using that time for tasks that are for more important tasks in their current role (e.g., enabling collaboration with other teams, providing growth and development opportunities to their team members, etc.).
Conclusions
In this post, we described some of the ways in which DS/ML/AI organizations can become overstressed and we talked about the troubles that usually follow. Many of these points (and many more) are explored in great depth for general organizations in Tom DeMarco’s Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. The book offers a recipe to make organizations slightly less efficient, but enormously more effective and capable of continuously changing and re-optimizing themselves. As we discussed in this post, that recipe is centered on the introduction of slack in day-to-day operations. The responsibility to introduce a creative use of slack to make an organization flexible and effective rests on the shoulders of middle management, and the book is in many ways a celebration of the importance of having capable people managers in an organization.
Of course, introducing and creatively using slack where needed is easier said than done. However, while slack may not be sufficient to solve all problems in your DS/ML/AI organization, it might be necessary for your organization to be able to find the time and understand how to address them. Slack is an enabler of organizational change and in an ever-busy organization change becomes impossible: “It’s like a car that can speed up but not steer. In the short term, it makes lots of progress in whatever direction it happened to be going. In the long run, it’s just another road wreck.”
Need help designing and managing an effective data organization? Data Captains can help! Get in touch with us at info@datacaptains.com or schedule a free exploratory call.
