In my last blog post, I talked about the accountabilities of a leader in correctly staffing a team, ending on the ongoing evaluation of competency. To be honest, I made it sound like once you get to that point, you’re over the hump. But I think competency deserves its own installment.
Also, in my second blog post in this series I advised you to read ‘Turn the Ship Around’ and if you’ve done so, you’ll hear some familiar refrains here. If not, hopefully this blog will help put David Marquet’s book on your reading list.
How to get competent
When thinking about how best to achieve competence, it’s worth thinking about how you view learning and training. Training is a part of learning, but not all of it, and probably not the most valuable part. We learn by doing, not just by being trained. We don’t learn for learning sake, but rather to be successful at something.
A training program should have a focus on certification, not merely briefing students with relevant information. Certification is a decision point; you pass or you don’t. Put another way, you demonstrate the ability to do the job or you don’t. Certification should be an active barometer of competence that goes beyond sitting in a room for two days in order to receive a piece of paper.
There can also be a hidden benefit to a well-run training program; the increased technical competence can result in an opportunity to delegate more decision-making control down into the organization resulting in greater engagement.
When competence abounds, the last thing we should do is keep it to ourselves. Telegraphing your competence by broadcasting the next steps necessary to successfully navigate challenges is what builds trust within the team. A method prescribed in ‘Turn the Ship Around’ that I have found very helpful is using “I intend to” statements. I coach my teams to sum up their thoughts and perspectives in the form of ‘I/we intend to do X in order to avoid/obtain Y.’
Beyond this deliberate pattern of speech is Deliberate Action, articulating what you intend to do next in order to combat mindlessness. This feels immediately useful in a factory environment, but it’s just as useful in software. Imagine a team member saying, “I intend to delete build 345 because it was the result of a failed merge.” Then the team member navigates and says, “Ready to delete build 345 by selecting delete specific build.” It might sound a little basic, but to anyone who has heard “Oh no, I just deleted all this sprints’ work”, there is merit.
As the leader, you are looked to for the audacious ‘what.’ Stick to the ‘what’, throw in some constraints to shape the playing field, and let the team flex their competency and creativity to find the ‘how’s’ necessary to accomplish it. Specify the goals and the outcomes, not the methods, and let the team shine.
One potentially enlightening measure of competence is the answer to the question ‘would my team follow a bad order, or would they question it?’.
One pitfall in measuring competence is if there is a commitment issue. If there’s a lack of clarity, lack of ownership, or lack of trust, all leading to a lack of commitment, there should be no expectation of competency demonstrated.
As a soft measure, competence is part of the equation for ‘Countability’ if you are a fan of John Maxwell’s ‘17 Laws of Teamwork’. If you can count on the team, you know you have a strong dose of competency.
Marquet describes a state where a team moves from empowered to emancipated. When a team has competency and clarity of vision, the leader no longer wields any power because it’s been delegated to those who can do. And when all is said and done, ‘doing’ is ultimately what it is all about.