XFN (cross-functional) work is one of the challenges of a senior engineer in most tech companies. Broadly, it means to interact with team members of a different team than your own. Concretely, this can mean anything from aligning goals or gathering feedback from other teams to inform your roadmap, to pair programming to flesh out the design of a new interface. Your team wants you to make progress on the goals through XFN, but also to make the team look good (ie competent, smart, motivated) to those who are judging. In my organization, this type of work is reserved for more seasoned engineers - although you're interacting with others on system designs, a lot of it is not the type of stuff taught in CS classes. It's about personal interactions.
When you first start talking to a member from a different team, it's important to ensure they feel that you're someone they want to work with. You should be able to describe the system you own or are building on a whiteboard in a few minutes, and you should be able to understand, follow and ask questions as XFN team members are doing the same. Besides that, you need to understand the goals of your own team so that you can make sure that the agreements that come out of your interactions align with the direction your team is going. XFN teams will sometimes try to move work onto other teams in order to save the bandwidth of their own team. You're still working for the same mission usually, but if you're not presenting the goals and constraints of your own team well enough, you might end up agreeing to take on 6 months of test debugging work in order to appease your XFN colleague.
XFN work means you have to think more a like a lawyer - you need to make sure agreements about who is going to do what are clear between you and the other party. It's essential, or else you'll end up missing your timelines because you thought they would do the work, and they thought you would.
Make the agreements clear - clear enough that you can understand it and describe it to your manager. Then make sure to write it down and publish it so that your colleague and your manager can see it - in an email or post - somewhere you can reference back to in case anything happens.
Follow-up with your XFN colleagues and sync up regularly. The workplace today leaves few excuses for not having reached out to a colleague soon enough - you can walk over to their desk, call them, send an IM, and in some workplaces you can post in their user group. So use the tools you have to check in and sync up to make sure everyone is doing the work they are expected to get done.
Even if things are in writing and you follow-up, the fact is that different teams are held to account by different management chains. If you get an agreement with an XFN team and they aren't following through, make sure you have a plan for what would happen next. If a timeline for a project starts to go from green to yellow, communicate it to the XFN team member and ask what they're doing about it. Tell your manager as well - they will want to know so that they can plan accordingly.
XFN work is different from technical work like coding and system design. It requires you to do a small set of very specific things with extremely high consequences if you fail to do any of them, and the only fallback for these things not happening is you. What would happen if simply missed a monthly check in and it turned out your XFN partner was falling behind? You'd find out a month later and then have to push back dependent projects back 2 months instead of 1 - that could mean a lot of people angry at you. In contrast, if you're writing code or designing an API, you can rely on code reviews, design reviews or colleague feedback to make sure you don't miss anything important. It's rare a week goes by without either someone on your team making sure your deliverables are moving forward, OR you yourself seeking feedback on what you've done so far.
XFN work is less fun in the short term but far higher impact in the long run. So try not to shove it aside as something boring and unworthy of your attention - if you screw it up, you could get your team in deep doo-doo.
Comments
Post a Comment