Get Kitted For The Right Kind Of Failure

My favorite article of the last few weeks was “4 best practices to build more perfect software, faster” by someone who is actually doing so. He works for a company called New Relic I’ve never heard of before and that I still don’t know much about but, judging by what I read, I’m clear on one thing: they hands-on and successfully (I have no idea who their competitors are but I am willing to bet they do better than them) make software. They are “doin’ it”. From just reading this, they sound DevOps-y, #Agile mindset-ed and therefore clear on the value of humans. This is not the kind of realization you come to from reading a book. 

The author of the article, Alex Kroman, starts with Psychological Safety. He’s unwavering in the assertion that if you want your people to move fast you’d best empower them to feel safe around one another and around failure and that as an enterprise, you have to “Treat psychological safety as a key business metric, as important as revenue, cost of sales, or uptime. It will support your team’s effectiveness, productivity, and staff retention, along with other key business metrics”.

Aside from how it tickles me pink that the industry is arriving at these “A-ha!” moments where they connect Psychological Safety directly to the ability to fail fast, adapt and become resilient and flexible enough to execute on Agile and make the products they need to, such an article is useful to anyone who’s truly intent on doing well.

The author is one of the few that “get it” - this value of the secret sauce we are eternally on about at PeopleNotTech and more so, is kind enough to share with the class not keep it to himself, like most other Silicon Valey darlings. But even he is hard-pressed to give suggestions of tools that will help. In fact, while his recommendations for the other 3 points show hands-on examples of things that work such as OKRs, a DACI framework, etc, this part stays at a bitter-sweetly all-encompassing “Emphasize purpose and values, demonstrate humility as a leader, ask questions, work to destigmatize failure” level of recommendation.” 

It’s an example of what I call the “DUH and yet impossible” monstrous task that is as large as “Have no politics, have a healthy organization and make your teams feel happy to be productive” - all true and all seemingly gargantuan tasks that tech team leaders don’t feel empowered or mandated to tackle. Which is why the tools and ideas he does mention are priceless. 

But is it that the tech leaders reading this, who are experienced and intelligent enough to know better, feel like they understand what all tools they need and, more importantly, do they feel they are mandated to kit their teams with all of them? 

If your team has a job to do you need to empower them with the tools to do it. The concept in itself is never under question. 

Should they need to launch a marketing campaign you’ll need to make sure they have shared workspaces. Whether Google docs and Slack or some other combination straight out of 1990 that’s an individual choice. 

If they need to sell something, they will need a place to keep information about prospects and a place to guide joint efforts - whether that is Pipedrive and Trello or the nightmare alternatives that’s up to the respective team.  

If they need to build software, they have to keep it and they have to see how it’s going - whether that’s Github and Jira or something archaic that’s also an individual choice. 

You get the gist. Nothing can be done in the absence of tools and that’s indisputable. Few tools out there are “nice to have”. You won’t hear anyone debate that maybe you don’t need an expense system or a debugger. No arguing whether one should have access to email or to a repository. 

The only ones that are uh-ed and ah-ed about are people tools. 

Granted, there aren’t many of those and they are all very new. The very fact that they are new is telling. For some reason, we have collectively left the human element of work out of it historically, and thought we would get away with it. As if we have expected to have jobs to do, tools to do them with and be non-human to employ them.

Realistically they “why” of how this has happened, is a lot more complex and it has to do with the way we’ve let (not “designed”) organisations to grow and how everything that is connected to humans was meant to be outsourced to this mythical separate function of the organization - HR which was supposed to deal with all the “fluffy things”. 

By the same token, one could argue that kitting the team with the tools to deliver on a project should have been outsourced to Operations and they should be the ones to give them the software or hardware they needed to do it and yet, because it’s so important, no team leader would dream of leaving it to some other external function. 

Imagine waiting for someone in the Ops department to decide IF you need any access to Jira for your project. 

And yet, when it comes to the human side of things, we routinely either expect it to magically sort itself out or expect someone else to figure it out. 

Does the team need motivation? Someone in HR should deal with it. 

Does the team need any extra perks to move them along a fast project with individual milestones? They should toy with some rewards system and someone else should decide if they deserve it. 

Is it imperative that they are happy and healthy as a team to do the job and so we must have the tools to listen out for that? Well, “imperative” is a funny word. 

Do they need to be able to execute in an environment of learning, leaning and opening up? They’re on their own.

Taking a step back it’s crazy to think we expect our people to perform without remembering they are people and without taking the tools that will help them be happy humans a lot more seriously. 

Would we send a young child to school with a bag full of rulers and books but devoid of any idea of social rules, with no means to communicate to us or any other adult and without as much as a talk on what they are to do should they need anything? Would we feel we have prepared Mowgli for village interaction if we see him in a uniform and ensure he has enough sharp pencils? 

Because that’s precisely what we’re doing when we’re asking a team to write software, sell something or deliver on any other project without giving them the tools to check and better the team. Thankfully, there are techies out there who, as Alex above, have been so smart and so clued-ed in that they evolved into real leaders who put people first and would never do that to Mowgli.

In short: if your job is to make a team do a thing you can’t expect to only give them half the tools to do so, or for anyone else to give them the other half.

If you’ve kitted them with Jira or Slack but no “people tools” then be prepared to work twice as hard, take twice as long, or just be prepared for failure of the bad kind.