Collaboration – as part of Enterprise Agility
I am often deeply entrenched in Enterprise Agility, Organisational Change Management and everything which comes with it on a daily basis. In my last post, I discussed very loosely how *I think* Agility should be dealt with. It’s something I preach every day to people far and wide. I also speak often about the people element of change and the impact it can have.
Recently, a great article from Lisa B Kwan centered around the blind spot’s created by enforced collaboration got my interest, and it ties into my last post so I wanted to explore this topic a bit more especially as I’m often rolling out collaboration efforts, teaching techniques or enforcing it within organisations. I also want to document some of my wins and failures!
Collaboration – it’s such a ‘thing’ now. Whether it’s collaborative software, collaborative work-spaces, collaborative teams, you MUST collaborate. Share, involve, include. This is how we do things. But sometimes it comes with a number of pitfall’s. Let me give you a bit of my perspective.
Being comfortable with the uncomfortable.
For many years I was often unaware of the impact change had on people. Being somewhat comfortable with constant change myself and often finding myself at the ‘whip’ end even in the earlier parts of my career (probably because I was a do’er) I was often insensitive to the people element of change and why often, everyone around me was reluctant to it with my attitude being they ‘just weren’t team players’.
I’d butt heads particularly with technical teams who always seemed completely resistant to collaborating with any other part of the business. They would seemingly bottleneck projects, confuse and obfuscate communication and generally not play any part in collaboration. I’d start projects with the best will in the world laying out solid proven and tested ground rules but could almost always guarantee a Development team would de-rail it within days though indignant lack of sharing. Sharing of knowledge, sharing of time, sharing of help. I often labelled them a ‘problem’. The archetypal ‘Developer effect’ whereby the stereotype we often have in our minds of Developers seemingly ringing true.
Over the years as I’ve *hopefully* developed my Management and Leadership maturity, I’ve discovered really getting to know the groups of people within an organisation and looking at things very honestly and clearly from their lense, can really help understand where the potential pitfalls could be, when trying to install collaboration into the collective mindset. I mention in my last post that change has to start from the top. It really does. But as a strategic goal, identifying the nuances and differences in teams and departments from the ground up can help you hone and personalise any change programme much more effectively. But you need to invest time to do this.
How do you do this then? You ask questions. You spend time within that Department. You learn their problems. You learn their mindset. The world of business has changed, and being sensitive to how different generations of workforce may wrestle with the idea of collaboration will help you understand how to tackle it.
Understanding how groups work – Being a Tribal specialist.
Often forgotten, and Lisa also discusses this and labels it as such, understanding what makes a group tick involves understanding three principles;
- Identity
- Legitimacy
- Control
Who do people believe they are? What do they stand for? (Identity) How are they integrated into the business, and therefore valued (legitimacy) and being trusted to be autonomous, and to effect change (control).
I translate these three often into one core question;
- Is the desire/instruction to collaborate honest or is there an ulterior motive
The above are key tenets with employee’s and typically groups of employee’s working in Departments and although seemingly common sense, we often forget to as leaders, think about the threat and identify these core dimensions. Instead (and I’ve been guilty of this) rush into the ‘doing’ which actually increases counter-collaboration. Rolling out an automated customer service bot single handedly and simultaneously threatening the validity of an entire department, automating Google analytics and Power BI reports to a point whereby the Data team are not needed, the list is somewhat long and that’s’ before we get into the thinly veiled guise of departments training their replacements! These scenarios aren’t going to encourage collaboration and I’ve been involved in them all!
Up to a third of value-added collaborations come from only 3% to 5% of employee’s
An example threat.
Automation threatens everything. In fact a peer of mine James Hedges has recently been involved in the authoring of a great deck discussing that very thing. Automation threatens jobs at a scale many of us are not yet fully capable of understanding. The change to the workforce and business will be considerable. The impact to jobs that things such as chat-bots with Machine Learning baked in, automation of big data manipulation and reporting, chunks of Supply Chain management and warehousing and even more old-fashioned things like Customer Service means people will lose their jobs. Replaced by efficient algorithms, Neural Networks and Intelligent bots. But I’m ok, because I’m at the end which deploys the change. So that’s ok then. Right? You see – there lies a real example.
Nobody wants to lose their job. Nobody wants to feel less important in their role because the business they are in has decided that their twenty years of experience can be replaced by a bot. Sure the business can call it ‘streamlining’ or ‘Operational Excellence’ or ‘Agility’ but that’s useless when you’re staring into the barrel of being replaced by 256 lines of code bought from an online vendor recommended by your friendly change/LEAN/Agile specialist.
What to do in Summary
- Be sensitive to Identity – Consider how change, especially the desire to collaborate can impact the identity of groups, Departments and teams. Deal with that challenge.
- Understand Control – Identify what teams are currently responsible for, be that process, decision making etc and document what collaboration may do to impact that. Take away peoples control, and your change project will stall.
- Don’t threaten legitimacy – It’s obvious to me now but if you’re going to demand collaboration with an aim of merging or shallowing out resource requirement, you can’t wrap it up in a bow and call it ‘operational efficiency’. Really think about how you deal with this.
What I do
I don’t run into enforced collaboration projects without looking over my shoulder for departmental threats. Some people don’t collaborate naturally and that is often fine. I document and chart the key benefits of collaboration between teams are and what value that it brings to the business before then tackling the Identity, Legitimacy and Control triangle. Only then can a map be developed to install collaboration change.
I also consider what the impact is both perceived and actual of any collaboration effort. Is that impacting any of the dimensions mentioned above threatening any of the dimensions of the triangle, how and what can be done to help smoothen that out.
Further Example Threats
For me, two key comment threats (regardless of being sensitive to the human element), I see and have learnt to identify;
- Territorial Demands – Watch for the groups or Departments that encourage a tail-wagging-the-dog situation – Development teams dictating to the business, IT departments controlling the business and being purposely confusing, maybe by dumping so much information from so many sources in such an un-ordered format, it means nothing.
- Departmental attacks – If I see departments being super critical of other departments it often sets alarm bells ringing.
An issue often collaboration causes is there is often less time to do actual work. We often spend and encourage meetings, stand ups, conference calls it leaves less time to do work. You really have to think about this when selling in the benefits of collaboration.
