[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (6 crucial tips for leading a cross-functional team)
[#]: via: (https://opensource.com/open-organization/19/8/tips-cross-functional-teams)
[#]: author: (Michael Doyle https://opensource.com/users/mdoyle)

6 crucial tips for leading a cross-functional team
======
Leading work that cuts across teams and departments isn't easy, but
taking an open approach will help you succeed. Here's a checklist for
getting started.
![a big flag flying in a sea of other flags, teamwork][1]

So you've taken on the challenge of leading your first cross-functional project, one that requires voluntary effort from people across organizational functions to achieve its objective. Congratulations!

But amidst your excitement over the opportunity to prove yourself, you're also feeling anxious about how you're _actually going to do it_?

Here are six tips for leveraging [open organization principles][2] to help you shine like the leader you truly want to be. These tips are drawn from my experience having led cross-functional projects, and from my conversations with other-cross functional project leaders.

### 1\. Start at the top

Executive sponsors who care will make your work feel like you're not swimming against the tide. Ideally, you'll want a sponsor who understands your project's importance to the organization—someone who can regularly motivate the team by demonstrating how this project delivers on the organization's goals, and who will, in the process, celebrate and promote the successful work the team achieves.

If your executive sponsor doesn't look like this, then your first responsibility as a leader is to guide them to clarity. Using the open organization value of inclusivity, give your sponsor clear feedback that will help them identify the project's priority. For you to be successful, your executive sponsor needs to clearly understand why they're sponsoring this project and be willing to support it all the way to its completion. That means being prepared to commit some time after the project kick-off to receive updates, remind the team about why this project is important, and to celebrate success. Your duty is to help them understand this.

Having this conversation with your executive sponsor might seem confrontational, but you're actually stepping up to your role as leader by caring about the success of the project and all the people who will be involved. On a few projects in which I was involved, this step helped the executive sponsor see that they didn't really _need_ this project. Think of all the resources saved because the executive sponsor made that decision earlier rather than later.

### 2\. Why ask why

Now that you've secured a committed executive sponsor, it's now time to translate their vision into the team's shared vision.

This might sound like a trivial step, but it's an important one for achieving team buy-in; it turns the executive sponsor's reasons for the team's existence into the team's _own_ reasons for existing. The open organization value of community is key here, because as the project leader you are helping build the necessary framework that provides the team with an opportunity to contribute to, understand, and agree on the problem scope presented by the project sponsor.

Notice I said "problem" and not "solution." Guide the team to agree on the _problem_ first, and define and agree on the _solution_ to solve it second. As you do this, make sure that each team member can voice concerns. Listen and note those concerns rather than giving reasons to dismiss them. You're going to need each team member's _real_ commitment to the project—not just a head nod. Listening to team members is the founding conduit through which this happens.

In an ideal open organization, people come together naturally and for the right reasons. Unfortunately your project exists in a real organization, and sometimes you need more than a verbal agreement to get such buy-in to stick.

In an ideal open organization, people come together naturally and for the right reasons. Unfortunately your project exists in a _real_ organization, and sometimes you need more than a verbal agreement to get such buy-in to stick. This is once again an opportunity to step up as a leader. Talk to each team member's manager and work together to connect the work they will do on the project to their performance and development plan. You'll want to make sure the team member and their manager are touching base on the project in their one-on-ones and factoring in behavior and outcomes into any financial compensation mechanism your company has (bonuses, salary review, etc.).

With this key step in place, you'll have the buy-in you need when the going gets tough as team members struggle to prioritize project work with their day-to-day responsibilities.

### 3\. Lights, camera, action

Movies work because everyone knows their role and the roles of others. They know what they are supposed to do and when. Your team needs this too, and you can shine as a leader by helping them create it.

Work with your team to draft some kind of "team agreement," guidelines team members have developed to structure _how_ they must work together to create a positive, productive process.

Work will flow smoothly if every team member understands what they're expected to deliver. As a leader, you're facilitating the open organization value of collaboration by giving each member an opportunity to define their role. You need to have an idea of the roles required to deliver the project, and you need to consult with the team to make sure each member is a good fit for the role.

At this point, you'll also start to define common vocabulary the team must understand to ensure they can work together smoothly. Don't take anything for granted here; use any opportunity to establish that common vocabulary by asking team members what they mean when they use potentially vague, ambiguous, or domain-specific vocabulary. For example, a team member might say, "We need to have a robust review process after each milestone." That's a great opportunity to ask, "What does a robust review process look like to you?"

### 4\. Mirror, mirror on the wall

Now that you've identified—and documented—the team's roles and common vocabulary, it's time to make sure you define yours.

Movies work because everyone knows their role and the roles of others. They know what they are supposed to do and when. Your team needs this too, and you can shine as a leader by helping them create it.

In my experience a project _leader's_ role is different to a project _member's_ role. The leader's job is to work _on_ the project, not in it. Getting bogged down in the tactical and becoming the project's "hero" might scream of individual accomplishment, but it's not going to prove your leadership ability to the organization in the way you're hoping it would when you took on this project in the first place. Let the team know that you're not responsible for managing or owning all actions. Leverage the open organization value of adaptability and use your advantage of seeing a broader view of the work to help the project team see for themselves where the gaps are. Help them make the connections from the tactical work to the strategic. Hold up a mirror so they can see when they're breaking their own rules, as documented in the "team agreement." The project team should expect their leader to keep them on track, focused, organized, and informed.

Having peer support will help you here. Your peers may know the landscape of people better than you do. They can also double-check your communications before you've rolled them out publicly. Seek out a trusted peer to be your sounding board, and find one or two equally trusted sources who can help you navigate the cross-functional landscape.

### 5\. Publish or perish

Communicate well and you'll be that successful leader you're hoping to be. Communicate poorly (or not at all) and you'll be fighting more fires than Steve McQueen's Michael O'Halloran in "The Towering Inferno."

Communication is not a burden; it's a useful tool for building organizational alliances, and it asks of you only a small amount of time. In return, it delivers immense value.

As a team, identify a meeting cadence and stick to it. Cut meetings short if there's no remaining value to add to a discussion, but keep the cadence. Cadence is your lead measure. Without a regular cadence the group will slowly disintegrate. Team members need to agree to join the meeting and show up. Let up for a moment here and make it acceptable not to attend, and guess what? That's now the team norm. Don't be that leader.

Publish your meeting minutes in a location that others can find them. This is essentially the "social proof" that the team is doing its work. Nobody praises a team that acts like a black box. Don't become that team. Transparency all the way.

And the most overlooked part of this? Measure it. Never assume anything has been read or understood just because it went live on the corporate intranet or swooshed away from your outbox. Find a way to ensure you know whether people have _read_ and _understood_ your materials. You can keep this really simple: just ask them. "What's one pressing question you have from our latest project update?"

### 6\. (Never) to infinity and beyond

Communication is not a burden; it's a useful tool for building organizational alliances, and it asks of you only a small amount of time. In return, it delivers immense value.

Lastly, the project needs to be _time bound_. Team members need some _light_ at the end of the project's tunnel. If the project is multi-year, or multi-phase, then this could mean giving an opportunity for old members to leave and new members to join. Nobody wins in a protracted war.

Be a great leader and conduct a retrospective when the project is finished so you can add _your_ experience to all of this—and pass it on to someone else leading their first cross-functional project.

Here's a handy checklist of the key points to set your cross-functional team up for success.

**Checklist for Leading a Cross-Functional Team**

Step 1

✓

My sponsor is clear on the project's priority and understands what the project team expects from them for the duration of the project.

Step 2

✓

The project team agrees on the problem and understands why this team exists.

✓

Each team member's manager understands how this work fits into the team member’s performance and development and will support them in their one-on-ones.

Step 3

✓

Each team member has helped to define and document their role.

✓

As a team we have clarified and documented the meaning of common project vocabulary.

Step 4

✓

The team understands my role as project leader.

✓

I have identified and engaged peers who will support me personally during this project.

Step 5

✓

The team has set the meeting cadence and committed to attending. And they documented it in the "team agreement."

✓

I have identified how I will follow up on team communications to ensure stakeholders are engaged.

Step 6

✓

Team members know how long they are engaged with this project.

--------------------------------------------------------------------------------

via: https://opensource.com/open-organization/19/8/tips-cross-functional-teams

作者：[Michael Doyle][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]: https://opensource.com/users/mdoyle
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/leader_flag_people_team_group.png?itok=NvrjQxM6 (a big flag flying in a sea of other flags, teamwork)
[2]: https://opensource.com/open-organization/resources/open-org-definition
