Taking Care of Your Talent

Clean Tools are Happy Tools!

(BTW, just wanted to give a shout out to Darren J. Silk BA (Hons.) Arch. ACIAT FRSA for the cover above; his passion for the craft is truly an inspiration, leading me down my newfound love for carpentry. Feel free if you want to stop by to see the workshop!)

In the previous articles about mental health and psychological safety and software project team considerations, we discussed the importance of having a (mentally) clean work area and having reasonable expectations for the tools (...ahem, people) that will be working on software projects for the organisation. This article will now touch on some topics regarding the project team members and how to transform them into a motivated work force.

But before proceeding forward....

An abrupt reality check

....I would like to say something regarding the analogy that people are tools. Throughout this series, the idea that people are tools is to be taken in jest and only for the purposes of this analogy. In reality, however, people are not tools, and most importantly people are not resources, as the term "resource" implies that people are an accepted cost that can be expended, and eventually replenished or replaced. This is not the case, hence this article, Taking Care of Talent. If my tongue ever slips and I accidentally refer to people as resource, please feel free to get one of my former managers, Anup Pareek , to set me back on the right path again.

Now that the random reality check is out of the way, onward and upward!

Are your engineers really experts?

Gary Klein (author of Sources of Power) makes a clear distinction between expertise and experience; it is common practice to equate years experience with a level of expertise without considering other factors. However, Gary Klein states:

"Expertise should not be confused with experience, as the two are quite different. Expertise is, in fact, a combination of knowledge, experience and imagination to instantly create a mental simulation around a given situation"

Why is this important when it comes to selecting members for a project team, or even recruiting new software engineers into a company? I cannot remember how many people I have interviewed over the years, but one of the things that does stand out is how mismatched their years in industry are with their performance during the interview.

However, when ensuring that members of a project team are most appropriate for the task at hand, an emphasis should be placed on potential. Even though software projects have rapid turnaround times compared to their construction counterparts, risk is omnipresent and failure is unavoidable. The value those team members deliver is how to iterate and do things better, regardless of whether the project is doing well. Ahem... continuous improvement or something agile-like.

But why aim for potential? For you KPI-driven folks in the back: opportunities for training growth is a retention tool (Management, David Boddy); caring for your employees is more cost-effective than hiring new ones and also helps maintain psychological safety in the work environment. Coincidently, this topic also creates a nice transition for the next section (it's as though I actually put some thought into these things for once!)

Caring for the craft

Here is where software engineering and wood working diverge ever so slightly. There will always talk about how important training is, and that dedicated learning time should be standardised across the industry, but how committed is an organisation to making sure people have adequate time to learn for the benefit of the business?

As David Boddy had mentioned within his Management and Management Theory works, training and opportunity for growth is a proven retention tool; in addition to retention, there is also a wide range of incentives for a company to have a robust training management package as part of its benefits (I would cite Boddy again, but I think it would also be good to look at blogs from industry as well. Don't worry, I did fact-check the content against own readings and empirical research).

The initial reaction to this kind of challenge would be to stand up some dedicated learning time, once every week or every two weeks, where engineers can go learn something of their choosing as long as it links to the business. During this time, I have seen engineers go learn new programming languages, frameworks, architecture, etc. While all these things are fine, there is one thing that I have encouraged others to go learn: domain knowledge.

This is where software engineering and wood working diverge. Wood working itself is the domain; there are requisites of some basic subjects such as algebra and geometry, but its true domain knowledge rests in biology (wood species, humidity impact, treatments) and physics (joinery strength, load tolerance, fixing attributes); this level of detail is what separates a novice from a master of their craft.

Software engineering, as a craft, is fundamentally without context, and needs to be applied to a particular problem, a user story as Agile describes it, in order to have meaning. This is why Domain Driven Design (Eric Evans) is such an important approach; it teaches engineers to look at code underneath the lens of a specific context. As Gary Klein (Chapter 9, Sources of Power) discovered in his research: the iterations of training the research subjects had gone through were proven to be ineffective in the absence of some, or even all, of the operational context.

"Domain knowledge is essential in applying training to a given situation."

As a visual aid, we can use the following diagram to see where domain knowledge fits in the overall composition of an individual's expertise:

As displayed in the diagram, domain knowledge can come from an overlap of experience and knowledge; in the case of software engineering, this would be experience in a particular industry, i.e. financial or retail, and knowledge on how to implement the services needed to support those use cases. Not supporting the team's development of domain knowledge will limit their potential to achieve

Protecting your investment

People, just like tools, are the most precious asset of the business. Just like a carpenter cannot function without the correct tools, an organisation cannot run without the appropriate people in positions where they would be most effective; this includes both internally and externally to the project team. Unfortunately, due to the array and complexity of functions within a project team, the value of people is not as easily apparent as the value of tools which are relatively straightforward. However, value in this context, is not monetary, but rather the perceived benefit the tool (person) has to the project.

Please consider the following:

• I need to fix together two components using nails. In this context, a hammer has clear value because it has a function that addresses a need.
• I need to connect together two services through an API. It is not immediately clear how many or what level of engineers I will need given the complexity and unknown scope.

Unfortunately, the value of an engineer in the given scenario is subject to bias created from experience. For example, if I, as a CTO, had seen seemingly similar work performed in the past by one software engineer, one of my reactions could be to take that experience and apply it to the new situation, despite the possibility that the current problem is more complex and would require more engineers. The CTO may ask, "why do I need a whole team? I saw one guy do it once before". In this situation, the value of the project team working on the API has diminished significantly based on anecdotal evidence;

But what does perceived value have to do with investment protection? A significant amount of tools become lost or stolen every year, and we can equate the idea of "lost or stolen" to employee attrition, as either having been fired or quit themselves. The software engineering industry has one of the highest attrition rates, ranging from 13-20% annually.

How protecting your people from potential offers is more than just paying them well and keeping them from feeling burnt out. Positive reenforcement such as understanding the value an individual has to a project and showing appreciation for such (doesn't always have to be monetary) is also a retention tool. Public recognition, shout-outs, and new opportunities for growth and investment are all alternative means of rewarding outstanding individuals. A random, spot poll shows that people would value a mentally-healthy work environment over a higher-paying one (yes, it's a small poll, but the result is interesting none-the-less).

Closing Comments

We invest a great deal of time in taking care of our tools, ensuring their edges are sharp and free of rust. Agile software development practices already sets this precedent by way of planning and retrospective, but project and engineering managers need to go beyond if they want to foster expertise from within the team. There is a significant amount of investment required to create an elite engineering team.

And that is an investment that we should protect as well. Just as we treat tools as something that is at risk of being stolen at any given time, we should also hold the same caution with people as well. As previously stated in other articles, the cost for hiring new talent is high; it is proven that it is more cost-effective to train from within and maintain high retention rates. And retention is not just about paying above the market rate, it is also about creating an environment where the individual can freely and willingly demonstrate their value.

I would like to attribute this article to some old colleagues of mine. In addition to Anup, Hemal Varambhia , Kannan Ganesan and Shrenik Patel have all taught me the value of perfecting one's craft and valuing continuous growth. Thank you all!