Developing Talent in R&D

Excellence is never an accident. It is always the result of high intention, sincere effort, and intelligent execution; it represents the wise choice of many alternatives — choice, not chance, determines your destiny. — Aristotle

As a Martial Artist, one thing is clear to me: you don’t get your black belt due to “talent”. You get your black belt due to the training you get and practice you put in. I’ve seen many brand new students come in sharing the same weakness and lack of knowledge, which only after a few years they overcome. You’d be foolish to simply look at a white belt and think “You can’t become a black belt”. That’s not reasonable. If they train and practice hard enough, they can!

Yet, too often in the software industry, we are looking for people with intrinsic talent. The “hacker” or “coder” stereotype that’ll somehow prevail and self-learn; overlooking that we’d never expect the same of our lawyers, doctors, electricians, etc. In fact, if you were to actually look at a highly capable Software Engineer’s learning history, you’d certainly notice their training and practice. Whether explicitly designed, or coincidental, they learned and practiced how to be good. If this is how strong performers are developed, how come R&D organizations seldom invest in training directly? Why do so many organizations simply leave it to HR, or give a bucket of money for individuals to self-invest instead?

It seems we are stuck in a mental trap. Business is competitive and training people is hard work, so the path of least resistance is not to train people, but rather to fire and replace people until you get “strong” people. After all, if luck has it your way, you’ll land on that genius Steve Jobs equivalent and make a billion dollars right? Why bother taking the harder and more deliberate route of training? This is a problem for me.

As a millennial in a leadership position, it cannot be all about making a profit. Leadership needs to also include developing people and creating an inclusive space to nurture future leaders. In fact, more so than ever before, people are choosing companies based on their alignment of personal values rather than solely compensation. People are choosing companies based on what they’ll learn, not just what they’ll earn.

What strategy should an R&D department take to be both appealing to future employees and nurturing to existing employees? And how can this be done without losing sight of the competitive nature of business? As a leader, it’s important for me to be able to meet all these objectives. It’s not OK to have people work with you and not become better as a result.

In this post I’d like to lay out how we are experimenting with taking on a more deliberate approach to training and accelerating the talent acquisition process at Diligent. I hope the ideas here encourage your organization to improve and experiment with its talent development strategy as well.

Skill Acquisition Process

There are a few distinct steps that take place in developing expertise. By acknowledging these steps, we can then focus our training system to accelerate people through these steps.

People initially are not aware of what they don’t know (Wrong Intuition). We need to first teach them what they need to know so at least they are conscious of it, even if not yet competent (Wrong Analysis). From there, we ask them to practice it perfectly until they are competent (Right Analysis). And with enough practice, they’ll then build the right habit to not require so much deliberate attention to get it right anymore (Right Intuition). That’s how skills are developed and turned into a habit for an individual.

There are a few key points here that’ll serve as the foundation for the training program outlined further below:

1. You need to teach —people will not magically come to know what the “right thing” is. You need to take yourself, or other leaders, and have them teach how your company applies its technologies and processes to solving problems. This is critical because it’s not Google-able. You can Google how e.g. Terraform works, but you cannot Google why your company picked Terraform, or which source code organizational pattern to use with Terraform for your company. You also mitigate quick “how to” solutioning with e.g. Stack Overflow, which may lead to dated or subpar solutions, when you could have instead outlined a big picture solution via training.
2. People need to practice — teaching gives people the information they need, but not the competence they need. People need hands-on practice to develop that competence, and if you can give them tasks that are directly related to what they were taught, the faster they can build that competence. That practice helps them retain that information longer as well.
3. People cannot learn everything at once — developing competence requires focus and that focus is limited. You need a system that gradually teaches people what they need to learn, and have managers assist individuals in their journey of learning.
4. People need a common baseline— every job is different, so no two people, particularly Seniors, are going to start off the same. Training however can establish shared understanding and shared language; without it, it’s difficult to support or coach each other through the learning process.

Ineffective Strategies

With those basic principles in mind, let’s now reflect on typical strategies organizations use and why they might be ineffective.

• Throwing people into the “deep end” to learn — the “deep end” is as real as it gets, but unless it’s a research activity or you already have strong knowledge of your company’s product and technology, it’s too harsh of an environment to learn in. As a learner, you don’t know what to focus on; furthermore, you do not know why things are the way they are, so you start guessing and potentially developing an incorrect foundational understanding.
• Ad-hoc assistance — if people learn only when they ask you a question, they’ll learn inefficiently. At best, they’ll ask what they think is important to ask about vs. what actually is important; at worst, it creates an environment where people are afraid to ask because the person who asks the most is the “stupid one” thus people persist in ignorance rather than getting help.
• 3rd-party trainers — 3rd-party trainers do not understand your business; they don’t know why you picked a certain technology and the history of other decisions you had made. They’ll come in and teach the technology (in a biased fashion), but people would still be missing how to apply it to your company. Trainers can be effective as part of a larger training strategy; but by themselves, their impact is muted.
• Self-training budgets — if people don’t have a basic outline of what they need to know to be successful, you’ll get random training budget expenditures. Don’t be surprised if you get Machine Learning training requests because “it’s the future, so we should know it”. Such a system is a great complement to an existing training strategy for self-driven learners, but it cannot be the only solution.
• Off-hours learning — last but not least, if your primary strategy is to have employees learn off-hours, you will not build an inclusive environment. Young parents, people with other commitments, etc. simply cannot do this. To be an inclusive place, you need to incorporate training into your culture and project planning. It’s not to say the company is fully responsible for people’s training — it’s a shared responsibility after all — rather it’s more acknowledging that people go through different phases of life and an inclusive place will support every phase. Ultimately, people understand that some individuals will want to move fast in their career and are thus willing to spend more of their personal time; but people still need some company investment to let them know what to train on, why, and some mechanism to get feedback on that training.

These ineffective strategies are common because they are easy for management. It doesn’t take any work to throw someone into the “deep end”, or hire a 3rd-party trainer, or put aside training budget. In comparison, structured training is rare because it’s hard. It’s not that these easier strategies serve no purpose, or that they cannot be used in complement, but they cannot be the primary strategy. We can’t avoid the hard work. We can however focus on making our hard work as effective as possible.

With that said, here is what we’ve decided to do in Diligent and its results so far, so you have a starting reference to consider.

Proposal

Imagine a former colleague of yours wanted to join your company and they asked “What do I need to know to be successful?”, what would you tell them? Not just at a high-level, but the details too. What do they need to know to be amazing once they start? That’s the mindset we want to have.

That leads to two core components of an effective training program:

1. Direct training via training modules
2. Indirect training via processes and coaching

Direct Training

At Diligent we have an internal GitHub repository called highbond-training to store all our training modules, with each folder focused on one particular topic. We use a number scheme of 1xx (Beginner), 2xx (Intermediate), 3xx (Advanced), 7xx (Tactical) to differentiate the difficulty levels.

Sneak peak at all of our training modules so far in Diligent

Each folder has three distinct pieces:
1. README.md — this is the written version of the training module.
2. PRESENTATION.md— this is the presentation version, which we then present using reveal-md.
3. ASSIGNMENT.md — this is an isolated assignment for the individual to practice the content of the training module.

Each folder fully includes everything you need

`reveal-md` makes it fast for engineers to create presentations and store it in GitHub

With each topic, we emphasize teaching what cannot be Googled. For example, take the topic of TypeScript. Here is how it breaks down:

1. Googleable — what is TypeScript, how TypeScript works, the syntax of TypeScript, how to create types, interfaces, etc.
2. Not Googleable — why does TypeScript make sense for Diligent, what tsconfig.json we use and why, where do we store our shared npm packages and types, what development libraries we use with TypeScript and why, how do we capture stack traces with TypeScript and where, how do we recommend transitioning from JavaScript to TypeScript, etc.

For the Googleable parts, we primarily link to credible sources on the web. However, its the non-Googleable parts we emphasize and create an assignment around. This is how we transition an engineer from:

An engineer that knows TypeScript working in Diligent

to

An engineer that knows how to apply TypeScript for Diligent 💪

Typically our training modules are grouped around a topic for a particular quarter. For example, in one quarter we emphasized Serverless capabilities and how to deploy TypeScript AWS Lambda functions using Terraform. For another quarter, we emphasized the Testing Pyramid and Observability, so that we have shared language and awareness of the various testing tools we use at Diligent. And in upcoming quarters, we plan to focus on design patterns, storage solutions, etc. There is a significant compound effect of having multiple training sessions focused on a particular topic, catered for a company.

Training also provides the required history and context to make pursuing new ideas easier and more successful. After all, if you are not aware of your company’s history, you’ll repeat its mistakes. And if you don’t understand your company’s context, your ideas will not be as focused or effective.

Senior Feedback & Recognition

To ensure that people correctly learn the principles of each training module, individuals fork highbond-training and complete their assignments in their own forks. Assignments are meant to take 1–2 working days to complete.

Once complete, they create a PR and send it to an expert for feedback. If the expert verifies their completion, they earn a badge that can be seen in an internal company tool to both celebrate their achievement but also provide insight for the engineering leadership team regarding where people are at in their understanding.

I can tell you that people greatly appreciate such level of training provided by their own engineering leaders. It’s one thing to have a 3rd-party come in; it’s another for your own team members to get on Zoom and share their expertise with the entire R&D department. Trainees appreciate it, and presenters get both writing and public presentation practice.

Furthermore, it immediately brings alignment for everyone in R&D in terms of language. For example, we are a big AWS shop, and as you may know, there is a lot to AWS. So having training sessions on how we use AWS to solve company problems quickly aligns everyone in language and tooling and prevents people from creating similar but divergent solutions. That’s a huge win!

Indirect Training

While direct training modules and assignments serve as a fast way to learn what’s important, it’s the day-to-day coaching and pairing with team members that builds detailed understanding. To support this learning model, we’ve restructured our processes and culture accordingly:

1. Kanban Process — we emphasize a Kanban process that encourages the entire team to finish tasks as quickly as possible and in a serial fashion. This process strongly incentivizes teams to work together, share ideas, and pair to get the job done. We want to discourage individuals from taking on tasks alone, spending many hours trying to “figure it out themselves” when they could have done the task faster and learned more by getting their team’s help.
2. Pair Programming — building on the Kanban process, we also encourage people to pair regularly in order to share ideas and come to solutions quickly. People don’t have to literally code together, but occasionally having two people assigned to a task helps both individuals grow and complete the task faster.
3. Upfront Designs and Discussions — for larger tasks (e.g. Epics or Initiatives), we encourage teams to write a document upfront and share it with other senior engineering leaders in the company. Often a team alone may not be aware of different techniques and nuances, but if they can gather their thoughts on a page (which itself helps train individuals to better structure and articulate their thoughts) it allows senior leaders to provide feedback that’ll help them grow.
4. Inspiring and Challenging Tasks —building a platform to address corruption and governance shortcomings is no easy task, and when building it in a Serverless fashion on AWS, it translates to a ton of interesting tasks for teams, particularly Seniors, to learn from. With an inspiring technology vision, Seniors have an opportunity to further their expertise and leadership skills as they lead their team through ambiguity.

Naturally other typical management processes help here as well, such as 1-on-1s, Career Development Plans, etc. The key is to ensure your culture and day-to-day processes encourage learning and pairing to provide the detailed training an individual can’t get via Google or via direct training. Training is not a one-time event; it’s a cultural mindset of constantly wanting to develop people.

Conclusion

There is a lot to training, and it’s a lot of work. It’s no wonder most organizations don’t have a robust program for it and simply focus on recruiting strong performers and firing “weak” performers. That is unfortunately playing a game of chance, and is not particularly appealing for someone considering to join your company.

Training requires “system thinking” and acknowledging that knowledge and talent do not randomly appear. They appear due to deliberate design and intentional practice. And if we take our engineering mindset, and focus it on creating such systems, then we can create amazing work environments that both develop talent and accelerate our company’s ability to deliver software.

It’s no coincidence that when interviewees at Diligent ask our employees “What do you enjoy about working at Diligent?” a common response nowadays is “The training and how much you learn here”. That tells me our training strategy is working. ♥️