Books for software engineers and managers

Back to Articles

Look for natural  talents

by Brian

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:

  1. A recurring pattern of thought, feeling or behavior
  2. Productive application

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?

Starter list for engineering talents

Below is a starter list for considering what recurring thoughts, feelings, and behaviors your engineers may exhibit:

  • Following direction
  • Dogfooding
  • Developing interactive experiences
  • Staying current with new technologies
  • Monitoring
  • Optimizing for conversions and churn
  • Cleaning up and refactoring
  • Engineering data systems
  • Automating systems
  • Securing systems
  • Innovating
  • Energizing the team
  • Enhancing team productivity
  • Planning around tech debt and opportunities
  • Managing projects
  • Reducing WIP
  • Driving business outcomes


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.

Engineering Team Talent Matrix

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.

Drake Innovating +

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.

Look for natural talents