Five Tips for Cross-Functional Leadership
Many job descriptions call for “cross-functional leadership.” But what does that mean? How can one lead people cross-functionally, especially without direct authority? Cross-functional means team members who work in functions not your own. Their work is essential to building or delivering on a goal — either as a tangible product or a functional service. Product managers have to lead cross-functional team members like researchers, designers, data scientists, and engineers members to deliver a new product or update an existing one. Marketing directors have to lead different agencies and production teams to launch an integrated or consistent campaign across several media. User experience directors lead researchers, content strategists, copywriters, designers, and developers and clients to design a comprehensive and satisfying digital user experience. These leaders are not the “boss” or managers of the teams. I’ve served as each type in my career and can offer five practices that help me lead a cross-functional team.
A note: I use the term “project” as a general label for any initiative that I’m leading to complete a goal with a team that I have no authority over. My cross-functional leadership projects have been American new digital and analog products, new or redesigned websites, new services and customer journeys, brand repositionings, and new integrated marketing campaigns. My advice is through the lens of my location and this experience.
Create a Compelling Vision
In business school I learned a definition of leadership that I’ve kept with me since: leadership is the ability to create a vision and enlist others to follow it. In my career, some projects and products worked, and some didn’t. Some teams flowed and some didn’t. The secret to the ones that worked and flowed? A great idea and a compelling vision. In my work on product management and strategy, each project starts with an idea and the goal is to bring that idea to life. The vision becomes the finish line that each member moves towards. They know every action contributes to completing this vision. An uncompelling idea or a confusing vision depletes motivation.
Creating a compelling vision is like writing a business plan on why the project needs to exist, who it’s for, how it’s different from the competition or available options, and how it will add value to the business or organization so it requires a good deal of homework before presentation. A kickoff meeting for the specific project is a great way to get all team members together, share the vision, listen to their questions, foster discussion, and generate energy for the project.
Author a Project Brief
A project brief is a short document that gives a succinct summary of the overall current situation, goals, approach, high-level plan, and stakeholders. This brief is a document written and best shared after an intake or kickoff call. I author briefs on every project I’m leading because it summarizes the initiative so every stakeholder understands why this project is necessary, what the project will achieve, and how the project will achieve it. I always share a draft with my stakeholders for review and approval to get the team on the literal same page. I position the brief as a living document that the team and I can add to as the project goes on.
Here’s my recommended outline of the project brief:
- Overview: Start with a summary of the current situation that requires this project. Include assumptions that each team member needs to agree to prior to starting the project so there are no misunderstandings as the project goes on.
- Goals: List the primary goals. Making each goal specific, measurable, actionable, realistic, and timely (SMART) gives confidence to stakeholders and team members.
- Approach: Describe how you will accomplish the goals. For example, will the team create and deliver something? Complete specific research? Identify an opportunity? The approach is specific to the project type. For new products, an approach like design-thinking or lean startup methodology is typical and can be described in this section.
- High-level Plan: Provide a table that lists high level tasks or milestones, any deliverable that stakeholders will see when the task is completed, and an expected completion date. This plan shows stakeholders and team members how the approach breaks down into discrete and clear tasks. Keep the plan high level to illustrate the overall milestones, deliverables, and schedule. All team members can use this plan to see how the project can come together, but save the details for a project manager who can translate the milestones into specific actions.
A great way to engage team members and build alignment is to collaborate on the brief creation — especially the high-level plan. Each team member is an expert in their subject area, so each can offer tasks, deliverables and timing that ensure their role and work is represented. - Stakeholders: Use the RACI (responsible, approval, consult, and inform) format to list all project stakeholders and their role on the project. When it’s time for reviewing the brief and all deliverables, this list makes it clear who to send the review email to and who to CC.
Set Up Regular Meetings
Once the project starts, regular communication is essential to keep team members moving forward. For meeting cadence, I like weekly for bigger teams on longer timelines or bi-weekly meetings for smaller teams with quicker deadlines. Checking in frequently regrounds the team in vision and goals, brings everyone together to discuss status and any challenges, and keeps the momentum going.
At the start of each meeting, I give an overview of the meeting’s purpose, where we are in the high-level plan. I ask each team member to speak briefly at the meeting. go “around” the often virtual room for each team member to give an update on their progress: what they’ve accomplished, what they are working on now, any challenges/concerns/questions, and what their next steps are. This style is a SCRUM-lite version in the Agile process. I’ve used a variety of tools to keep track of meeting notes like Trello, Airtable, or Google Sheets and Docs. Every team member usually has 100 other projects they are a part of, so the purpose of note taking is not to hold receipts, but to refresh everyone’s memory and help them focus.
Foster Transparency
On every project I’m leading, I create a collaborative shared folder and documents for each artifact the team and I author. At the very least, the open-access documents should include the project vision, brief, deliverables, and meeting notes. By sharing, I create an open-minded ethos for the team and enable stakeholders to access any document at any time. When team members need to share documents with their peers, they can easily share a link.
This shared approach takes a little time, but the transparency creates an open archive for the project. All team members and stakeholders can see what’s been done, where the project is going, and the progress of the team. If a new team member joins, they have a library of project knowledge to get up to speed. At the end of the project, the team can see all they’ve accomplished and refer to the project as a template for future work.
Seek Understanding
On each project, at each phase, each team member has questions and concerns. As leader, it’s my responsibility to understand any team member’s concerns and questions before offering my opinion or direction. Concerns and questions come over chat, email, document comments, meeting discussion, and or happy hour. I’ve learned to always listen to them, ask follow up questions to understand the “why” of their concern/question, and then proceed. After I understand, I usually ask if they have a recommended solution to their concern, which they usually do, and need to voice it aloud. Ten times out of ten, their recommendation is the best way forward to address their concern.
If they don’t have a recommended solution, I ask them what they need to address the concern. If they can’t provide either, then I ask them to let me know what they need as a next step. Once they identify what they need, then I help them get it to resolve their concern.
Identify What I Can’t Control
In my career, I have led successful and unsuccessful projects. All my projects gave me lessons where I can improve my own leadership and performance. Some projects drove me crazy. It took me years to figure out why because often my manager and I placed blame on myself for any failure. As I matured, I spoke with my friends who are also cross-functional leaders and learned unfortunate truths and awful horror stories related to sexism, racism, and ableism.
Sometimes, I couldn’t succeed because of a team member’s misogyny or bullying. Recognizing what I can’t control like a person’s biases, a toxic culture, bullying behavior, or general unwillingness helps me keep my sanity regardless of the project results. In these cases, I have enlisted help from my manager and their manager or, if the behavior violated company policy, HR. Sometimes they’ve helped and sometimes they haven’t, but I realize there’s only so much I can do and can make decisions accordingly.
Cross-functional leadership is an essential managerial skill and one I’m proud to learn and practice. Each project gives me new lessons, and I’ve found that I rely on these five practices every time. I hope you find them helpful as well. Let me know in the comments your experiences, tips, and questions too!
