Over a million developers have joined DZone.

Letting Engineers Choose Their Own Teams: How It Works

As part what they call Project Upscale, New Relic recently decided to let engineers choose their own teams. Did it work out?

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

New Relic recently put its thoughts about innovative engineering into practice by letting engineers choose their own teams and make their own rules in what we call Project Upscale. At FutureStack16 in San Francisco, attendees will get a rare behind-the-scenes look at our software teams, the way they work, and how we ended up building a stronger organization. Who knows? You might pick up some best practices for your own software development organization.

We Let Our Engineers Choose Their Own Teams

In a special session titled, “Inversion of Control: How New Relic‘s Engineers Picked Their Own Teams and Built a Faster Org,” New Relic Chief Architect Nic Benders and Senior Software Engineer Cory Johannsen will take you behind the scenes of Project Upscale, sharing what it was really like to let our engineers select their own teams and make their own rules, how we nearly chickened out, and why we think this is the future of engineering.

To convey what really went down, the session will combine a high-level perspective from an engineering leader with the personal experience of an individual contributor who ended up thriving on a team he would never have expected to join.

As Nic explains it:

“Building great products means dedicating your engineering organization to innovation. But success brings new challenges and organizations can become frustrated by the feeling that innovation is getting harder, not easier, as they grow. At New Relic, we went back to our roots to solve this problem and ended up giving our engineers far more control than anyone thought possible, and it worked out great!”

Common Problems for Growing Teams of Engineers

A key issue, Nic says, was increasing dependencies on other teams. Small delays on one team can ripple out to all the teams that depended on them, rapidly becoming big delays and big problems. Cory felt this first-hand as an engineer, for example, when a project he was working on was stalled by upstream delays.

The result was Project Upscale, an organizational redesign that put our engineers, designers, and product managers at the center of the solution through crowd-sourced analysis, self-selection of team members, and group chartering, with the goal that every individual on every team fully understands their purpose and has the tools and authority to get the job done.

If you see these kinds of issues in your organization, we hope that learning about how we addressed them can be helpful. We are interested not just in creating great software, Nic says, but in pushing the state of the art in how software is made. We wanted to ensure our engineering process matched our culture, he adds, and we found a way to help engineers have a say in how they choose to do their work, have a blast, and ship great software. Based on the results, we think other companies should be doing it too!

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:
agile ,engineers ,work life ,software engineering

Published at DZone with permission of Fredric Paul, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}