"David," I told an old colleague a few weeks back, "I won an argument that I should have lost."

Our argument was about Adobe Flash and it took place in 2009 and 2010. Charged with creating a user-centric vision for our engineering team, I argued for using Adobe's Flex toolkit. Flex promised greater developer productivity when compared with JavaScript as well as a native-like UI feel. Everyone had Flash installed, and so the objections seemed foolish to me. David argued that, according to his research, developers were writing UIs in Javascript. The launch of the iPad, which happened in the midst of the argument, strengthened the opposition to Flash. David wasn't the only one who felt that way. Several folks agreed with him but didn't fight aggressively. But, as the "UI guy", I won the argument by default.

Five years later, it's quite clear that we would have been better off if I'd listened to David. Certainly some hindsight bias is in play here. Before it launched, we actually didn't know that the iPad would succeed or that Flash would become irrelevant so quickly. But it's worth noting that my arguments in favor of Flash really didn't work out. We weren't especially productive writing our Flash UI. JavaScript development wasn't nearly as hard as I expected, once I forced myself to learn.

Even in the most meritocratic of environments, ideas win not based on their merit but based on the quality of arguments used to advance those ideas. And sometimes ideas win based on the caliber of the arguer.

That experience scares me. It isn't enough for me to win an argument. My job is ultimately to reach the best outcome, even if my arguments need to lose for that to happen. Fighting for the best outcome means that I need to encourage arguments that I might disagree with.

I saw a similar situation at work recently. Two people were arguing over project priorities. The person who backed down first lost the argument even though, in my opinion, that person had the better argument. Backing down had little to do with conceding the superiority of the opponent's point. One arguer was simply more skilled at debating than the other. The other, meanwhile, didn't derive any joy from continuing to fight.

I wish there were some system or trick for arguments to win on their merits. But, since there isn't, it falls on the arguers to know their strengths and weaknesses and to adjust to them. Strong arguers need to be careful that their confidence and argumentative skill don't lead to their winning arguments that they should lose. Weak arguers, meanwhile, need to get better lest they never contribute to their full potential.

The fallacy of the root cause

Everything would be a lot easier if every problem had a root cause. Fix X and you'll have better software. Fix Y and your favorite sports team will become a winner. Just change Z to solve the gender imbalance in the tech industry. But that's not reality. Big problems have multiple causes, and those causes interact with each other.

For instance, David Simon argues that societies flourish only when capital and labor balance each other out. "Labour doesn't get to win all its arguments, capital doesn't get to. But it's in the tension, it's in the actual fight between the two, that capitalism actually becomes functional, that it becomes something that every stratum in society has a stake in, that they all share."

We wrestle with similar problems in software development. As the leader of an engineering team, my job isn't to find a magical root cause of greatness and to address it. My job is to enable a productive tension in a system that I don't completely control. We must move quickly, but we can't let speed win out over quality. We can't become so paranoid about quality, though, that we stop taking prudent risks. User focus matters, except when it's at odds with making money, which is great, except when it conflicts with our reasons for writing software in the first place. We must listen to our customers, but we must not let them enslave us into building "faster horses."

Getting the tension just right is hard. For instance, I've struggled before with how to balance risk management with the other responsibilities on a team. In a past job, we became too conservative. Our specs, reviews, approvals and tests made it hard to screw up, but those same processes overwhelmed our other responsibilities. We slowed down and locked ourselves into a cycle of hill climbing. At GameChanger, however, risk management processes have made us faster and more confident. And greater confidence has enabled us us to take bolder risks.

It concerns me when we try to reduce a big problem down to a single root cause. It's happening right now with this weekend's storm over Paul Graham's comments on female startup founders. Does a gender imbalance exist in the tech industry because investors like Paul Graham aren't pulling their weight? Or, as Taylor Rose argues, is Graham correct in identifying middle school as the time to get girls interested in computer science? Or is the locker room mentality that surfaced at PyCon to blame?

Yes and no. All of the above and none of the above. Big problems lack root causes. They arise from many forces that interact. Addressing big problems requires creating just the right tension between just the right forces.

Updated 12/30 to fix a typo at the end of the third paragraph.

Ideas and values

Should we be like Twitter and build everything on top of a public API? Should be be like Wordpress and let anyone work wherever in the world they want? Should we be like Google and restrict the languages that people can use in production or like Amazon and let people use the languages of their choice?

I recently read Scott Berkun's The Year Without Pants, a book about Wordpress. It offers an insight that rings true. You can't just borrow other companies' practices without developing the cultural values that make those practices work. Culture creates the environment in which practices can succeed.

Facebook, for instance, proudly declares that speed is a core value. A company with less tolerance for error wouldn't have the tolerance for their freewheeling, speed-trumps-all culture. Wordpress, meanwhile, owes its very existence to its autonomous, distributed and independent-minded open source community. It couldn't exist without embracing the autonomy and chaos that are central to open source development.

The cultures force them to develop processes that others wouldn't. e.g., Facebook's release process helps them work fast. Wordpress's P2s enable them to work in an autonomous, distributed way.

But, now that Facebook and Wordpress have developed processes, can't we apply those processes to our own jobs? Only if our culture offers enough support for those processes. Working at speed is great, but what if you cause a customer to lose data? What if, by moving quickly, you infringe on some product manager's turf? What if you confuse customers, leading to a ton of support inquiries? Will your company support you? Will they let you keep the peddle down until you've developed the systems that let you move safely and quickly? Or will they slow things down and find a way to operate more safely right away?

Should I do what Google or Facebook or Twitter does? Maybe. Stealing their ideas only makes sense if my values can support those ideas.

Building great things

This is a blog about building great things. That topic is inherently not simple. It spans a system of creators, technologies, markets, and customers who interact in surprising ways. It can’t be reduced to concepts that are too simple or too quotable — not without losing something important. Should you really trust your gut feelings? Do Minimal Viable Products actually succeed at their goals? What’s the downside of short iterations?

This blog will wrestle to understand great ideas that don’t shy away from the complexity of real life. These ideas are difficult, and their authors don’t all have mainstream following. I’m thinking of people like Donald Reinertsen and Sidney Dekker and Bill Buxton. This isn’t a takedown blog for pop science, pop engineering, or pop business. Just google “Malcolm Gladwell criticism” or “<technology X> sucks” if you’re looking for that.

Content will span all aspects of making great things — from engineering to design to business to organizational culture — depending on what I’m currently obsessed with.