If you want to build a well-rounded product, strong cross-functional collaboration is a must.
As a leader, you must make sure that cross-functional partners have empathy towards each other and that they understand the value of other functions.
Ritendra Datta, Director of Engineering at Meta, gives valuable advice on improving cross-functional collaboration. He shares his viewpoint on cross-functional collaboration, talks about common mistakes when leading or scaling cross-functional teams, and offers a possible solution to keep good morale within cross-functional teams.
This post covers:
Engineers and research scientists build new products. They write algorithms and code while creating the necessary systems for product development. Everyone else surrounding them is a cross-functional partner with their particular responsibilities.
Different types of software require different types of engineering methods, so in some cases, cross-functional collaboration is more important than in others.
With consumer software, it’s easier to gather insight. For example, if your team works on a social media platform’s software, they’re most likely consumers of that product, and so are their families and friends. They know which features need to be improved or changed, because they use the product on a daily basis as consumers.
If you’re working on enterprise software, however, you’re unlikely to be your own customer, so you’re more reliant on the expertise of your cross-functional partners’ research and insight.
In cross-functional teams, there is a hierarchy of managers and leaders, all the way up to VPs and CXOs. The reporting structure of the company affects how they collaborate with each other. Each leader has a clearly identified counterpart, for example, an engineering manager has a product manager counterpart.
Product managers, engineering managers and senior ICs often work together as a team, and they are the base of cross-functional collaboration. This triad of leaders is the most critical set of people in the product development process. They keep close contact with the UX designer, the UX researcher and the data scientists through the product manager.
Every product is born from an idea. In a bottom-up culture, this idea can come from anywhere: an engineer, an IC-level product manager or a data scientist.
The product manager determines the minimum viable product by writing a PRD and creating a roadmap. They also have to consider factors such as privacy and security measures as well as the available resources before bringing the idea to the engineering team.
The planning and decision-making parts are bottom-up, but then the refined plan and the roadmap is presented to a senior leader for approval. The first version may not get approved. In those cases, a VP or a senior director looks at the plan and gives advice or asks for clarification. It’s important to get a senior’s insight and approval before executing a new idea, because people at higher levels tend to have wider information about markets, timing and budget.
Agile companies sometimes reverse this process: they try something out immediately, then gather data about it. This way, they can see what’s working and what needs to be iterated, and they can set a new direction if necessary.
Software is never done. It’s frustrating and exciting at the same time, but there’s no sharp ending to a project, because some features can always be improved.
In an ideal situation, the lines between cross-functional roles are blurry.
If you hire well-rounded employees, they can act in their assigned role 80% of the time and contribute to other cross-functional roles in the remaining 20%. That way, everyone feels included in organizational decision making, and cross-functional collaboration will be stronger.
Cross-functional collaboration can only work if you have the right leaders who make sure that people feel empowered, included and heard in key decision making forums. Feeling left out or excluded does not support the culture of a collaborative cross-functional group.
People have opinions, and they want to be part of the conversation early on. Each function and each individual brings a unique perspective, which can be invaluable in the long run. If you only include one function for the majority of product development, you won’t have a well-rounded product.
It’s hard to determine how much work a particular cross-functional partner needs to finish a project, especially if they’re not included in the conversation. They can’t plan early on, so they’ll become overworked in the late stages.
Learn more about what others do around you. Conflicts happen within cross-functional teams when there isn’t a transparent flow of information and understanding. Get close to people on your team, understand what they do, and it will help you become a better leader.
We tend to judge others quickly. Be self-aware of that, call yourself out, and correct your mistakes along the way.
With cross-functional collaboration, it’s inevitable that people in one function criticize others in other functions, questioning how they are contributing to the final product. It can lead to frustration and conflicts.
It’s common for ICs to not see what their skip level managers do on a daily basis. It’s also common for engineers to not see the value of product managers or data scientists. It roots in their biases; they focus on their own work, and believe that anyone who’s not doing the same is useless.
It’s a problem of inclusion. Just because you don’t see somebody else’s contribution, it doesn’t mean that they’re unnecessary.
Cross-functional partners don’t criticize each other for the sake of bullying; it happens because they lack information about the value the other functions bring. This is a serious problem, but it can easily be solved.
We have cross-functional empathy sessions, where people get together for 4 hours and represent all cross functions. The key tech lead, an IC, a manager, a product manager, a data scientist and a UX researcher will meet somewhere outside of the office, and spend the day talking to each other.
They could discuss what they do on a daily basis, and what’s frustrating about it. The representatives of each function gain a better understanding of the different positions, and why the work of each function is valuable and challenging in its own way.
Every time we have these cross-functional empathy sessions, everyone goes home humbled by what others are doing and the struggles they’re facing. They realize that everyone is working hard. They often describe it as “an eye-opening experience.”
A good example is a UXR. Many tech companies are data-driven, running A-B tests and almost blindly picking one variant, thinking people like it more. But sometimes this data doesn’t capture the emotions that the product is intended to evoke.
That’s where UX researchers come in. They can get more accurate measurements of success, and they can tell if A is preferred by users, even if the data on B looks better. It’s because the metrics used by engineers can’t caption emotion, and so, you can’t rely solely on this information without consulting a UXR.
Empathy sessions work best if cross-functional teams recognize when they need one, and they take the initiative to organize it. Usually, the engineering leader and the product leader counterparts team up: They decide that they want to do an empathy session, and then they notify upper management about the plan.
Empathy sessions aren’t useful if there’s malintent within the group. If people are miscommunicating, or if they lack empathy and aren’t open to changing their minds, it doesn’t make sense to hold the session.
Avoid these conflicts by encouraging people to hold cross-functional empathy sessions at least every 6 months, so they’re constantly reminded of the value that other functions bring to the project.
Large companies are driven by promotion culture, and that can lead to selfish intent. If some leaders are solely focused on their personal career growth, it doesn't always lead to the right decisions.
It can also be true for other cross-functional partners.
They might take on projects not to serve the company, the product or the users, but to serve their own career. It can hinder the goal of empathy sessions as well. They will question what they are personally getting out of participating in these events.
This happens more within a function, among peers. You’re less likely to compete with a cross-functional partner for a promotion, but you might fight for scope on projects with your peers. Empathy sessions are useful in these cases, too: people can share their frustrations with each other, and their manager can help with separating their responsibilities, so they won’t compete with each other for the wrong reasons.
Don’t put too many people in a meeting unless it’s a one-sided conversation where someone is disseminating information. For other types of meetings, keep it under 10 participants.
One principle you can follow is to include the right decision maker for each function in a meeting. You don’t need anyone above or below them in the reporting chain just to make them feel good about being invited. People can be enthusiastic about meetings when they don’t have too many of them - don’t overbook their calendar, only include them when necessary, and they’ll look forward to those meetings.
People might fear that not being part of a certain meeting means they’re out of that conversation. This is another mistake to look out for. Provide the right communication channels, have the right leaders present, and they will figure out a way to forward the information for their team while representing them at the meeting simultaneously.
Those who aren’t invited to a meeting that concerns them must trust that they’ll receive relevant information. They shouldn’t assume that important details will be hidden from them to someone else’s advantage. If that’s the case, you have a bigger problem to solve than the number of people in meetings.
There’s a cynical view of scaling — some leaders scale their teams for the sake of building an empire. You must scale for the right reasons, when there’s work to be done.
When your product is scaling, you may need to scale your team with it. If there are more requests coming in, if there’s bigger demand to improve multiple features in a product, the number of cross-functional teams needs to grow.
As a leader, you must make sure that scaling doesn’t feel like unnecessary growth within the company. You can grow your team, but do it if you have the right indications that it’s necessary for a better product that has already found product-market fit.
It’s better to have a smaller team that can effectively prioritize than to have a large team that’s doing redundant work. Multiple teams working on the same project is bad for morale. Engineers recognize that somebody else is working on the same piece of code, and they will either get frustrated with the redundant work, or they’ll worry about their job being unnecessary or replaceable.
A different approach to scaling is to see it as switching to a larger room. A bigger room can hold more air in it, just like an upscaled company can always find enough work to do. This philosophy can work in some cases, although it’s the opposite of keeping teams lean to avoid redundant work.
With small startups, it’s easier to keep teams small, because they can’t afford empire building yet.
For large companies, scaling is trickier. It’s difficult to track how many people would be enough. Those who make decisions during hypergrowth often have to decide without having all the necessary information, and they resort to making guesses and deal with the aftereffects of bad scaling decisions later.
Scaling while managing the already existing workload is like being in a boat with your team. Your team is growing the boat in size and capacity while it’s moving, and you make sure they don’t fall into the water. The boat moves fast, but everyone is protected.
Scaling needs the right leaders. There are different ways to make sure you have the right people leading your cross-functional teams. Some companies hire the top leaders of the industry, and give them a charter of growth. When you approach scaling from the other way around, and hire lots of new people before bringing in leaders and managers, it tends to be more challenging.
If you pick the leaders first, they are with you throughout the scaling process, and they learn a lot more. That way, you build a bench for your ship, so if you fall sick or go on vacation, these leaders will be able to take over. Key leaders not having proper substitutes means that the company has to run on autopilot for a while, and larger organizations cannot operate like that.
When hiring managers, they often inquire about the number of people they’re going to manage. That’s challenging, because it might be their top priority, but you might not be able to answer that.
It’s more common that leaders want to run a large team from day one, but some of them are happy to take on a charter and grow it along the way. Scaling is more effective in the latter case, but these types of managers are harder to find.
Scaling policies differ at each company, and it depends on how involved someone’s role as a manager is. If you work at a company where you have a lot of work to do per team member, you tend to have fewer direct reports. Other organizations can have managers with 30 reports, and they have fewer responsibilities per engineer.
Both solutions are equally common.
The tricky part about making one of your engineers a manager is that now they become the manager of their peers, and sometimes, that doesn’t land well.
In some industries, becoming a manager is a career leap. In the tech industry, becoming a manager isn’t necessarily a promotion. Maintaining an IC role can be just as valuable.
When there's a need for a highly technical manager, it’s a great idea to hire internally. If you want to find your next manager in house, there are a few traits to look for in potential candidates.
The most important skill a manager has to master is leading with empathy. Does this person have enough empathy for the role?
Do they like the idea of not getting credit for their work directly? Are they happy to give credit to their team?
If there’s a senior engineer who masters both of these leadership soft skills, you have found a new manager who can contribute to scaling and perfecting cross-functional collaboration within the company.
Ritendra is a Director of Engineering at Meta, and has been there for three years. He runs the Facebook video and reels recommendations teams. Before that, he worked at Google for ten years, where he went from summer intern all the way up to leading 30 engineers as a tech lead manager. There, he founded, led and managed teams working on shopping searches on Google.
He is passionate about building scalable systems. Aside from engineering, he loves making films.
👉 If you are serious about becoming a great engineering leader, you should take a deep dive into the State of Engineering Management 2022 report.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.