Agile Reviews Build Better Engineers Faster
Agile Reviews Build Better Engineers Faster
This is the ninth in an ongoing series of posts that address how New Relic does engineering management in the real world, talking about one-to-one meetings in teams.
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
When it comes to coaching and reviews, New Relic engineering strives for fast iteration and mutual trust.
In New Relic’s product engineering organization, every individual has weekly or bi-weekly one-on-one meetings with their manager and receives two or more performance reviews a year. A friend of mine who is a workforce development trainer at a big healthcare provider was surprised to learn how much time we spend on this. But it actually makes good sense.
Software is a high-leverage business and a creative pursuit. Engineers are more satisfied when they’re improving their craft, and even small improvements in an engineer’s abilities can pay big dividends. We invest heavily in personal growth because the compounded interest on that increased effectiveness helps liberate everyone from the tyranny of micromanagement and creates tremendous value.
That’s why the review process for New Relic software engineers starts with regular one-on-one meetings, an approach former Intel CEO Andy Grove talked about in his classic book High Output Management. This 20-year-old management tome is still highly relevant and remains recommended reading for any dedicated engineering manager.
The purpose of these one-on-ones is to enable employees and managers to talk about how work is going, workshop any frustrations, and check in on expectations and long-term projects. The meetings are an excellent way to carve out space and put aside the project-focused concerns that consume most daily interactions.
One-on-ones create value in multiple ways. First, they can improve performance and job satisfaction. Not only can they make individuals more successful and effective, they can help reduce turnover. One-on-ones are also excellent sources of information and insight into what’s really going well and what’s not going so well within the engineering department. One of the best ways I know to discover underlying problems is to hear my employees vent about them.
What Goes on in a One-on-one
I’ve adopted a number of habits from Michael Lopp’s excellent article on one-on-ones, “The Update, The Vent, and The Disaster.” For example, here’s how I like to start mine: “How’s it going? Anything I can be doing to support you better?”
This sets an immediate tone of support and encourages my employees to put something of themselves into the conversation. Of course, for this approach to work I have to actually mean it when I ask, and I need to be clear about what I can and can’t do to help fix issues.
The rest of the conversation is generally free flow from there. What I’m ultimately trying to achieve is a safe space to talk openly and freely about what’s in their head and help them understand the context they’re working within. If I have critical feedback to give, it’s important to communicate that openly and help them see it as an opportunity to improve. Fortunately, I often find that whatever is on my mind will be brought up by the employee before I say anything about it, which is the best way to start improving things.
Bi-annual Reviews, or More
We also do more formal performance reviews, but again, we do so more frequently than is common at many companies. Because we have so many one-on-one meetings, the formal reviews are designed to be a chance to sum up the conversations we’ve already been having—with an added dollop of strategic thought.
The review process includes some self-assessment, some peer and manager feedback, and some analysis of what areas the individual is excelling at and where they can most improve. We also like to include a significant personal development goal with each review. It often goes something like this: “You’ve had these successes over the last few months; here are some areas you’ve struggled with and need to improve; and we agree that over the next few months you will take on this new challenge that will require you to master some new skills.”
A big part of the art of the review comes in that new challenge or goal. Goals need to have clear success metrics or it will be difficult to say in the next review whether you’ve succeeded. They shouldn’t be tied to specific project work, because priorities for projects often change in ways outside of the individual’s control. We want to set goals that employees can succeed at even if their team or priorities change.
New Relic used to deliver formal reviews every four months. But it takes time to have the brainstorming and preparatory conversations as well as to solicit feedback from others. So we’ve recently moved to a twice-yearly tempo and find it very manageable.
Reviews Are Worth the Time and Effort
Despite the time they take, New Relic engineering managers are expected to prioritize one-on-ones and reviews, and make sure they happen even when other priorities are pressing. In general, we put them on the same level as delivering projects and hiring new engineers.
Speaking as a manager, there’s no question that all this interaction with team members is worth my time. The faster I help our engineers improve, the more multiples of effectiveness and value they can deliver. Just as important, frequent, structured communication cuts down on surprises and helps me build confidence in everyone on the team. Finally, this investment is a recipe for building a solid foundation of trust and empathy between engineers and managers. This trust makes it easier to have the hard conversations that are necessary to address challenges and help people improve faster.
We’ve found that this type of frequent communication with our engineers—from one-on-ones every week or two to formal reviews twice a year—leads to faster personal growth and the kind of rapport that helps a manager be a coach rather than dictating the details of how someone does their job. That leads to happier and more fulfilled engineers delivering better software, faster.
Look for more posts in the series in the coming weeks.
Published at DZone with permission of Jonathan Karon . See the original article here.
Opinions expressed by DZone contributors are their own.