Item — HN Reader

>But universally, “sparse micromanagement” (the best term I’ve heard for jumping in to some random issue, overturning all the decisions, and then disappearing) is the worst.

Great essay. My favorite term for this is "drive-by micromanagement."

I think it's hard to make "chief architect" work out in the long term--if the role is too weak, it often becomes nothing more than an evangelist; if too strong, it often disempowers the people who are closest to the work.

For figuring out what CTO means in an organization with a VP engineering, you might take some inspiration from Google's organizational history. Google never had a CTO, but they took care to establish ways for highly technical people to have huge impact without being forced onto the management track.

The first was Google Fellow, a level of individual contributor equivalent in to a VP engineering. Jeff Dean and Sanjay Ghemawat are good examples; they didn't manage people, but they did work on very hard technologies like GFS, MapReduce, and BigTable that were used by the whole company, and later inspired projects like Hadoop. (In general, I think having a dual career ladder—one for ICs, and one for managers—is a good idea, and the "Fellow" model really just recognizes the fact that the best engineers are worth as much or more than the best managers.)

The second model is essentially skunkworks: leading projects which are high-risk and important to Stripe's future, but far enough outside the main product that you want to treat it almost as a small startup. The first attempt at this were Googlettes, led by Georges Harik, which included projects like GMail, Google Talk, Orkut, and Google Mobile. At the time, those were very distant from search, but as they grew the successful projects became core to the company. The second version is Google X, where they're now expanding into very distant areas that involve hardware, biosensors, self-driving cars, etc. For Stripe, maybe the equivalent is something like cryptocurrencies, or physical payments, or something you've imagined by I haven't. :)

Anyway, thanks for writing. I have a lot of admiration for Stripe's culture and so I hope you all keep blogging about it.

5 comments

I've heard 'seagull management' or something similar too. They fly in, shit all over everything, and leave.

The term was popularized most recently by Mark Suster:

http://www.bothsidesofthetable.com/2009/10/25/choose-your-vc... --

One of the terms we coined there was a “seagull.” We used it to describe certain of our partners (e.g. the owners of Andersen Consulting). Seagulls were the partners who didn’t spend much actual time on your project. They were smart and accomplished. They knew enough about your project to have an opinion but not enough to help. They would swoop in for one day to “check in on things,” shit on you and then fly away. Seagulls.

The analogy holds pretty well for some VCs and this can be destructive.

My favorite term for it is "Eye of Sauron" management. Most of the time the eye is not on you ... but when it is, look out!

you missed step 2 after fly in:

2) loudly squawk

Hah, true!

To take the analogy further, sometimes you need to throw some breadcrumbs to keep the seagulls busy.

Hit-and-run management too.

I think it's hard to make "chief architect" work out in the long term

I think it can work fine as long as the chief architect is acting as an architect. Problems arise when a chief architect tries to make engineering decisions about individual components. When you're dealing with a large project, having someone who knows what all the components are and how they interface with each other can be absolutely vital; but that person should be treating each component as a black box -- not just being uninvolved with the implementations, but being actively unaware of the implementations of the components, in order to ensure that he doesn't make the mistake of assuming that a particular implementation detail will remain available in the future.

Its a shame that Craig Silverstein does not get metioned as often. I will leave it to people better than me to elaborate on that.

Losing touch with actual dev problems is one of the occupational hazards of architects. I think the way to make "chief architect" work is that the chief architect does at least some development him/herself. The architect could for example build the prototype of a new system, perhaps with a small team of assistants.

"Bungee Boss", now over 20 years old:

http://dilbert.com/strips/comic/1994-09-07/