A big organization, like Windows, needs to be aligned and work together to produce a great cohesive product. This means teams talking to each other about dependencies, interfaces, and timelines. That communication is crucial to tying together seamless customer experiences, reducing friction, and delivering value smoothly and efficiently. Unfortunately, humans are lazy, selfish, and suck at communication.
Lazy, selfish teams don’t want to deal with demands from others. They’ve got their own problems and desires and don’t care about yours. Since they must appear to be “good partners,” they’ll do the minimum to make other teams shut up and go away. That typically involves collecting prioritized requirements from partners, responding with dates when those requirements will be met, or making excuses as to why a third team should help instead. Responding that way is passive-aggressive behavior at its finest.
Instead of discussing the customer experience, these passive-aggressive teams argue over requirement lists and dates. The teams consuming dependencies believe their requirements won’t be delivered properly or on time, and the producing teams believe the requirements are excessive and the dates are outlandish. All the teams exaggerate their priorities and timelines, hoping to negotiate an acceptable middle ground. This game of mistrust is considered normal, and that’s outrageous. There’s a better way.
You complete me
When partner teams ask your team to help complete their customer scenarios, you could ask for a list of requirements, but that completely misses the point. Partner teams are like customers–they are clueless. They have no idea what you do, how you work, what your component really does, or what it’s capable of doing. Their list of requirements is bound to be misguided, incomplete, and excessive. As I discussed in When the customer is wrong, customers (and partners) don’t understand what they want or need–they only understand the problem they are trying to solve. That’s where you start.
Instead of creating a list, start with what your partner is trying to accomplish. Ask questions. Be curious. Deeply understand the customer experience and scenario, as well as your collective role in bringing them to life. It might take 20 minutes or more to grasp the problem, but that is time well spent.
Once you truly grok the problem, you can begin to address it. What does your partner really need from you, if anything? How best can you provide what’s needed in the time available? What are the steps along the way that can help you both validate that you’re on the right track (The value of navigation). Now you are solving the problem and building trust, which is far more valuable than exaggerating and arguing over misguided, misunderstood malarkey.
Too much
“But our partners always ask too much!” say the lazy, selfish teams. “We’re not lazy and selfish–we’re pragmatic and responsible!” You are lazy if you fail to deeply understand what your partners are trying to accomplish. You are selfish if assume your work is more important than others. Instead, show the respect and take the time to listen to your partners, ask them questions, comprehend their problem, and come to a shared picture of what’s needed.
“But our team doesn’t own that area!” say the lazy, selfish teams” We’ve got to stay focused and deliver on the areas we do own!” Who do you think writes your paycheck? Your team lead? Your group manager? No. Microsoft writes all your paychecks. You can get away with being shortsighted and team-centric as a senior engineer or below, but to succeed as a principal engineer, you’ve got to go beyond. If partner teams need help delivering an important customer scenario, you have an obligation to at least hear them out and help point them in the right direction.
Once you and your partners are on the same page, you can discuss your constraints. Everyone lives within limits–doing so is not insulting or surprising. Being honest and candid builds trust. Brainstorm different solutions that fit within your constraints, involving other teams as needed. You’ll be surprised at the creative solutions that pop when everyone understands each other’s issues and limitations. Maybe you can stage your improvements over time. Maybe you can be aggressive, but have a fallback position. Maybe you can suggest cheaper alternatives that are good enough to get started.
The key is to build trust through understanding, honesty, and acknowledgement. Then use that trust to work together effectively on a solution that meets everyone’s needs in order to deliver value sustainably, responsibly, and with high quality.
Eric Aside
For more about dealing with dependencies, read You can depend on me. To better understand negotiation, read My way or the highway.
Why are we here?
We love our customers and partners. They are the only reason we’re gainfully employed. Yes, they can be demanding. Yes, they often are misguided and clueless. But our job is to listen to them, understand them, help solve their problems, and make them successful.
Microsoft’s mission is to empower every person and every organization on the planet to achieve more. This includes our co-workers. Don’t resort to prioritized lists as a way of communicating requirements. Instead, learn about the experiences we are trying to deliver together to our customers and to developers on our platforms. Dig deeper, beyond the perceived needs, down to the real problems, so that we deliver solutions instead of feature lists.
When you truly partner with other teams and acknowledge each other’s issues and constraints, distrust becomes respect, arguing becomes brainstorming, problems become challenges, and competition becomes winning together. The choice is yours. You can be cynical, frustrated, and annoyed, or you can be open, curious, and collaborative. Choose wisely–for your own sanity, for our shared success, and for the benefit of all the customers we serve.
Be First to Comment