Cross-Functional Teams
At work, I serve the engineering side of the "learning experience area" (LXA), which is in charge of most of the aspects of actual language learning as our customers are facing them. There are three XAs, each of which is co-led by a product and an engineering person.
My product partner and I have established a "The XA is the team." motto. It's the headline for how we are thinking of LXA as being strictly more than our respective (reporting) orgs. It means that the notion of "team", i.e., group of individuals that work towards one shared objective, should very explicitly be understood as one that spans reporting hierarchies, or cuts across them. You can think of this as a view on teams as proper cross-functional teams.
What does this mean concretely? Take one of my engineering teams that is currently doing a technical overhaul of the lesson player (a core piece of the learner experience). The team consists of (in alphabetical order, to emphasise that everyone contributes equally) back-end engineers, a designer, a didactics project manager, an engineering manager, front-end engineers, a mobile engineer, a product manager, a QA engineer, and a test automation engineer. Many of these people aren't in my or my product partner's reporting org; they're in different organisations, and yet they're part of LXA because they contribute to the work LXA is delivering. In fact, the team would simply be incomplete without these folks, and their input is crucial to the team's success, as is the input provided by the engineers.
The point is, reporting lines have more to do with functional clustering and people management / career development than with team and work organisation. The latter is strictly more important for company success, so being pragmatic about it is key. Thinking of teams only as reporting structures can easily lead to silos, politics, and turf wars (to quote a book title and give a reading recommendation) if egos overrule mission and alignment. Conversely, the factors that should drive work organisation are priorities and capabilities - and each team should ask itself whether they're working on the most important thing for them right now.
This is true at all levels of "team", including leadership, of course, and even the entire company. One consequence of this view is a strong commitment to getting the important things done and helping each other out across reporting organisations. If, say, another XA is missing engineers with a certain capability but needs to contribute to a high-priority OKR, and my XA is working on items of lesser priority, it's natural to think about supporting them by asking engineers in my org to help out "over there". After all, we're here for the success of our customers and thereby the company, not for the success of our immediate surroundings. Global optimisation usually beats local optimisation.
I'll give another, perhaps surprising, example: hiring.
There is a hiring team involved with filling a role. For hiring a mobile engineer (since that's currently on my mind), it consists of (again, in alphabetical order) engineers who conduct technical interviews, engineers who review coding challenge submissions, a hiring manager, a people and operations colleague supporting the contract and onboarding, and a recruiter. Again, everyone contributes, and the objective cannot be achieved if any one of these members stops contributing. What is the objective? It's twofold. On the one hand, the role needs to be filled quickly with the best possible candidate so that the team in need of the role, and the company as a whole, are set up for success. On the other, the candidate should get a good impression of the company in any case - regardless of whether they're hired in the end or not.
What does this mean? Hiring is a project just as any other project, and it requires a team that goes about its work with great dedication. This implies some priority juggling. Should I, as an engineer, focus on the work needed to complete that JIRA ticket, or on reviewing that coding challenge? Should I, as a hiring manager, focus on screening those 30 CVs, or on straightening the work processes for that one team in my org? The answer is, as usual, "it depends", but it is important to keep the work flowing in all of these areas.
In my book, hiring usually takes priority, simply because being fast at it means that I'll be able to work with meaningfully complete, and hence more powerful, teams sooner, which is good for the company - and the customers.
Tags: work