Picking Your Software Team Battles: It's About the Product, Not Winning

A coworker of mine sent me this excellent blog post, entitled "How to Pick Your Battles on a Software Team." Life's about making choices, and the blog outlines how to make the choices that will maximize both team productivity and morale. The blog comes down to two questions:

• Can you win?
• Is it worth it?

"Can you win?" is vital: if the big boss says you're doing it, then do it. Sometimes you don't get a say, and that's the way life is; that's the reason the boss is the boss. Someone has to make the final decision, and that's not always you. You do, of course, have every right to say, "I don't believe this is the best approach and here's why," and you should say that. If you don't, and it turns out the boss was missing vital information later, your judgment will be called into question. Your responsibility is to make thoughtful recommendations during the planning process. A healthy work atmosphere is one in which you can state opposing views without fear of reprisal. (Note: reprisal is getting fired or demoted. Reprisal is not about being told no. That's just adulting.)

Take the Battle Inside

After your passionate disagreement, the boss can, and will, say, "Duly noted. Do it my way." At which point: do it her way. It behooves no one on the team to beat your dead horse into smithereens, and certainly not in a group meeting. If you feel passionately that the approach is all wrong, schedule a private meeting with the decision-maker. Private meetings offer both of you the freedom to explore deeper questions without risk of embarrassment. If you're anything like me, I fall into defensive postures and lose professionalism in a more public setting. I'm no Richard Hendricks (I've never bloodied my nose in a meeting), but I definitely dig in my heels when I have an audience. That was pretty badass, until it wasn't. Solution: I remove the audience so I can make a clear-headed argument. A private meeting, scheduled for later, allows my cooler head to prevail. Whether or not I "got my way," I've rarely walked out of the private meeting not feeling satisfied that my voice was heard and considered.

Build a Better Box

Here's where the rubber hits the road: even if you don't like the idea, step back, take a deep breath, and put as much effort into the new direction as you'd put into your own idea. Make like the Pied Piper team and surpass your expectations. Note: spoilers ahead for the Maleant Data Systems Solutions episode of Silicon Valley. Just because making the box sucks doesn't mean we have to suck at making it. Richard and the team were absolutely against building a box, and had even developed an elaborate skunkworks plan to execute their own vision of Pied Piper. But because they love solving problems--and can't help but provide great solutions--they end up building a better box. Sometimes the best solutions come out of the most challenging circumstances. If your decision-maker wants a different solution, take it as an opportunity to succeed despite yourself.

Who Cares More?

Sometimes, all things are equal. The execution is based entirely on preference, and is unlikely to change the end result in any measurable way. Or, if it does, your projection of the end result is based purely on instinct and best practices, not on any hard data that can accurately predict the outcome. After 20 years in the workforce (and nine years of marriage) I've learned to recognize the point where I must ask: Is this issue more important to you or me? I DON'T CARE! It comes down to the question of personal passion. I've found myself in many meetings where I suddenly realized I was defending an idea that would work exactly as well as my teammate's. Or that, with the deadline looming, a protracted battle would cause more damage than good. In those cases, I take a deep breath, step back, and cede the floor. Just recently, I said in a meeting: "I am completely agnostic on how we handle this. Tell me what I need to provide for the end product and how I can manage the process." Tip: "I am agnostic" means you believe either solution will work. "I don't care" means you don't care about the project, and "Do what you want to do!" means "You better do what I tell you, or you'll be sorry." (To my mother, anyway.) The key here, of course, is tone: keep it professional and clear. Don't get defensive or flippant, a la Pierre, who was eaten by a lion because he was so "agnostic" about his circumstances. We can all agree that getting eaten by a lion is not a desirable outcome for any project.

Know Thyself

In the end, it's about using your energy to solve a problem, not defending a rock vs. a hard place. Know when you're being stubborn and when you're being passionate. Know when the battle becomes more about winning than it does about the good of the product. Development isn't about winning: it's about creating great solutions. Read the article: How to Pick Your Battles on a Software Team