Beliefs

I have a lot of beliefs drawn from experience that shape my behavior as a manager and contributor. If you’re interested to know what kind of philosophy I bring to an organization, feel free to read on. You’ll get a fairly good sense of what I’m about.

No ideas but in things

Ideas are cheap. Even great ideas are dime a dozen. An idea without an implementation might well be perfect, but it’s worthless in the absence of execution. It’s the implementation in which all of the interesting issues are worked out. Some great ideas are flawed only in practice.

Don’t get me wrong; I love ideas. I love talking about ideas with people. But it’s easy to get swept up in the fun of splashing around in them and forget that we’re really in the business of carrying water. What matters is execution. Doing the work properly, correctly, thoroughly, cleanly, beautifully. That’s the art. That’s what creates value. An adequate idea executed flawlessly will trounce a great idea done shoddily every time.

No originality

If you have a great idea that hasn’t been had before, you are either a phenomenal genius or the idea is bad. But the good news is that this relieves considerable unnecessary burden on thinking.

No need to fear the past or present. No need to reinvent everything, keep yourself willfully ignorant, deny your influences. It’s not the same as not believing in creativity or combining existing elements in surprising and delightful ways. Just accept that having the same perfectly good idea as other smart people means you really might be on to something. (Then execute better than everyone else, and you’re set.)

No malice

It’s stunning to me how often people assume other individuals or groups are aligned against them. In my experience, it simply isn’t the case. There is no hostile world wishing us to fail. That said nobody is invested in our success either unless we give them a reason to be. Mostly, people are bound up in their own narratives where we don’t figure nearly as prominently as we think we do.

In scenarios where there is actual competition for resources, it is realistic that other groups wish to advantage themselves over us. If the situation is internal to the organization I try to figure out what the best outcome is at a higher level. I won’t fight a battle if I don’t believe in the war. It is highly likely that it’s better to join and align efforts than to pit them against each other.

If the competition is external, the only thing to do is game up. Everybody wants to win. To vilify the other side is to fall into a trap in which you can’t realistically understand their motivations. (That said, we shouldn’t be denied the unifying simplification of a common enemy as long as it remains in fun.)

Be wrong

I’m wrong a lot. I love to find out I was wrong. It’s a clear indication that I’m learning. Each time it’s one more mistake I never have to make again. Admitting to someone I was wrong is a great gift I can give them at essentially no cost. I often see people clinging to indefensible positions simply so as not to have to admit having been wrong. Embrace wrong! Demonstrate to others that you have the capacity to learn.

There’s a corollary to this: Trying to move forward always being right is a recipe for paralysis. Go ahead and give yourself the latitude to be wrong. Just move the ball.

Everything is technical

Everyone’s job, when done artfully, is technical. As developers we have the tendency to imagine ourselves to be at the tip of a pyramid of technicality, masters of languages sensitive to single characters and symbols. Dealing in the messier realms of human interactions seems soft and aimless. In reality working with groups of people involves problems of specification, concurrency, latency, noise, impedance, availability, failover, and protocol that the complexity of software can’t touch. The interest of any problem is in its details.

Don’t do what I say

The person I most want to hire never does what I tell them to do. Instead they do something better. They figure out what really needs doing instead of what I described. (Why shouldn’t they? They’re likely to have better information, and they certainly will spend more time with the problem.) They keep me informed, but they don’t wait for my approval. I love to encounter something that stretches me beyond my own initial imagination of a solution.

Never rewrite anything

Invariably, those who have not experienced the pain of a protracted software rewrite underestimate the difficulty of the task. Legacy software is often not well specified. Its only specification is the code that embodies it. Every line, every possible execution path multiplied by every program state is a behavior that the new system must either match or reject consciously and replace with a superior alternative. Instead of a grand rewrite, consider targeted refactorings. There is no reason a legacy system cannot be improved incrementally. If it is delivering value, avoid a wholesale rewrite at all costs. (Joel Spolsky writes about this problem quite convincingly.)

Stay flexible

I can’t state this any better than the framers of the Agile Manifesto did. Responding to change is more important than having a great plan. Stable requirements are myth. Teams lose people and hire others. Markets expand and contract. Getting and integrating proper feedback from customers is the only way to know which direction is right even for the near term. If your team has the same dreams of the future year in and year out, when the time rolls around to implement them, they’ll already feel old. Roadmaps are great. But no artifact should be privileged over experiment, trial, and error.