Cross-functional Engineering Teams: Embedding the Voice of the Business in Every Decision
If you’ve been keeping up with this series, you know that earlier this summer I sat down with two stellar engineering & product leaders – Yoav Shapira, Engineering Manager at Facebook, and Craig Daniel, VP Product at join.me. You also know by now that these two have a ton of wisdom to share. So today, in our final post, we’ll discuss why, when and how to build a cross-functional engineering team.
The Value of Cross-functional Teams
“Put simply, you make more informed choices if you have more data,” says Yoav Shapira. And when it comes to building high functioning teams, the same rings true. For Shapira, it makes sense to include employees from marketing, sales and customer support on engineering teams. “You not only build personal relationships between developers and other stakeholders across the company, you gain a unique perspective from every department.”
In fact, Shapira would argue that the decision to go cross-functional can be vastly more important than even the development methodology you choose to employ.
“It’s so much easier if the engineer can turn to a salesperson and ask, ‘Hey, will this demo well? Will it sell well?’” Why not go right to the source?
When and How to Go Cross-functional
While the value of cross-functional teams is undisputed, determining the right time to go cross-functional can be a little trickier. Shapira says to start from the very beginning.
“I don’t think you can do it too early. It usually happens anyhow,” he says. “Typically when you start a company you have a founding team or its first year employees, one from each functional area, and a lot of decisions are cross-functional by default.”
Things start to unravel, however, as the company grows. “When you get to that middling stage where you’ve hired 10 or 20 engineers, you experience a breakdown in communication,” Shapira adds. “You don’t want to lose those connections.”
But if restructuring your company sounds daunting, Shapira suggests starting small. Building cross-functional teams doesn’t have to be a formal endeavor. Instead, let the sales team know what new features you’re building. “The one or two team members who really care about what you’re working on can become your alpha testers – your guinea pigs so to speak. The others might not care, and that’s totally fine.” Don’t force it.
Hackathons can also ease your employees into the idea of working on cross-functional teams. “There’s an interesting pattern we’re starting to see at Facebook and a few other Silicon Valley companies,” says Shapira. “Rather than a typical hackathon, companies are now holding ‘hack months,’ which, contrary to how it sounds, is not a month long hackathon where individuals or small teams work on a project of their choosing. Instead, hack months allow individuals to work on different teams.”
The reason for the month-long stints? Well, as you can imagine, teams can’t accomplish much in a day or two. But, give employees a month and “you can really make a significant impact,” says Shapira. “At the end of the month, team members will either decide they like their new teams better or will go back to their original team with a ton of new knowledge.”
For Craig Daniel and join.me, building cross-functional teams hasn’t been straightforward, but the benefits are plain to see.
join.me, a subsidiary of LogMeIn, hasn’t formally rolled out cross-functional teams, but the product team actively releases new features for LogMeIn employees to test out on a regular basis. “We actually have Slack channels where we release new features and gather feedback,” says Daniel. “It’s typically the same people every time, the ones who really care and want to give feedback, but they get in the loop early. They’re advocates for each feature by the time they become generally available.”
Continuous, Rapid Improvement
As cross-functional teams become more prominent at startups, mixing these teams up will become crucial. After all, the benefits of cross-functional teams come largely from blending different departments. You want to avoid group think at all costs.
While Shapira says each leader or organization will find a timing that fits their own company, he tries to keep teams together for about a year. He also is careful not to completely scramble each team. Instead, Shapira says to “add someone new and take one or two other teams members out at a time. The ideal team should have three or four developers, a PM, a marketer and salesperson. All in, you should have seven or eight people,” he says.
And what happens when you need a team member to serve on more than one cross-functional team? Well, you’ve misplanned.
“Correct your planning. Document why you failed, understand if you need to hire differently or replan the project or train someone else,” says Shapira. Building the perfect cross-functional team isn’t easy, but it’s well worth it.
Have your own experiences building and managing cross-functional engineering teams? Let us know in the comments.