Photo by Nick Fewings on Unsplash

Competence, Clarity and everything in between

In more than one of my roles as a head of engineering I was faced with a dilemma, how to enact organisational and cultural change with a junior (albeit enthusiastic) team of engineers. No longer could I tackle the complex tasks and wait for the team to mature organically, we needed some major work done. I had my doubts and speaking to a colleague of mine he introduced me to “Turn the ship around!” by David Marquet. Just as “The Phoenix Project” opened my mind to new ways of handling process and tasks “Turn the ship around!” helped me realise what I needed to do to bring people on the journey.

Synopsis

David Marquet took charge of the USS Santa Fe (the worst performing submarine of the US Navy) after training to take command of the USS Olympia, a completely different breed of submarine. What he observed was that his lack of knowledge of the Santa Fe combined with a rigid command and control structure was a recipe for disaster with potentially life threatening consequences. He recognised they could not continue in this manner and sought to develop two key pillars in his crew. Competence (can they technically do their job) and clarity of purpose (do they know why they are doing their job). I decided to apply the same methodology to my new teams.

Competence

Photo by Tim Mossholder on Unsplash

Measuring competence is easy right? You study, you get a certification and boom you are done! Well…yes and no. In my experience studying a subject is like learning vocabulary and grammatical rules of a language, it does not fully prepare you to speak fluently, this takes practice. As a leader I found it beneficial to approach this from an agile development standpoint and select minimal courses which educate engineers just enough to gain context and achieve their immediate tasks. But how do you measure this?

The solution was an extension of my existing One-to-one sessions to incorporate the Feynman learning technique. Positioning myself as the student my engineers began lecturing me on what they had learned and teaching me. This gave me opportunity to assess their competence, guiding future development goals but also allowed me to question them and make them realise where their knowledge was lacking without criticising them.

In terms of practical applications of their knowledge we could continuously re-frame the conversations to a task level context in their work and make them see the application of knowledge as well as the theory. This gave me hard data by linking their development goals directly to their ticketed work.

Clarity

Photo by Ian Schneider on Unsplash

Knowing how to perform a task effectively and correctly is seldom satisfying on it’s own. To create driven, purposeful individuals who wish to invest their time and fully commit to an effort often require clarity of purpose or a “reason why”. This came in the form of the organisational change we wished to see using GIST planning techniques. The quick summary here is:

• Goals: A desired end state of your organisation, business unit or team
• Ideas: Initiatives which could satisfy the goals (these are not set in stone and may be iterated frequently)
• Step-projects: Short term efforts which bring an idea into a reality
• Tasks: Individual tickets, cards etc in a step-project assigned to individuals.

This can be used for product development but also for enacting organisational change and a good GIST plan not only brings your community of engineers around a common goal it lets them see how their individual tasks or step-projects contribute to a greater good. This in essence is a clarity of purpose.

In a practical application consider an organisation with the following:

• Goal: Better security posture of a web based application

This is a high level objective with may moving parts so lets break it down:

• Ideas: Code and infrastructure auditing, continuous pen-testing, assigned reviewers, locked down application accounts

Now on the surface these all appear great ideas (and they are for different people) but consider what is most actionable and effective for a team first. Let’s go with step-projects for code and infrastructure auditing.

• Research and trial code analysis tools such as sonarcloud.io
• Research and trial IaC tools such as tfsec, checkov and terrascan

This covers code an infrastructure but also gives engineers an immediate objective for the larger goal. The last step is to try them out and implement them. This has been an effective way of smaller teams driving improvements within their own team space but also taking those improvements into wider organisational scopes.

In between

Photo by Hannah Busing on Unsplash

Now everything is sounding pretty rosy and easy so far, the team is clear on objectives and has the competency to carry them out. What is there in-between? Well, in a military or naval setting people have their assigned role and responsibilities and do not deviate. In a software development world this is not the case, in fact the concept of T-shaped individuals or cross-functional engineers is paramount to success. Often this can lead to multiple solutions being presented and conflict about which one is best. In some cases engineers are perhaps just not enthusiastic about the assigned tasks. This is where the engineering leader usually needs to intervene. There is no magic bullet here but there are some rules of thumb I have found particularly effective:

1. Let engineers pick their step-projects and tasks according to their development goals and place emphasis on unknowns as opportunities.
2. As best you can guide the team towards time-boxed efforts so there is not only an end goal but a deadline. This should ideally be within a single engineering cycle but no more than three cycles.
3. Encourage pairing on step-projects where possible, working in a vacuum is a great way to create conflict however working as mutual partners often yields better results.
4. Get used to breaking the rules. Now I don’t mean throw the book out the window but consider whether you and your team is working within the status quo by default and challenge it.
5. If you find yourself in the unenviable position of being a tie-breaker and pushing an agenda directly then circle back to the engineers you may have overruled and take some time out to walk through your reasoning to get them on board. This is perhaps the most important as it affects future efforts not just the current effort.

Good luck leaders and remember your people come first!