Looking up and down the power continuum

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

The Modern Way To Build Your Product Team

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:

  1. Keep the teams small – “Small teams have a singular shared focus on the customer problem at hand.”
  2. No shared resources – “Want to move slow? Want to deal with politics? Have your product teams share resources/dependencies.”
  3. 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.

Only a Fool Learns From His Mistakes

steve blanksgblankJul 12, 2016, 3:16 am 
Only a fool learns from his mistakes;
wise men learn from other people’s mistakes
– Bismark

Happiness

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, …

Collaborative Pre-Reads for Meetings

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.

Rule #20: Ask for opinions

Unwritten Rule of Engineering #20: Cultivate the habit of seeking other people’s opinions and recommendations.

You cannot hope to know all you must about your field and your employer’s business. Therefore, you must ask for help from others; routinely seek out those who are “in the know.”

This cannot be emphasized enough and is an especially frequent flaw in newer engineers who believe they know everything. Typically they do not understand the larger context and thus make locally optimal but globally sub-optimal decisions; decisions that could have been avoided if they had asked for advice from others.

Rule #19: Be inclusive

Unwritten Rule of Engineering #19: In all transactions be careful to “deal in” everyone who has a right to be in.

It is all too easy to overlook the interests of a department or individual who does not happen to be represented, or in mind, when a significant step is taken. Even when it does no apparent harm, most people do not like to be left out when they have a stake in the matter, and the effect upon morale may be serious.

Note particularly in this and the preceding rule the chief offense lies in the invasion of someone else’s territory without that person’s knowledge or consent. You may find it expedient on occasion to do parts of other people’s jobs in order to get your own work done, but you should first give them a fair chance to deliver on their own or else agree to have you take over. If you must offend in this respect, at least you should realize that you are being offensive.

Rule #18: Don’t do an end run

Unwritten Rule of Engineering #18: Never invade the domain of any other department without the knowledge and consent of the manager in charge.

This is a common offense, which causes no end of trouble. Exceptions will occur in respect to minor details, but the rule applies particularly to:

  • The employment of a subordinate. …
  • Engaging the time or committing the services of someone from a different department or division for some particular project or trip. …
  • Dealings with customers or outsiders, with particular reference to making promises or commitments involving another department. …
  • Performing any function assigned to another department or individual. …

There is significant commentary on this last principle that should also be observed: in general you will get no credit or thanks for doing the other person’s job at the expense of your own.