Talent is a recurring pattern of thought, feeling, or behavior that can be productively applied.
This definition of talent from First, Break All the Rules has two key components:
As engineering manager, your first job is to recognize what recurring patterns of thoughts, feelings, and behaviors your individual engineers exhibit.
What topics make them overflow with excitement? What things do they tinker with on the side? What do they read about in down time?
Below is a starter list for considering what recurring thoughts, feelings, and behaviors your engineers may exhibit:
But more than just recurring thoughts, we need practical application and that requires context. The context of this book is our goal – increasing deployment frequency. It’s your job to imagine how each of these can be applied to increase deployment frequency.
For each engineer on your team, list their talents plus the practical application for the change you seek to make. For instance, let’s say you’re trying to release more frequently. Your team matrix might look like this:
|Name||Recurring thoughts, feelings, and behaviors||Practical application to improving deployment frequency
|Andy||Reducing WIP +
Energizing the team
|When our WIP grows too big, Andy is usually the first person to speak up. If I encourage Andy to trust his instincts, his desire to reduce WIP will provide me with an ally in my push to deploy more frequently.
With this alignment on reduced WIP, Andy will feel more energized and his energy will be contagious within the team.
Staying current with new technologies
|Drake is pretty open to experimentation. I should ask him directly to think about what technologies could help us release more. Or conversely, which technologies and systems are holding us back?
I wouldn’t be surprised to find Drake just testing some new approach in order to answer my question. In fact, I should just look at our past conversations in Slack to see what he’s already mentioned.
|Harsha||Optimizing for conversion and churn||Harsha thinks like a digital marketer. He appreciates “how might we” type questions and divergent thinking.
I need to engage Harsha’s creative side. I wonder what Harsha would recommend if I challenged him to a thought experiment – 10x our deployment frequency.
|Jesse||Automating systems||Jesse hates manual processes. He thinks they’re dumb and inefficient. What areas of our deployment and automated testing systems can I point Jesse toward to fulfill his desire to squash all things manual?|
|Vanessa||Cleanup and refactoring||Vanessa really likes to clean as she goes. In aggregate, these small refactorings really add up by making our codebase easier to navigate and debug, which also helps us decrease lead time. But right now, those refactorings aren’t valued by the company.
How can I publicly celebrate and signal to Vanessa that small and incremental refactorings frequently deployed to production are appreciated?
1:1s are the best time to introduce these talent applications to each team member because you’re speaking directly to their personal interest, not watering down your message for a group environment.