Overview
Over the years we all learn a lot of 'stuff' and some of it is more intricate than others. For many of the day to day things we may do at work, it is a good idea to automate them, or eliminate them by finding better solutions. Sometimes however, there are complex workflows that can't easily be automated, or where the return on investment just doesn't justify the work to do so.
At the same time, we all know how risky it can be for the individual and for the business when there are SPOFs controlling or even hoarding knowledge, whether they do so intentionally or not.
So in those cases, how can we ensure that the person with the complex workflow knowledge (including the 'why', not just the 'what') is not the only person that can handle that task?
This is as much a #devdiscuss topic as anything, but I'll put an answer below, albeit an incomplete one...
Be a billboard, not a vault
It may be a bit of a cheesy expression, but I feel that title encapsulates the thought behind what I'm trying to say quite well.
In my experience, from the 'knowledge holder' perspective it can be difficult to let go at times, especially if you feel that others might not do the job "properly". But the best thing to do is trust your colleagues and let go. In most cases people will surprise you in the best way.
I've had situations where I've held onto certain processes myself for far too long, only to find that when I do hand them over, the other people actually do them far better than I did and often think of things from different angles, ultimately improving the overall workflow.
For example, I recently had a task to analyse a graph of metrics for the past 24 hours, to ensure the system health was at baseline and we had not missed any alerts. When I looked at it, I sort of mentally compared it to previous baselines and made a judgement call that it "looked about right".
Someone new to the process did the same task the next day, and noticed that the graph was showing 'average' rather than 'maximum' for one of the metrics, meaning we were not getting a true reflection of the metric in the context we needed (CPU usage I think it was). Their fresh eyes unlocked a really important insight, much the way a code review uncovers bugs or flaws in 'perfectly fine' code.
Don’t wait, initiate
From the other perspective, i.e. "the team member who doesn't have the knowledge but should", I have found that most people are only too happy to share their workload, especially when it's for tedious work that needs doing, but nobody really wants to do!
In cases where the knowledge holder does not want to share this knowledge, they normally accept that they should be doing so, and can normally be persuaded to do so, even if slightly begrudgingly. This is normally something that business leaders would be in favour of doing anyway, so if necessary can be escalated (though obviously tread lightly as this can be damaging to team relationships if not handled with care).
Team leaders: consistency is key
In leadership roles it is often one's job to make sure the team have no single points of failure or, at least that these are minimised with some form of backup strategy. One of the tenets of modern agile teams is the concept of T shaped developers, and cross-functional teams in general. This does not mean that every single person must be fully equipped and trained to do every single job; that can very quickly become unmanageable and counter-productive.
It does however mean that there should be a certain baseline knowledge level of all the different aspects of a team, e.g. most or all team members being able to do the basic support tasks required of the team, with maybe one or two team members taking the lead in that area, driving improvements such as automation, or otherwise streamlining processes.
This is why knowledge sharing is so vital to a high-performing team, since without it, silos can very quickly develop and lead to a multitude of pain for the team and the rest of the business, and ultimately, the customers and end users.
The biggest challenge with knowledge sharing is making sure there is consistency in approach, in terms of the actual steps taken as well as the quality / detail level applied.
As a leader it can be tough to encourage or enforce standards like this, but this consistency is key to a healthy and high performing team, so should be valued very highly at all levels.
I have been in teams before where if team member A performed a task it was pretty much guaranteed that there would be rework, build failures (normally because they 'forgot' to run QA locally), and compatibility issues when it came to deployments, but if team member B did the same task, it would have great test coverage, work flawlessly, and be forwards and backwards compatible, and even have documentation for how it works (which of course team member A "didn't have time" to do).
The team themselves should be enforcers of their own standards, whether that's during code reviews, passing tickets back to individuals who 'forgot to run QA', or whatever else. Generally, the person in question will start to improve their habits just to avoid the social stigma and rework!
Summary
This has turned into a bit of a ramble, so here's the short version:
- As a knowledge holder, be open and honest and willing to share your knowledge as it not only helps the team, it actually helps you!
- As a team member or knowledge 'seeker', offer help and most people will bite your hand off for it!
- As a team lead, when encouraging knowledge sharing, ensure consistency is key and try and get the team to enforce this themselves; if it's 'top down' driven, it won't be nearly as effective as if it's peer-to-peer.
Over to you
Are you a developer, tech lead or in another relevant technical role? What are your thoughts on this topic? I'd love to hear some good tips for knowledge sharing both from the 'sharer' and 'sharee' perspectives, as well as from a leadership standpoint.
Top comments (0)