The argument in Paul Graham’s “Beating the Averages” about how programmers have a hard time recognizing more powerful languages because they don’t understand their power has long been one of my favorite discussion points. The point being that it’s extremely hard to raise the quality in yourself or your colleagues because, unless you deliberately surround yourself with people who are better than you are, it’s very difficult to see “better”. I’ve had the privilege to be part of three organizations that were very deliberate about raising the bar: Amazon, OTI, and the University of Washington CS department. Each was a scary place to be because I was no longer the smartest person in the room, but each helped me raise my personal standards and achieve more than I imagined possible.
So the lesson is similar to that famous quote about poker: “look around and if you are the smartest person in the room, it’s time to find a new room”.
A nice exposition of the same principles I’ve been using to build great engineering organizations: The Modern Way To Build Your Product Team by David Cancel. First, he points out that customer expectations have changed along with the rise of software-as-a-service and the on-demand economy. They don’t want to hear “it’s on our roadmap for next quarter.” So one has to build a different kind of organization, one designed to be low latency and high velocity. That means:
- Keep the teams small – “Small teams have a singular shared focus on the customer problem at hand.”
- No shared resources – “Want to move slow? Want to deal with politics? Have your product teams share resources/dependencies.”
- The Key Ingredients Are Autonomy And Ownership – “development teams are responsible for the entire product, including operating and supporting the apps.”
An engineering organization built along these principles is a lot more fun and productive than a big company with politics and roadmaps and endless meetings. That’s the kind of place I’ve been creating for more than a decade, and if it sounds attractive to you, we’re hiring.
wise men learn from other people’s mistakes
While our Pacific Cup race did not end as I’d hoped it would with us crossing the finish line into Hawaii with a flying spinnaker after a week of fantastic downwind surfing in the tropics, to me it always about the experience rather than the result. And the experience was great. That fantastic start out under the Golden Gate Bridge, sailing through a pod of whales, struggling with the #1 on the foredeck while getting continually doused by breaking waves, sailing along under the moon so bright that no lights were needed — and then, early in the morning, sailing under the Milky Way and even then we didn’t need any lights: there was enough star light and enough absolute darkness that we could see just fine.
Life is good.
I’m headed off to Kaneohe, Hawaii as crew on a J/42 named Velocity doing the Pacific Cup race. Here’s a picture of us sailing on the Columbia River.
We should have a great time and, satphone willing, I’ll post a few pictures along the way.
My super cool geeky birthday present: a working Star Trek communicator. I love it.
One characteristic of a good leader, perhaps the most important characteristic, is whether others will follow him or her. And one excellent indication of that is when the leader moves to another company or another role inside the same company, do people want to follow him? I’ve worked with some excellent leaders whom I would follow anywhere, such as Patrick Moran, Dave Thomas, and Dave Pellerin (if any of these people offer you a job, I highly recommend that you jump at the chance!)
I’m also pleased to say that many excellent engineers and managers have wanted to follow me as I’ve taken on new challenges: I’m honored by their vote of confidence, and I always strive to live up to their expectations. Most recently a few top people from my past have joined me in my new role as CTO at InVision, and by combining them with the existing excellent engineering teams …, well, we’re just going to have a lot of fun building another great high-performance organization.
Life is too short to be working for poor leaders, so take a look around and see if you can find a good one; and one clue is whether others want to follow them.
The sun has set, the moon is up, the tall volcanos are glowing ghostly white up ahead. It’s still light but the light is fading and the dark purple is thickening on the ground. Soon it will reach up and engulf Superboy and I’ll need to turn on the lights but not yet, not yet, …
Like many engineers, one of my goals is to have as few meetings as possible. Not quite zero meetings because there are good reasons to have meetings but the key is to avoid the useless ones. Useless meetings are ones whose goals are better accomplished with some other mechanism — with the status meeting being the worst offender in the useless category. That weekly meeting where you go around the room, listening to each person talk about what they’ve done, most of which you already know, none of which you care that much about, everybody knows it’s a waste of time and yet they still occur.
In my organization, we don’t do status meetings: we only do decision meetings (and occasionally an alignment meeting). My philosophy is to make the best use of everyone’s time, all the time, and the best use of highly-intelligent humans is analyzing a situation and making a decision. Those are useful meetings.
But in order to make a decision, we need information (status), so I’m not saying that status is inherently bad, only that status meetings are inherently bad. So instead of status meetings, we communicate status with written pre-reads for status-like information, and then we jump off from there in our discussions and decisions. Some companies, such as (famously) Amazon, use this same mechanism but start each meeting with the reading of the pre-reads: I instead simply insist that everyone come prepared by having done the reading. Nobody fails to do the reading more than once.
Being a modern SaaS organization and fully in the cloud, we actually go one step further than simply having pre-reads: we use the collaborative editor Quip to write our pre-reads. This shared collaborative writing mechanism allows us to read and comment on each other’s pre-reads, and then revise and clarify our own contribution based on each other’s comments, all at our own pace and time. All of this is done in advance of the meeting and thus we arrive with a shared understanding of the status of the issues (because we’ve read all the pre-reads), as well as a complete understanding of the issues (because we’ve asked for clarifications via the Quip commenting mechanism), and are ready to dive into the discussion.
And because we come prepared, our meetings are enjoyable, efficient, and productive.