Essential onboarding tips for high-performance teams

Getting a new hire up to speed takes up to 3 months or more, but if you’ve only got that time to execute a project, you’ll need your new hire to get up to speed quickly. Here’s how you can use processes and tools to ensure new hires hit the ground running.

In my experience, high-performing software engineering teams need three key things to thrive:

Leadership: Leadership is responsible for creating the conditions for success.

Effective Team Habits: High-performing teams do things differently than average and low-performing teams, including habits around performance monitoring tools.

Intelligent Interviewing: Attracting and keeping people who fit the team well is critically important.

Get these right, and your new hires will become part of your high performing team delivering maximum impact to customers. Let’s look at them one at a time.

Leadership

Given the right environment, a team of competent (not ninja/rockstar/10x) developers can become a high-performing team. This is why leadership is most important. Without leadership providing the necessary resources, no team can perform at a high level.

Software development teams must be free to focus on execution. Leaders within a software development team, and in a company as a whole, must provide teams with information, resources, and clarity of purpose. Together, they do the right work for the right reasons.

Leadership operates at multiple levels within teams, and all have a part to play in effective onboarding.

Executive Leadership

Executives include C-level, VP, and directors. They serve two masters: customers and internal teams. “Wait, what?” you say. “Executives are the bosses! They listen to the customers’ demands, then tell the teams what to build!”

Yes, executives are responsible for the directional vision based on the requests of customers. Effective leadership, at the executive level, recognizes that the “how” comes from the teams of professionals they employ to execute on those requests. Both the what and how must come together through a collaboration between executives and teams. Executives don’t tell teams what to build- they express the desires of the customers, then ask those teams how to provide it.

Executive teams create the conditions for high-performing teams to do their best work by maintaining a culture of trust and communication. They clearly state expectations, using broadly defined, objective measurements for success. Development teams then have the autonomy to find the best way to deliver on those expectations. High-performing teams don’t need to be micromanaged; they just need a goal and the resources to get there.

Engineering Management

Engineering managers add value to the process by supporting their teams. This means helping define and plan work, mentoring senior developers, and dealing with career development. They usually have an engineering background, so they can lead by asking the right questions of their teams:

• “What are our options to solve this problem?”
• “Which of our options provides the most value?”
• “How are we going to organize and prioritize this work?”
• “What is preventing you from completing your work?”
• “How do we clear our blockers to progress?”

It is said that “developers deliver the work, and engineering managers deliver the team.” Engineering managers create the conditions for high-performance success by advocating for their teams and ensuring they have the resources they need.

Senior Developer/Tech Lead

You may be surprised to see these titles in the list. They usually don’t have any direct reports. They aren’t management. Does this mean they aren’t leaders? Hardly. Leadership and management are not the same thing, yet both have their part to play in effectively onboarding new hires.

The “tech lead” title is used so often that it has lost its meaning. “Tech Lead” is short for “technical leader”. It’s important for high-performing teams to recognize the leadership role that tech leads play. These developers are critical to success. Tech leads are the primary problem solvers, the mentors of junior developers and so the makers of future tech leads, and the last line of defense against operational incidents. When a system fails, the most senior developers know the system well enough to find the cause.

High-performing teams respect the leadership role that tech leads fill, and recognize their contribution for the value it provides. Tech leads do the front-line work of maintaining a high-performing team. This means finding the best ways to get things done, and making those things a habit.

Habits of a High-Performing Team

A high-performing team is distinguished by its behavior. They do the same things as average teams, but they do them differently.

Agile/DevOps

Agile and DevOps have become standard practices for engineering teams. There are many, many ways to do both. Agile includes Scrum and kanban. DevOps is as much a philosophy as a practice. How do high-performing teams succeed with them?

1. Be flexible
Adapt Agile and DevOps to your way of working. They are not rigid playbooks, they’re frameworks. Teams must make these practices their own by experimenting, trying new ways of working, and throwing out things that don’t work.

2. Groom your backlog
Groom your backlog well. Find the right maximum size for every story- four to eight hours’ work is ideal. Create as many stories as you need to express the work. Include lots of detail with each story. A well-groomed backlog helps new developers get started with less supervision. It takes more time to deconstruct your work that finely, but it is well worth the effort.

3. Use Agile ceremonies efficiently
Agile typically includes ceremonies such as standups, backlog grooming and retrospectives. Each has a purpose. Agile teams sometimes lose sight of that purpose, and the ceremonies are held “because it’s Agile” and not specifically to fill a need. Developer time is precious, so time spent away from writing code should have a clear purpose. By all means, hold the necessary ceremonies, as long as everyone understands *why* they’re necessary. If a consensus develops that time is being wasted, don’t be afraid to make changes within the broad definition of “agile”.

Knowledge Sharing

As developers work, they build up contextual understanding of their work. Capturing and sharing that context helps them and their colleagues as they return to old code, and write new code. New team members can use these resources to contribute quickly, and frees senior developers’ time.

Gathering and curating knowledge includes things like:

• Well-commented code
• Clearly documented user stories with lots of detail
• Maintained wikis and knowledge bases
• Blog posts

The other side of the knowledge sharing coin is mentoring. Senior developers and tech leads must have the time and the inclination to guide more junior developers. Mentoring makes both stronger- teaching helps people learn, and junior/new developers can’t learn without mentorship. When looking for potential leads, consider how well they do at helping their peers.

Data-Driven Execution

Software development isn’t just about writing code and “throwing it over the wall” to be run by Ops teams. DevOps practices demand a constant cycle of develop-deploy-monitor, with Dev teams equally as involved as Ops at each stage. When things go wrong (and they will) it’s critical to have concrete data on which to act.

Systems that are not monitored effectively are black boxes. When they fail, if your team does not have enough data to diagnose the problem, every solution you try is an un-educated guess. Software monitoring tools like Raygun’s Crash Reporting and APM provide the data your teams need to make informed decisions and respond quickly with fixes that target the failure precisely.

Soft Skills

Communication skills, empathy, time management, and other “soft” skills are too often ignored and undervalued. High-performing teams push hard, so they’re constantly under stress. Dealing with changing requirements, tight deadlines, and complex systems require more than just strong coding skills. They require well-rounded humans who know how to push through adversity as a team.

Mentors can teach a junior developer how to be a better programmer. Soft skills are a different story. While a strong team can set an example for good team-player behavior, it cannot teach a lone wolf to run with a pack. This is why new hires must be a good fit from day one.

Interviewing

Effective leadership and good habits are the elements of an environment in which a high-performing team can thrive. Building and evolving that team requires intelligent, considered interviewing of qualified candidates. You’ll need not just developers, but also project managers, product owners, and several other roles to fill out a team that delivers software.

Interviewing is not an exact science, to say the least. It includes many parts: skills test, personality evaluation, culture fitness. It’s a filtering process that, hopefully, includes candidates with the right balance of all those things. There’s no way to get it right 100% of the time, but there are best practices.

1. Technical Knowledge/Ability
The best way to test a developer’s ability is to work with them on a problem. Canned, online skills tests are far less effective than a *trained* interviewer working through a coding problem. It is *very* important that the interviewer be trained, so that they understand how to objectively (as much as possible) evaluate a candidate. Candidates must be interviewed fairly (to avoid legal issues) and respectfully, so they come away with a positive experience, even if they’re not the right fit.

2. Culture/Team Fit
High-performing teams interview and hire as a team. Candidates should have an opportunity to meet as much of the team as possible. Everyone on the team has a say in the final decision. Many companies in Silicon Valley have an “OR”-style decision process: one “no”, from any team member, is a “no” overall. This is because a bad hire can cost $7-10 thousand dollars. A bad fit can demoralize the entire team, lowering everyone’s productivity. If there are doubts, it’s better to pass on a good candidate than to take a chance on a poor fit.

3. Diversity
Diversity is another undervalued, overlooked aspect in hiring. There is plenty of research to indicate that diverse teams do a better job than less diverse teams. Remember, customer satisfaction is the single strongest measurement of success in software development Teams must be able to empathize with a diverse user base. Which team will do better, the one with many perspectives, or fewer?

Conclusion

High-performing teams need the right environment in which to build and grow. That environment must be created by business and technical leaders with aligned values. Teams succeed when they understand clearly what sets them apart from lower-performing teams.

It’s important to incentivize the right behaviors, build good habits, and support a generative, trusting, professional culture. Once built, a high-performing team is maintained by good hiring practices. The best candidates have the right balance of technical skill and soft skills. Support your hires with the right tooling. If you want to help your team get visibility across the whole tech stack no matter where you are in the world, take a free 14-day trial of Raygun’s performance monitoring tools.

Learn about bringing your team up to speed with onboarding tools and processes in our free webinar,How to build high-performance software teams. 

About the Author

Dave Swersky has been in the IT industry for over twenty years, as a support engineer, software developer, Enterprise Architect, and DevOps practitioner in a wide variety of roles in managed hosting, banking, property management, and the federal government.

As a developer, Dave has used .NET/C# and JavaScript to develop a variety of systems from concept to production. As an architect, Dave has worked on multi-million dollar initiatives to implement and integrate systems.

Dave is currently a Lead Engineering Manager at a software and services company based in Kansas City, KS.

Keep up with Dave’s work on DevOps Katas site