I’ve been watching Sex and the City with my wife. I’d gotten her to watch a lot of other shows of my choosing: Breaking Bad, The Wire, Justified, and I thought I’d try something from her corner of the television universe. We blasted through all six seasons, alternating between HBO Go and the (very large) pink album of the complete series sitting on our shelf when our internet crapped out. We watched the first movie last night. There are a lot of lessons to be learned from that show, and most of them are of the “What not to do” sort.
[Spoiler alert!]
Last night, Carrie and Big were arguing about the size and impact of their nuptials.
Big angrily shouted “200 people! Page 6! Do you know how that makes me look?”
I shouted back at the TV (I do that): “No, because you don’t communicate your feelings with Carrie!”
In fairness, Carrie isn’t good at that either, but that brings me to my point: communication is key.
Communication: Not Just For Personal Relationships Anymore™.
I see this as a problem in software development all the time. People talk about the “tension” between sales and engineering, but I don’t have to look that far. I see the tension within engineering. I see the tension within QA. I see the tension everywhere. People wanting one thing but getting another. People getting what they didn’t want and attributing the gap to the deliverer’s shortcomings.
I’m here to tell you, if you aren’t getting what you want, you might not be communicating what you need.
I’ve been guilty of this as much as anyone.
The project was incredibly important. The Big Boss was going to be the first customer and every T had to be dotted, every I had to be crossed.
“It is vital that we make a good impression,” I said.
“Failure is not an option,” I said.
“You know what you have to do,” I thought.
The project did not go well.
Afterwards, a few things were clear: my bar for success was at a 9. The Big Boss’ bar for success was an 8. Folks on the project thought they were hitting a 9. Unfortunately, we were not all working on the same scale.
What went wrong?
The specifics are unimportant, but I know what could have been more right.
Instead of “It is vital that we make a good impression,” I should have have said “X, Y, and Z need to be done or else I and The Boss™ will be displeased.”
Instead of “Failure is not an option,” perhaps “Talk to me about your plans for accomplishing X, Y, and Z.”
Forget, “You know what to do.” Assume that you’re not on the same page and go with “What I’m hearing is ABC…”
By assuming that we were all on the same page, I ensured that we weren’t, and it wasn’t fun.
Setting expectations in project management is staggeringly similar to setting expectations in any relationship. What do you want out of your romantic relationships? Stability? Support? Excitement? This isn’t a “choose two” sort of game, but you do get to choose how much of each you want. If you want 1% stability, 40% support, and 59% excitement, you’ll probably end the night at the police station after driving the getaway car for a bank robbery. If you go 1% stability, 10% support, 89% excitement, your partner will take a diving roll out of the car leaving you to hold the bag.
How can you avoid these sorts of problems? Imagine that you’re figuring out the details for your next date.
You say: “Is there anything you’d like to do? See a movie, play some mini-golf, go for a hike?”
They say: “Let’s be spontaneous. Are you up for an adventure?”
Let me stop you here, for a second.
The fun, devil-may-care response is “You bet!” but you might want to couch that with your own limitations. How spontaneous do you really want to be?
You might say: “Sure, what do you think about meeting at the corner of Main Street and First Avenue, and walk around until we see something that catches our attention.”
Maybe you really don’t want to go swimming under any circumstance, and so you want to avoid beach outings at all cost: communicate that with “Yes! I’m up for anything but a swim.”
Maybe you actually want to rob that bank. I’ll leave that one as an exercise for the reader.
In software development, we tend to think about Quality as a function of Scope, Cost, and Time. Are you willing to compromise on your scope to get your feature out quickly and cheaply at the highest quality? Are you willing to compromise on quality to ship all of your features quickly? Can you delay shipping to get all of the features out, near-buglessly (and without accruing overtime or pulling staff off of other projects)? Likewise, you need to be on the same page as your business partners.
Let them know what their options are: “We can definitely ship the map with locations, but navigation is going to have to be in the second iteration unless you’re willing to delay the release by 2 weeks or take Tom’s team off of the Account refactor.” Why? Because there just isn’t time for your team to finish in time at the quality you want. You need help or more time.
“We can definitely ship everything by the end of the month, but the team hasn’t used this library before and half of the team is new to writing unit tests. If we can’t delay the release, we should label this a Beta because it will probably be buggy.” Why? Because you have a lot of technical risk, so you have to balance quality for time.
“Bob says he wants the coolest UI so that we drive adoption by teenagers but he doesn’t know what will engage them. Sue’s been doing this for 20 years and thinks she knows what’s best. Gina, we should run an A/B test to see how well Sue’s UI is doing with the teenagers of today.” Why? Because it sounds like Bob has an idea of what he wants, Sue has an idea of what will work, and you want some real data to help make the final approval decision.
I can’t tell you what attributes are most important to you. Time, quality, cost, or scope? Stability, support, or excitement? Whatever you find most desirable, let your partners know. In life, in love, and definitely at work.
Matt Newkirk's NotSoSoftware 