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.
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.