To have a successful project, you need to trust your team, and they need to trust you.
This is obvious on some levels. Your team must trust that they’re going to get paid, and you must trust that they’re not going to copy your whole database and sell it to your competitors.
But trusting your team should mean more than that. To achieve real, powerful teamwork, trust must go far beyond, “I know you won’t cheat me.”
Teamwork & Shared Goals
Members of amazing, productive teams trust that all the other members want to help them. Put simply:
- Members must share a common vision of the project goals and priorities, and
- Everyone must believe that everyone else shares that vision.
It’s not enough that we’re working toward the same goal. We also need to believe that each other’s actions are based on that goal. That’s real trust.
Where Are We Going?
When team members don’t have this kind of trust, they don’t rely on each other, they don’t get the best from each other, and the project suffers.
For example, suppose you’re visiting my city for the first time, and I pick you up from the airport. I ask you where you’re staying, and you say, “Don’t worry about the destination. Just turn right here.”
Strange, right? It’s much more likely that you’d just tell me the destination (“I’m at the Marriott downtown”), knowing that I have local knowledge to help me navigate. You would trust that I share your goal (getting you to the hotel), and you’d appreciate my understanding of local congestion, construction, etc.
Unfortunately, although software projects should work similarly, they often do not. I’ve worked with clients who try to plan out a software product themselves, down to the smallest detail, then bring developers in to simply implement their plan.
Rather than trusting us with their vision—empowering us to help them reach it—they give us step-by-step directions. And this lack of trust keeps us from bringing everything we have to the project.
I suspect customers think they’re helping when they shield us from worries and complications involving their business, but that “protection” can easily become an impediment rather than an asset. When you shield me from those distractions, you also shield me from information.
On Collaborative Teams, Everybody Navigates
Jason Porritt recently wrote about the Design Thinking idea that successful products are the intersection of:
- People’s needs
- Technological feasibility
- Business viability
If you come to a software team with a project, you probably are very knowledgable on the business viability side. But your consultant can provide extremely valuable feedback on technical and user experience matters. It’s our area of expertise–our livelihood.
We can identify which features are common patterns, and which implement new (and risky!) things. We can look at your long-term vision and try to identify the right amount of foundation to build. We can help you find useful ways to test out ideas while minimizing rework.
We don’t know where the value is—that’s knowledge you bring to the table from the business side. But we do know where the cost is, and together, we can optimize it. We don’t need every person on the team to be an expert in anything—but someone from each discipline should have the broad strokes for the short, medium, and long terms.
We Can Build the Best Things Together
We don’t need you to answer to every question on Day One. We don’t need pixel-perfect designs for every page.
But we do need you to share your vision. Share your “why,” and let the team extract maximum value out of everyone’s unique perspectives.