Modern Teams for Modern Service-Oriented Architectures: 6 Keys to Building Your Team
Hiring developers used to be pretty straightforward: Hire back-end developers to handle your server-side software and business logic; hire front-end developers to design and create the user interface and interactivity; then hire product managers to keep it all on track. The tiered, monolithic architectures of decades past made partitioning out roles and responsibilities cut and dry—but they also created more dependencies.
As the traditional software stack changes, everything is tilting toward a more distributed model: software, the way software is developed, and development teams’ structures. This has had a direct effect on the way companies source and hire developers—and what they’re looking for in those developers.
The success of componentized software leans on more diverse teams and an innovative, entrepreneurial spirit. Put simply, software is less cut and dry, and the same can be said for the culture and competencies of the developers building it.
Here’s a look at six ways you can successfully build your engineering team in response to this shift and how a few top companies are doing it.
1. Microservices are “loosely coupled but tightly aligned”—but distributed teams can too easily become misaligned.
More and more companies are moving away from a monolithic, tiered approach to building software to a more distributed, component-based architecture. In these microservice-based ecosystems, software is broken out and encapsulated into services. These work in tandem to contribute to the app’s functionality as a whole, but they can be updated and launched independent of one another.
Distributed teams didn’t come about solely because of distributed software, but they are serendipitously well suited for one another if well managed. They’ve become more common as remote work architectures have replaced the old way of doing things.
“The distributed team is an innovative way to get things done with remote talent around the world. Companies who are tapping into the growing freelance economy are getting work done with greater efficiency and more flexibility. As a result, team structures are beginning to look a lot different.” – What is a Distributed Team & Is it a Good Fit for Your Company?
However, this alignment is something many companies have struggled with when it comes to teams. Microservices don’t necessarily encourage alignment—and as Upwork CTO Han Yuan emphasizes, “the fact that everything is so micro creates high probability of misalignment.” That’s why it’s up to leaders to ensure teams don’t get too separated. Han adds, “Alignment for microservices therefore is not a technical problem, it’s a people and process problem.”
Strive to keep teams more aligned and working toward the same goal.
2. Keep teams focused, small, and nimble.
Microservices can have their own, unique stacks—containerized systems that run their own languages and frameworks without relying on a large, tiered infrastructure. While these teams should not be siloed, it’s important to keep them small. Rob Zuber, CTO of CircleCI says, “Engineers are people. People work better in small groups. So we’ve divided our team into several functional units, inspired by Spotify’s pods. We’re much smaller, so we’ve adapted their ideas to meet our needs, while maintaining the core principle that each team has the resources they need to implement a feature across the stack.”
At the DIY website building platform Wix, chief architect Yoav Abrahami explains, “For us, a microservice is a single application deployed as a process with one clear responsibility… That team has to be able to describe the microservice responsibility in one clear sentence.”
For smaller organizations, this is more manageable. But it can quickly become a theory that’s hard to put into practice, especially when ecosystems get massive (think: Uber-sized).
That’s why, even when encouraging teams to be independent, “you still need some central governance in terms of how you centrally monitor and page for these stack,” says Han. Ensure that your teams—even while fully “owning” certain components—are still interconnected.
3. Create cross-functional teams when appropriate.
Here’s where the “loosely coupled but tightly aligned” mission comes into play. As focused as services and teams are, they should also seamlessly weave into the bigger picture—and that often means playing a cross-functional role.
For companies building microservice-style software, this approach to structuring teams has been a no-brainer, and it’s also informed some decisions about culture.
Dan Pupius, head of engineering at Medium, writes, “We operate in cross-functional, mission-driven teams, so while some people specialize, everyone should feel able to touch any part of the stack. We believe that exposure to different disciplines makes you a stronger engineer.”
Wix takes a unique tack. Their 400+ engineers are organized into “companies” within its engineering team and “guilds.” Guilds are tech-focused units, while companies are product-focused and pull engineers from guilds. This encourages a more connected, multifaceted department. The same goes for Spotify’s now-famous tribes, squads, guilds, and chapters. Squads deliver product and chapters group engineers by competency, with heavy communication between them.
Whether you choose to adopt one of these strategies or not, the takeaway is clear: There’s rarely a benefit in completely siloing teams and engineers.
4. Encourage an “entrepreneurial spirit” for more effective, innovative teams.
A service-oriented architecture (SOA) inherently means that the many parts must seamlessly contribute to the software as a whole—but the more keyed in teams are to how their work plays into the bigger picture, the better they’ll be. As Alex Zirbel, an engineer at Opendoor.com, explains, there’s “a very entrepreneurial, pragmatic culture: Engineers here typically talk with customers, understand their needs, and take the initiative on projects. We’re big on ownership and empowering others.”
That communication with the end user—while not always possible (or necessary) for all organizations—can definitely help foster a more entrepreneurial spirit by educating developers about how their work contributes to the success of the business. For smaller businesses, this might mean gathering your team and sharing some key insights about customers and your overall business goals. It doesn’t have to be overkill, but that point of view can be excellent insight and much-needed encouragement.
HotelTonight values an innovative “DIY” culture and encourages developers to not only come up with their own ideas but also to take initiative and build those ideas out to prove they “have legs.” Director of platform Jatinder Singh says, “Everyone has an opportunity to make an impact.”
Make ideas and constant improvement a part of your mission, and talk about what that looks like with your development team from day one—you can even make it a part of your interview process.
5. Stay flexible. Like microservices, teams and how they communicate will always be evolving.
The lines of communication between microservices are what make it all possible—and the same goes for the teams working on them. It’s crucial to keep everyone on the same page working toward the same goal.
At Opendoor, Zirbel says, “As we grow, the lines between teams often get blurry, so we expect that the structure will always be evolving. It’s common for engineers to move between teams, including between the product and data science teams.”
Paul Liu, a DevOps developer at online photography app 500px, explains, “Teams are highly cross-functional and boundaries are fairly loose, so engineers wind up moving around a lot between teams to work on specific projects. This helps us spread knowledge and prevent siloing. There is also a very tight communications loop between engineering, product, design, and the customer excellence teams, which helps to keep us honest, agile, and focused on delivering the right things.”
To increase visibility and reduce complexity, 500px uses a Slack bot, BMO, that they created to keep everyone on the same page. Liu writes, “Anyone at 500px can easily deploy the site or a microservice with a simple chat message like ‘bmo deploy <this thing>.’ BMO goes out, deploys the thing, and then posts a log back into the chat.”
There are plenty of collaboration tools teams can use (and tailor) to their workflows to keep everyone on the same page. Find a combination that works for your team and be open to feedback and adjustments.
6. Hire multifaceted developers who are interested in being involved outside of their singular roles.
At Upwork, a long-standing tip we suggest for interviewing a freelance developer is to ask questions that give you a sense of a developer’s motivation and passion for what they do. When it comes to augmenting your team, looking for that entrepreneurial spirit can really shape your engineering culture—even if you only have a handful of developers. Whether you’re a large enterprise organization or a smaller company with 10+ team members, hiring multifaceted developers interested in touching different parts of the business is increasingly important—especially with an SOA.
Event organizing platform Eventbrite knows the value of front-end engineers with diverse skill sets. While they’ll hire back-end engineers and a handful of “pure” front-end engineers, they often look for engineers who can marry skills the way their product marries services—say, a front-end engineer who has strong data visualization skills, two things that directly shape their product.
It’s an evolving narrative that will look different in nearly every scenario, but you can apply these principles to your software development team in a way that works for your needs—and those needs will often change.
Look for developers who are engaged, motivated, and care about the broader impact of their work beyond their own tasks. When interviewing, ask questions that give them an opportunity to demonstrate how they’ve worked on cross-functional teams in the past, or stepped outside their lane to lend their expertise or perspective to another team. And finally, as easy as it is to throw work over the fence, try and establish a culture of collaboration and regularly regroup to bring everyone up to speed. This will give everyone a common focus that will guide their work back on the front lines.