IT Is Saving the Organization - You're Welcome

We make no secret at PeopleNotTech that our best dialogues and partnerships are with DevOps heroes. Meaning if we need to build a business case so that the organisation gets why they should actively work on making their teams more Psychologically Safe, then it would be “tech people” who are best positioned to help with that.?

Why? The same reason why they were the first to try out remote and distributed teams, the same reason why Agile is finally etched in the very bones of the community, the same reason why they were the first to insist on rethinking architecture, bringing in the cloud, OKRs and so on and on - the practical realisation of the needs created by the speed of technology that only IT seems to have.?

If you’re in an organisation that has a strong knowledge component where you make any type of technology, then you must have noticed the huge gap between “business” and “tech” and how much more advanced the latter is. They have seen more rapid change than any other part of the organisation because the ask was to create things fast and no speed was possible before a series of shake-ups to the status quo.?

Those same needs aren’t evident elsewhere in the organisation and many “supporting departments” could well function as if it’s 2010 and nobody’s watching, for the next 10-20 years before their lack of deep understanding would evidently translate in their performance.?

Any IT shop within an organisation knows they are light years ahead. That they have a duty -if not always a license- to drive fast progress while the rest of the enterprise drags feet.?

What we make with our team Dashboard has no “market”, it rarely is a line item, it is never “scoped” or “required” and in the rare occasions where it is hailed as a priority, it is also “resolved” by extreme sterile awareness only vicious circles, so it’s no surprise to us that we have to keep repeating the same things and that it is immensely hard and it takes superhuman efforts from both our part and the DevOps Superheroes that help move the needle in their organisations when it comes to getting serious about Psychological Safety. So we expect it.?

But this isn’t the first time that IT has had to drive change that is really uncomfortable for the organisation. Almost everything to do with Agile was accompanied by some of these big pieces of hard transformation work.?

What about when IT realised they needed coaches? I would even include here Scrum masters and any type of highly emotionally intelligent tech leaders not even just Agile coaches - anyone who had the EQ to comprehend the new demands of the Agile team and try and deliver them. I remember the days, not long ago, when that need arose and how let’s face it, HR mostly kicked off. They thought even expressing the need was an attack on their competence - they were providing their people with that type of support with all the pieces of training, the intranet and the conferences, right??

Wrong.

Not only did it take a long time for the need to not be taken personally but be understood as a new set of competence but the acceptance isn’t even the norm today. Not long after, there was a flurry of HR, Ops or even Marketing or Finance rushing to “become Agile” and at first, it looked like a worthwhile exercise except instead of it being “These are the principles behind Agile, this is the manifesto, do we *get it*? Do we all feel them in our bones?” type of true mindset change effort it became a deluded attempt to simply emulate process and use the same tools- “This sprint, let's all use Trello and send it off to be approved and road mapped where the line manager can align requirements”.

Meanwhile, in IT, they had not only comprehended the importance of the deep change but they had brought in the people to help them keep honest about that realisation and the ushering of the new types of coaches in actually opened the door for guidance and help for the rest of the organisation too.?

And coaching isn’t the only example of when IT drove needed change of attitude or tools.?

Cast your mind back a few years to the adoption of Slack - how many Comms departments had veritable cows over that topic? And what about the infamous cloud migrations - how many holly-backend-protectors chained themselves to the servers so that nothing budges?

How about Dojos - they can’t have been an easy sell to get over the line in front of the “concerned” HR and L&D stakeholders who believed they fostered that same amount of extreme learning, collaboration and experimentation at large. Even today, many organisations that did create Dojos, seem to keep them as the grass-on-wall innovation department 2.0. They are often a marginalised and tolerated structure not the beacon of POCing and experimenting while teaching people practical skills to increase the performance, that they were meant to be.?

Not to mention the huge one that’s current and painful now and how it comes firmly from the DevOps community - servant leadership and the way it reflects in the new reality of hybrid. No one before them spoke of being truly helpful, removing blockers and getting out of the way. Not really. Not truly. The conversation was stuck in the “manager” versus “leader” rhetoric and peppered with inspirational examples and never went into the exact behaviours that are the opposite of command and control and how to achieve a mindset to support them. Talent and Learning and Developments departments everywhere look at the topic as it is laid out by the DevOps community and roll their eyes seeing it as a fad and not the radical change sorely needed and that eye roll allows them the perceived license to not tackle the big topic that it is.

This same mistrust and lack of support from the organisation is what smart IT leaders face when they say “This Psychological Safety thing - we need our teams to have it. It’s not a nice-to-have, it’s an imperative in the way we work. We need to know how much of it we have and we have to find ways to make more of it because it’s the secret sauce that helps us make things faster that are better. No, it’s not “engagement”. No, your annual survey is not good enough. No, we don’t need you to organise another awareness program or give us another lecture about modelling vulnerability, thanks. We need this tool and we need you to recognise these people for doing the people work and we’ll take care of it.”

Helping everyone understand that the people work is needed and that it has been distributed to the team’s level and now the team needs to integrate it in their work and they need the tools to do so, is at a minimum tough work and in some cases a veritable and super-frustrating Sisyphean task.?

I firmly believe all of this tragedy and discomfort of battling the organisational resistance while trying to drag them kicking and screaming into competing, sustainable and fighting shape fit for going head-to-head with the smartest and most innovative shops is temporary. Fast forward 10-15 years and most teams will have:

• A hybrid set-up they have agreed on;
• A servant leader to inspire and help;
• Open and honest communication, a thirst for experimentation, low impression management, extreme trust in each other, no fear, emotional closeness, a sense of purpose, impact, belonging and joy;
• Flow;
• DevOps pipe magic (insert the darlings du jour- the architectural models and supporting software to build it)
• All the tools they need to go fast and do the technical work and the human work too i.e. half the screen will feature Jira in a Retro and the other half PNT’s Team Dashboard to see why is it that what happened came to pass)

Above all, they will be higher performing and much happier and perhaps fast forward another 10 or 15 years, history would have already recorded the true fact that had it not been for the Agile/DevOps community then the change in mindsets, organisational structures and ways of work that was so sorely needed to deliver on the promise of technology and compete with non-legacy-sufferers, could have taken double the time to implement or could have well never came in time for the organisation to?have survived at all.?

—————————————————————————

The 3 “commandments of Psychological Safety” to build high performing teams are:?Understand,?Measure?and?Improve

At?PeopleNotTech?we make?software?that measures and improves Psychological Safety in teams. If you care about it- talk to us?about a demo?at?[email protected]??

To order the "People Before Tech: The Importance of Psychological Safety and Teamwork in the Digital Age" book go to this Amazon?link