New Hire: Project Selection and Execution

Over the years, our engineering team has grown from a dozen super-talented individual contributors to a hundred-strong organization with teams, specialized roles, and responsibilities. With that growth came a need for better mentorship and training. Various initiatives were focused on taking common learnings and evolving them until they were mature enough to be reused for teaching others. However, certain pieces still need to be tailored to each new hire and two in particular can have a huge impact on creating awesome developers and teams:

  • Selecting a first project
  • Setting expectations

Why is selecting a good first project so crucial? Think back upon your first time writing code and how easy it was to get discouraged. Legacy codebases are full of unfamiliar paradigms and clever, complex snippets that require layers of assumptions to understand. It’s easy to forget these difficulties, especially since we usually assign more experienced developers to be mentors.

Some “toss them in the fire” types believe that struggles lead to learnings, and more struggles lead to more learnings. This can be true, but optimal learning happens just past the zone of comfort and everybody has a different threshold. Failing to find an appropriate balance can easily cause new hires to feel demoralized, unempowered, and/or ineffective.

So, what criteria should be considered when choosing a first project?

Minimal Complexity How much knowledge do you really need to finish the task?
Captures Interest Will he/she be engaged or bored with this project?
Useful Learnings Will they learn anything that can be applied frequently in other projects, or in their career?
Potential Progression Can the task be extended to a larger task/project?
Minimal Dependencies Do other tasks depend on this?
Does this task depend on key individuals? E.g. person A from other team B
Available Assistance Is it clear who they can go to for help if/when blocked?

How do we know when we’ve done well? It depends on our mentee; so develop a habit of gathering perspectives and feedback continuously. Giving mentees a choice of projects beforehand can help to avoid issues earlier. Transparency about the process itself will help your mentee grow to be a mentor.

The other piece that goes hand-in-hand with project selection is project execution. Mastery is built through repetition, so focus on the details of execution that always apply no matter what problem is being solved. Examples include the importance of risk assessment, understanding use cases, impact, trade-offs and dependencies.

Why is this so crucial? It sets a clear and high initial bar for individuals but also importantly; it defines and shapes the team’s culture.

Changing a team’s culture is hard. The usual approach involves introducing processes, top-down mandates, value/mission statements, or team building exercises. I’ve found that a more effective way to introduce a culture change is to create the illusion that new expectations are the standard for new hires. They have both the objectiveness of a pristine perspective and the motivation to learn/adapt to a new environment necessary to embrace such a change.

Examples of bad habits/culture that can be changed:

  • Information silos
    • Teach the new hires, but also encourage them to spread the knowledge
  • Lack of ownership on failures
    • Always provide transparency (at an appropriate time) on emergency production issues and short-term/long-term fixes
  • Careless code reviews
    • At Medallia specifically, our culture of feedback comes through in the code review process; it is not solely a style/correctness check but an opportunity for sharing perspectives
    • Enforce minimal turnaround time
    • Clearly differentiate optional nitpicks from issues with more lasting consequences
    • Provide references to learning materials or examples in the codebase
  • Ignoring technical debt while building features
    • This applies situationally, but e.g. migrating usages of FluentIterable to Java 8 Streams can be done incrementally
  • Ill-defined requirements
    • Strive to minimize the risk of frustration in work given to new hires
  • Flaky or slow unit tests
    • If it’s embarrassing to explain it to the new person, then fix it, or let them be part of the solution

Sure, we should always strive to do these things. However, a new hire provides an amazing opportunity both for the individual and the team to jump start on new habits or pick up things that have slipped. They deserve that extra effort to set a solid foundation for a team’s journey.

There’s nothing worse than wasted potential.

Leave a Reply

Your email address will not be published. Required fields are marked *