Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Letting Engineers Choose Their Own Teams: How It Works

DZone's Guide to

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
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. 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 how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. 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.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}