Analytical 35: Competency

12 January, 2019


In every broad discipline it’s become impossible for one person to be competent in all aspects. Organisationally speaking, we look at how we could ensure a collective competency is maintained.

Transcript available
[Music] Everything can be improved, iterated and refined. If you don't think that's true, maybe you haven't analysed it enough. Calculated Choices, carefully considered, absolutely analytical. This episode is brought to you by Clubhouse, the first project management platform for software development that brings everyone on every team together to build better products. Visit this URL, clubhouse or for more information. We'll talk more about them during the show. Analytical is part of the Engineered Network to support our shows, including this one. Head over to our Patreon page and for other great shows, visit today. Competency. Now, in episode two, I actually talked about differentiating confidence from competence. And I've written a white paper, a long form article, whatever you want to call it, called Nobody is Competent, We're All Human. And if you haven't listened to or read those, you probably should first, as sort of preliminary material, because I want to lead in from those on this episode. In recent years, I've been confronted with an interesting dilemma, and frankly had a reasonable realization recently. There are so many individual technical issues in any given discipline that you might like, like electrical engineering, like I am, mechanical engineering, computer software development, the list really does go on and on. It's simply not possible to be conversant in every single one of them, in any one of those disciplines. Now, if you think about the frailties of our human memory, and that's something that I discussed in the first point of the Nobody is Competent article. So, just to recap on that quickly, our brain is continuously bombarded with new information, sights, sounds, smells, and events that push other knowledge aside inside our minds. And sometimes the information that is pushed aside is critical to the task at hand and can either slow down or stop work until sources can be cross-referenced to confirm what was once a known fact and has since become a more vague recollection." Ending quote there. So personally, I've been surprised from time to time when I've pressed my memory on a specific technical detail that I'd learned maybe, I don't know, a decade ago, something like that. And I've been absolutely convinced that I recalled that detail correctly. And then I need just to find out that the actual fact when I went and did my fact checking, it was just slightly different. And it was different enough to make a difference. And that's why things like refresher training is so vitally important and depending upon the complexity of the task, that needs to be refreshed more regularly. Sometimes once a year, maybe every two years or three, maybe five years or so, but usually not longer than that. And one more thing to consider, mastery or competence in a set area, set area, it can be considered to be a time exposure measurement. What I mean by that is that if you let's say you spend one year focused on a specific set task in a specific sub-discipline within your discipline, let's say. So in the parlance of computer programming, perfect example, you spend a year programming in Java. Sorry about that, but hey, it happened. So that set task at the end of that year, you're going to reach a certain level of competence. Maybe, I don't know, for the want of a better word, moderate competence, whatever, however subjective measure you want to use, I suppose. But if you did two years of that, it would be more significant. You know, if three years, maybe you might call yourself an expert, again, in Java, sorry about that. But that's a bit vague and it's arbitrary. And that's not the point necessarily. It's just to highlight the fact that if you wanted to make it less arbitrary, you'd need more specifics in that area of competence in question, you need to set exams and run courses in order to set like standardized expectations, and then you could test people against them and all that other good stuff. But look, let's just not worry about that. The point is that would be the way you would measure it. But since it's going to be arbitrary, just to make the point, the point is the longer you're focusing on that, the more experienced you get, the more competent you get. I don't think anyone would challenge that. Generally speaking, that will be the case. So, what people fail to consider, generally speaking, is that when older areas of knowledge, what happens to them when you're focusing on learning this new sub-discipline, this new technical expertise that you're developing? What happens to all the old things that used to be your areas of expertise? What happens then is those areas of knowledge, as your current area of focus advances, the other unfocused areas begin to decline. So, the truth is, we're essentially trampling on our old areas of competency with the new areas of competency that we're currently learning. So, our new competence essentially tramples on our old areas. So, we're in a constant battle, really, a never-ending battle with our own minds in terms of retained experience. So, if you consider all of those things and your job is to ensure that you have a competent technical part of an organization. How can you actually deliver that? Before we go any further, I'd like to talk about our sponsor for this episode. And that's Clubhouse, the first project management platform for software development that brings everyone on every team together to build better products. Clubhouse was built from the outset with agile development in mind, with an intense focus on intuitiveness and responsiveness, with their web app backed by Fastly CDN it really feels like a local app on any platform you might be on. Clubhouse delivers developer-centric tools for everything from Kanban boards to Epics, Milestones, Cards with different card classifications for features, bugs and chores but it's more Clubhouse's ability to interconnect all of them together that makes it so impressive. Users have reported creating less duplicates, navigation is very fast using a common board but with as many configurable workspaces as you like to customise that board for whatever purpose you might need. Morning stand-ups for different teams, sub-teams or all the teams, it's entirely up to you. Ultimately, any collaborative project management platform has to be as low friction as possible and not just for software developers, but for everyone in the organisation. Marketing, support, management, you name it, the lot. So everyone can contribute and actual collaboration actually happens. Finally, the other part of Clubhouse that really shines is its ability to zoom out from individual tasks to the overall project status that not only keeps project managers happy, but keeps the team connected to how their part contributes to the greater project and keeps them focused on what matters, delivering a result their customers will enjoy. There are others in the market, but they're not like Clubhouse. And what makes Clubhouse so different is the balance between the right amount of simplicity without sacrificing key functionality, structured to allow genuine cross-functional team collaboration on your project. Clubhouse is a modern software as a service platform with seamless integrations for popular tools like GitHub, Slack, Sentry, and lots more. And if the tools that you want to integrate aren't available out of the box, an extensible REST API in Clubhouse makes those integrations straightforward. If you visit this URL, clubhouse, or one word dot IO slash 10 the word, you can take advantage of a special offer for Engineered Network listeners. Of course, you'll get the 14-day free trial, but if you sign up, you'll get two months free. And because this is a team-centric solution, this offer will work for your team, not just you. This offer is only available to Engineered Network listeners for a limited time, so take advantage of it while you can. Thank you to Clubhouse for sponsoring the Engineered Network. So how can we actually deliver a department in an organization that is competent in the areas that it needs to be when it is such a broad area of expertise. If we call it a discipline and it's got, I don't know, let's say 50 or so specific areas within that discipline that you need to have a certain level of competency in to be sure that you can make informed, correct technical decisions, how do you do that? Clearly, it's impossible for that to be one person. And if we, just referring back to the nobody is competent article, you need a second person to cross-check, peer review, double-check, validate, verify, sanity check, review, pull apart, critique, provide a second opinion, a different perspective, get their thoughts on, I should probably stop with the synonyms there, but at least two, but for them to be effective, they each need to have approximately equal areas and levels of competency, which means two people with 50 areas of equal competency is equally as unlikely or essentially impossible as if it was one person. Let's say due to relative complexity, an average human could maintain 10 or so, let's say, of those areas in any given year. So ideally, then you would split those 50 areas between five people. Each of them would take about 10 of those sub areas. So then your continuing professional development trains up each person in different areas of their competency in a rotation, such that in five years, they return back to where they started. This way, each person in the team has an increasing competency in more areas as their older knowledge fades into the background. Of course, they're all just random numbers, right? And complexity, natural talent, business distractions, all this impacts everything. But ultimately, they tend to drive the number of people higher, not lower. Of course, all of those rough calcs don't even include things like employee turnover, churn, rehiring, hiring, rehiring, you know, illnesses, projects, accommodates, which are commonplace as well, and so on. Once you have these realizations, the only way for any organization to maintain useful competency in a broad area of expertise is by achieving collective competency. And the only way that can happen is by, well, first of all, retaining technically competent people. got to start there. And then ensuring every individual has some overlapping and some unique competencies. Also ensuring the collective whole of people in the organization present no competency gaps. And actually, you know, you should probably first make sure you figure out what competencies you actually need before you do that bit. Otherwise, you won't know if you have gaps. And then of course, you need to invest in training for your people to extend their competencies in a coordinated fashion. And before you think money, money, money, training does not have to be formal training, although that's obviously preferable in many cases. It can be peer training and it can of course be on the job hands-on training, but you have to allow extra time and space for people to learn and to absorb and not expect them to produce at the same rate as if they weren't learning a new skill anyhow. So just to wrap this up, I just wanted to wrap it up on an oldie. I mean, it's an oldie, but it's a goodie. And when I say oldie, I mean, it's like 6th century BC, a bloke called Aesop wrote a bunch of fables. One of them was the four oxen and the lion. And from that one, popularized the expression that was derived from the story, "United we stand, divided we fall. And only when you have a unified, united approach when maintaining a collective competency can you actually have confidence you have a truly competent coverage. And anything other than that, well, you pretty well don't. If you're enjoying Analytical and want to support the show, you can, like some of our backers, Carsten Hansen and John Whitlow. They and many others are patrons of the show via Patreon and you can find it at or one word. Patron rewards include a named thank you on the website, a named thank you at the end of episodes, access to raw detailed show notes as well as ad-free higher quality releases of every episode. So if you'd like to contribute something, anything at all, there's lots of great rewards and beyond that it's really, really appreciated. Beyond Patreon there's also a PayPal for one-time contributions at But if you're not in a position to support the show that way, that's completely fine. There's lots of other ways to help. Leave a rating or a review on iTunes, favorite the episode in your podcast player app, or share this episode or show with your friends via social. All of these things help others discover the show and can make a huge difference too. I'd personally like to thank Clubhouse for sponsoring the Engineered Network. If you're looking for an easy to use software development project management solution that everyone can use, Remember to specifically visit this URL clubhouse or one word dot io slash 10 the word to check it out and give it a try It'll surprise you just how easy it can be Analytical is part of the engineered network and you can find it at engineer dot network and you can follow me on the Fediverse at Chigi at engineer dot space or the network on twitter at engineered underscore net We also have a youtube channel with more content going live regularly for your convenience Accept nothing, question everything. It's always a good time to analyse something. I'm John Chichie, thanks so much for listening. [Music]
Duration 14 minutes and 50 seconds Direct Download
Episode Sponsor:

Show Notes

Links of potential interest:

Episode Gold Producer: 'r'.
Episode Silver Producers: Carsten Hansen and John Whitlow.
Premium supporters have access to high-quality, early released episodes with a full back-catalogues of previous episodes


John Chidgey

John Chidgey

John is an Electrical, Instrumentation and Control Systems Engineer, software developer, podcaster, vocal actor and runs TechDistortion and the Engineered Network. John is a Chartered Professional Engineer in both Electrical Engineering and Information, Telecommunications and Electronics Engineering (ITEE) and a semi-regular conference speaker.

John has produced and appeared on many podcasts including Pragmatic and Causality and is available for hire for Vocal Acting or advertising. He has experience and interest in HMI Design, Alarm Management, Cyber-security and Root Cause Analysis.

Described as the David Attenborough of disasters, and a Dreamy Narrator with Great Pipes by the Podfather Adam Curry.

You can find him on the Fediverse and on Twitter.