Working cross-functionally requires a lot of give and take. My team has a bit of a unique structure where I manage all of our full stack resources at our company, and the other two teams receive these full-stack resources “on loan” depending on what their team objectives are and how we’re prioritizing for overall company objectives. It most definitely has its challenges, but this is our structure.
As business objectives shift and allocation changes are required, I often have to play a game of chess across all of Engineering to make this work. I’ve developed some particularly useful habits along the way to facilitate this movement, hence today’s post.
Maintain a close relationship with the EM and PM on other teams. I can’t emphasize the importance of this one enough. You should be meeting regularly with both of them, making sure they are getting what they need out of your engineers. Even if an engineer is working on another team, you’re still responsible for their enablement; this means you need to be checking in often on projects and making sure everything is running smoothly.
Prepare for business objectives to change, and help your team through transitions. This is nothing new, but if you’re managing resources across multiple teams, you’re going to need to be ready to shift resources around when the business requires it. This often means for me descoping or delaying projects on my team or telling other teams I don’t have additional resources due to competing objectives. It happens. We’re all working together towards the same goal; we’ll all get there eventually.
When this happens and your own projects are descoped or delayed, it’s important to be able to explain to your team that this doesn’t mean the work they’re doing isn’t important - it’s just not the most important thing at the moment.
Prepare to have trade-off discussions when you need to adjust your engineering resources. You will obviously not be able to get everything done that you originally set out to do if engineers are assigned to other projects. This needs to be a clearly documented conversation with your manager and the important Product team stakeholders.
Plan early for the next quarter. You need to be aware of what every team is planning to do, and they need to let you know up front what to expect in terms of engineering resources required for the quarter. The more thoroughly you plan, the better off you’ll be to minimize the number of surprises you may encounter during a quarter. (You can’t avoid every surprise, but if you fail to plan, plan to fail.)