Boss: "We need something done... really soon."
Me: "How important is it?".
Boss: "Really, really important."
Me: "Important enough that everyone needed to get it done can be given the freedom to make it their unambiguous priority?"
Boss: "…"
Me (eyebrows engaged): "...?"
Boss: "Tell me what that looks like."
Have you ever worked on a team that was so productive you felt energized about work? Don’t feel bad if the answer is “no”. Maybe instead of trying to improve morale to increase productivity we should try to increase productivity to improve morale. Given how important work is to us as humans, that should seem like a logical progression. Let’s explore this a bit in this short article (short for me… ahem).
Raise your hand if you know what “whole team” means. I have said that I think this Agile practice is the one most observed in the breach and that is borne out by the blank stares when I ask the question. It means that everyone needed for the success of the project is on the team, and everyone on the team unambiguously shares the same priorities. The more complex the project and larger the organization, the less this tends to be realized. But the goal is really pretty simple – as the team exposes the work it needs to do, it can actually do the work. Please just ponder that last sentence for a moment. It is so obvious that it’s tempting to wonder why it even needs to be said. And yet I would put my finger on this as the biggest reason projects fail, and the most profound ingredient if you want projects to succeed.
Let’s imagine first a positive example. One of the most energizing things about a startup environment is the unambiguous nature of priorities and the knowledge that you are shoulder to shoulder with everyone that is going to do the work (there is no “them”). I’ll go out on a limb here and say that this used to be profoundly facilitated by everyone working in the same physical space. If you have never experienced the energy of working with a group of people that way, and successfully delivering the goods, then it’s difficult to convey how satisfying it can be. I still think it is simply the most productive you can be. But it is a level of productivity we are seldom willing to afford. It is not my intent to litigate “remote vs. local”. Co-located teams in the software industry have been getting increasingly difficult to assemble for a long time for many reasons (some of them quite legitimate). I simply want to assert that anchoring one end of the spectrum for how well a team can function we find this phenomenon of a small, co-located team with the essential skills and very nearly unambiguous alignment of priorities. It is a heady draught. It is the closest I’ve ever come to “I can’t believe I’m being paid to do this”.
Anchoring the other end of the spectrum is… something else. Here we have a team whose unifying principle is that they occupy the same physical space on an org chart. Someone has almost certainly bought into the idea (or is making decisions as if they have) that people are fungible and arbitrarily divisible units. Each person seems to have their own little private backlog within the backlog. Priorities are onboarded by the team with no real assessment of whether they could get done in a timely way but doing so allowed someone to check a box and say, “we’re working on it”. Getting anything done that is too big to fit in one person’s head is a matter of aligning all these little backlogs. No-one is quite sure whether that thing is really important enough for them to shove the other things in their private backlog aside – all wrapped up in a suffocating dread that it won’t get completed before a new shiny object displaces it. To make it worse, you might have dependencies on other teams in the organization – teams that may not even have a common executive who can disambiguate priorities until you get to a VP or CEO. Remote vs. co-located is irrelevant – the advantages of either have been completely neutralized. “Look – we went remote with no loss of productivity!” Yeah, about that…
So, what’s to be done?
Here is my plea to all the executives out there. This is a hard problem viewed from the trenches and you should not expect your teams to overcome it at the grassroots level. Ok – there are some strategies for teams that can help them overcome this. But let me put it another way – do you think your job as an executive is to lead an organization that teams need to overcome to be successful?
I think it was Jack Welsh sometime before he was CEO of GE that told a story about how he was given responsibility to solve a problem and was given a nearly blank check plus the ability to draft pretty much anyone needed for the effort. Well – nice work if you can get it. This is not the world most of us live in. However, it illuminates a directional strategy. I have had the opportunity to try something analogous on a much less exalted scale. To revisit the little dialog at the beginning of the post – what that looked like was an agreement to assemble a team consisting of people from several development teams, field operations, content creation, and perhaps most significantly from the legal team where otherwise great ideas go to die. It was successful. It was efficient. It was fast. It was fun. And it was bigger than Dev Ops (oops… different topic).
Now you might object that in the steady state it’s just not that simple. Granted. Nothing ever is. But that isn’t the problem, is it? This is only really hard for those bent on carrying two tons of canaries in a one-ton truck by keeping half of them in the air at once. Suffice it to say I think the reason this is hard is because it drains the swamp and exposes the need to make tradeoffs people aren’t comfortable making.
Do I need to say it again? Don’t make me say it again. Ok, I’ll say it again. If you want the humans on your teams to thrive, and generate a dividend to show for it, never underestimate the power of people who are in no doubt about what they are supposed to be working on and are given the latitude to do it.
Bonus paragraph:
Ok – let’s litigate remote vs. co-located just a little. Whether remote, or co-located, the goal should be to have the “vibe” of working in an effective physical team space and being aligned on the work at hand. An effective physical space provides almost zero barrier-to-entry for helpful ad-hoc collaboration. It also provides significant barriers to distractions from those who are “not on the team”. How you arrange that given your tools and constraints is going to vary a lot. But it will be for naught if you can’t get alignment of priorities. If you are resourceful enough to solve that, you can solve the remote/local thing. But please don’t try to do it without baking in a way for subsets (at least) of the team to share air and food with one another on a somewhat regular basis. I think it will be an uphill climb without it – because people are weird that way.