This is the seventh in an ongoing series of posts that address how New Relic does engineering management in the real world, written by various New Relic software engineers and managers. Look for more posts in the series in the coming weeks, or see them all here.
What does the term “invisible manager” suggest to you? Is it a manager who’s never around when you need them? You know, the awful kind described by HR consultant Rita Olsen: the ones who work behind closed doors, are always busy attending meetings or on conference calls, and never have time to review your work or listen to your suggestions?
Here at New Relic we strive to have invisible managers of a completely different kind. Our managers are invisible because they’re working behind the scenes, supporting their teams while giving individual contributors the spotlight. In many organizations the managers are typically the representatives of the team, the ones who give the demos and show off their teams’ creations. But we believe the engineers themselves should be visible and recognized for the good work that they’re doing.
A great example is our annual offsite Product Conference, where each team takes a turn talking about its charter and road map. For the most part, managers don’t do those presentations, individuals on the teams do.
As a manager, seeing growth in my team is the way I get satisfaction out of my job, and when I see a VP tell an engineer on my team how great a job they’re doing, that’s a reward for me, too. Ultimately, I know I’ll get recognized anyway—if my team is doing well, people associate the manager with the team.
6 Pillars of invisible management
Being an invisible manager rests on several intersecting principles. One fundamental is the recognition I’ve already discussed. If there are demos to be given on their work, the engineers should give them. If there are emails to be sent out about cool things the team did, usually the engineers should send them. If a manager sends out such an email, it’s essential to name the engineers involved rather than just saying, “The team did this, the team did that.” We make every effort to put individuals’ names out there.
The second main principle is to give the engineers autonomy, to enable them to make decisions about trade-offs, for instance, without having to find their manager and ask what they should do at every step. That means making sure they have the information and context required to understand the company’s priorities. The proper information and context leads to clear vision, which enables our engineers to judge whether an obstacle in their path is important or something they can safely ignore to stay focused on their ultimate goal.
We rely on an assortment of tools to support these efforts. For example, we built a status-reporting tool, Fog Lights, to communicate goings on within our team. Every week, for every project, I use Fog Lights to let people know what the team did during the week and also call out individual accomplishments by name.
Much of our effort boils down to removing obstacles for the team so they can do their best work. For example, if you need a certain piece of software to do your job more effectively or efficiently, our general philosophy is to provide it. You get what you need to do your job.
The bottom line is that we try to establish and implement an engineer-focused culture. We’re very product-focused, but we work to make sure engineers are as empowered and enabled as possible to do their jobs. For example—and here’s a way all this ties together—we recently did a workforce survey. When asked whether “I receive the right amount of recognition for my contributions,” 100% of the people on my team said yes. That kind of acknowledgment goes a long way with engineers.
Invisible from the top down
Our approach to invisible management is also cultural, and it starts with upper management. It’s not uncommon after an executive review of a team’s projects for a VP to tell managers that “You should get your engineer more involved in this. She has a lot of good ideas, and she should be presenting the material.”
It all starts with the kind of people we try to hire as managers. In interviews, we listen for “we” language rather than “I” language. Someone who spends their interview talking about “me, me, me”? They’re less likely to get hired. A candidate who talks about what their team accomplished and sincerely says “we” a lot is much more our style. We’re looking for people who come to the company with the invisible manager philosophy already in place.
Be sure to read the other posts in this series:
- New Relic Engineers Have Two Jobs
- How We Hire and Develop Great Engineers at New Relic
- Peer Groups Help Our Engineering Managers Build Great Teams
- Project Leadership Teams: How We Deliver Fantastic Features
- At New Relic, Management Isn’t a Promotion—It’s a Different Job
- Designed for Collaboration: Helping Engineers Be Awesome Together
- Transparency Is Clearly the Secret to Good Management
- How Our Agile Review Process Builds Better Engineers Faster
- Completed Staff Work: The Secret Management Technique to Empower Your Team
- The 5 Habits of Awesome Engineering Managers