Choose Boring Technology
March 30th, 2015

Probably the single best thing to happen to me in my career was having had Kellan placed in charge of me. I stuck around long enough to see Kellan's technical decisionmaking start to bear fruit. I learned a great deal from this, but I also learned a great deal as a result of this. I would not have been free to become the engineer that wrote Data Driven Products Now! if Kellan had not been there to so thoroughly stick the landing on technology choices.

Being inspirational as always.

In the year since leaving Etsy, I've resurrected my ability to care about technology. And my thoughts have crystallized to the point where I can write them down coherently. What follows is a distillation of the Kellan gestalt, which will hopefully serve to horrify him only slightly.

Embrace Boredom.

Let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps.

If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that's existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you're in trouble.

Any of those choices might be sensible if you're a javascript consultancy, or a database company. But you're probably not. You're probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail. Or at best, delay success [1].

What counts as boring? That's a little tricky. "Boring" should not be conflated with "bad." There is technology out there that is both boring and bad [2]. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood. Anyone who knows me well will understand that it's only with a overwhelming sense of malaise that I now invoke the spectre of Don Rumsfeld, but I must.

To be clear, fuck this guy.

When choosing technology, you have both known unknowns and unknown unknowns [3].

  • A known unknown is something like: we don't know what happens when this database hits 100% CPU.
  • An unknown unknown is something like: geez it didn't even occur to us that writing stats would cause GC pauses.

Both sets are typically non-empty, even for tech that's existed for decades. But for shiny new technology the magnitude of unknown unknowns is significantly larger, and this is important.

Optimize Globally.

I unapologetically think a bias in favor of boring technology is a good thing, but it's not the only factor that needs to be considered. Technology choices don't happen in isolation. They have a scope that touches your entire team, organization, and the system that emerges from the sum total of your choices.

Adding technology to your company comes with a cost. As an abstract statement this is obvious: if we're already using Ruby, adding Python to the mix doesn't feel sensible because the resulting complexity would outweigh Python's marginal utility. But somehow when we're talking about Python and Scala or MySQL and Redis people lose their minds, discard all constraints, and start raving about using the best tool for the job.

Your function in a nutshell is to map business problems onto a solution space that involves choices of software. If the choices of software were truly without baggage, you could indeed pick a whole mess of locally-the-best tools for your assortment of problems.

Crazy Created with Sketch. Problems Technical Solutions
The way you might choose technology in a world where choices are cheap: "pick the right tool for the job."

But of course, the baggage exists. We call the baggage "operations" and to a lesser extent "cognitive overhead." You have to monitor the thing. You have to figure out unit tests. You need to know the first thing about it to hack on it. You need an init script. I could go on for days here, and all of this adds up fast.

Sane Created with Sketch. Problems Technical Solutions
The way you choose technology in the world where operations are a serious concern (i.e., "reality").

The problem with "best tool for the job" thinking is that it takes a myopic view of the words "best" and "job." Your job is keeping the company in business, god damn it. And the "best" tool is the one that occupies the "least worst" position for as many of your problems as possible.

It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it. Mature and productive developers understand this.

Choose New Technology, Sometimes.

Taking this reasoning to its reductio ad absurdum would mean picking Java, and then trying to implement a website without using anything else at all. And that would be crazy. You need some means to add things to your toolbox.

An important first step is to acknowledge that this is a process, and a conversation. New tech eventually has company-wide effects, so adding tech is a decision that requires company-wide visibility. Your organizational specifics may force the conversation, or they may facilitate developers adding new databases and queues without talking to anyone. One way or another you have to set cultural expectations that this is something we all talk about.

One of the most worthwhile exercises I recommend here is to consider how you would solve your immediate problem without adding anything new. First, posing this question should detect the situation where the "problem" is that someone really wants to use the technology. If that is the case, you should immediately abort.

I just watched a webinar about this graph database, we should try it out.

It can be amazing how far a small set of technology choices can go. The answer to this question in practice is almost never "we can't do it," it's usually just somewhere on the spectrum of "well, we could do it, but it would be too hard" [4]. If you think you can't accomplish your goals with what you've got now, you are probably just not thinking creatively enough.

It's helpful to write down exactly what it is about the current stack that makes solving the problem prohibitively expensive and difficult. This is related to the previous exercise, but it's subtly different.

New technology choices might be purely additive (for example: "we don't have caching yet, so let's add memcached"). But they might also overlap or replace things you are already using. If that's the case, you should set clear expectations about migrating old functionality to the new system. The policy should typically be "we're committed to migrating," with a proposed timeline. The intention of this step is to keep wreckage at manageable levels, and to avoid proliferating locally-optimal solutions.

This process is not daunting, and it's not much of a hassle. It's a handful of questions to fill out as homework, followed by a meeting to talk about it. I think that if a new technology (or a new service to be created on your infrastructure) can pass through this gauntlet unscathed, adding it is fine.

Just Ship.

Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.

Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.


  1. Etsy in its early years suffered from this pretty badly. We hired a bunch of Python programmers and decided that we needed to find something for them to do in Python, and the only thing that came to mind was creating a pointless middle layer that required years of effort to amputate. Meanwhile, the 90th percentile search latency was about two minutes. Etsy didn't fail, but it went several years without shipping anything at all. So it took longer to succeed than it needed to.
  2. We often casually refer to the boring/bad intersection of doom as "enterprise software," but that terminology may be imprecise.
  3. In saying this Rumsfeld was either intentionally or unintentionally alluding to the Socratic Paradox. Socrates was by all accounts a thoughtful individual in a number of ways that Rumsfeld is not.
  4. A good example of this from my experience is Etsy's activity feeds. When we built this feature, we were working pretty hard to consolidate most of Etsy onto PHP, MySQL, Memcached, and Gearman (a PHP job server). It was much more complicated to implement the feature on that stack than it might have been with something like Redis (or maybe not). But it is absolutely possible to build activity feeds on that stack.

    An amazing thing happened with that project: our attention turned elsewhere for several years. During that time, activity feeds scaled up 20x while nobody was watching it at all. We made no changes whatsoever specifically targeted at activity feeds, but everything worked out fine as usage exploded because we were using a shared platform. This is the long-term benefit of restraint in technology choices in a nutshell.

    This isn't an absolutist position--while activity feeds stored in memcached was judged to be practical, implementing full text search with faceting in raw PHP wasn't. So Etsy used Solr.


Data Driven Products: Lean Startup 2014
January 27th, 2015

Here's a video of me doing a slightly-amended version of my Data Driven Products talk at the Lean Startup Conference back in December.

I am told I upspeak? You be the judge.


Thoughts on the Technical Track
December 9th, 2014

I saw lizTheDeveloper's post about technical leadership at Simple and I realized that I've been meaning to write about this for a while. I hope to persuade you that there are a number of systemic biases working against a healthy technical career path. I don't think that they're insurmountable, and I don't disagree with Liz's post. But I've never heard of a company clearing all of these hurdles at once.

I was the first person at Etsy with the title of "Principal Engineer," which was the technical equivalent to a directorship (i.e., one level below CTO). I'm not saying this to toot my own horn, but rather so that it's understood that the following comes from someone that was the beneficiary of an existing system.

(Incidentally, I think Etsy is an example of a company whose heart is in the right place, and it's not my intention to single them out.)

To Review, Management is a Job

My views on the merits of having a technical track align with those of many people in our industry. Management is a different job, with different skills. They're not necessarily more difficult skills, they're just different. By and large they're unrelated to the day-to-day labor of the people who build technology products.

It doesn't make any sense to divert your technical talent into a discipline where they will need to stop doing technical work. (That's in the event that they intend to be effective managers, which I concede might be an unrealistic expectation.)

Other people have made this case, so I'll just proceed as if we agree that there must be a way forward for people that are great programmers other than to simply graduate into not programming at all.

Having that way forward is an ideal. There is always a gap between our ideals and reality, and we cannot act as though we've solved a problem simply by articulating it.

Fundamental Asymmetries

Management Just Happens

I have had management responsibility thrust upon me at least four times over the course of my career, and at no point has that been my goal. It just happens. Do you want to be a manager? I will now tell you the secret to becoming a manager in a growing company: just wait.

You have a manager. Eventually, your manager will accrue too many responsibilities, and they will freak out. They will need somebody to take over some of their reports, and that lucky warm body is you.

Good hair: also helpful.

It is entirely plausible to become a manager accidentally. It might even be the norm.

Technical Track Promotions are Post-Hoc

The process for minting a new manager is: crap, we need another manager. There's no symmetrical forcing function pushing people into the upper ranks of technical leadership.

Mentorship and technical feedback are things everyone does on a functioning engineering team. A technical track "promotion" is merely additional recognition given to someone who is already performing that role notably well.

If the job is already getting done, then filling the job is clearly not a pressing need. Technical promotions are something that happen when it's convenient, which is generally never.

Stumping

Between the founding of the United States and the end of the 19th century, it was considered tacky for presidential candidates to personally campaign for the job. Instead, they staged an elaborate farce in which they reluctantly answered the call of the nation to serve. Trying to intentionally get a promotion into the technical track is pretty much just like this.

Getting promoted in the technical track is kind of like being James Garfield.

Your work must be recognized, and this is the rub. Let me rephrase: "someone with the power to bestow promotions has to be your fan." To be promoted you have to be a good mentor, but you also have to worry about playing to an audience. That may be executives, or it may be your peers (and potential competitors). Regardless, you're running a weird campaign in which actually saying anything directly about wanting the job would be gauche.

The most qualified individual contributors may become known without ever really doing this on purpose, but that doesn't say much for this as a tenable career goal of the sort that can be counted on.

The Problem of Credibility

Society Applies to Idealistic Tech Companies, Too

American society is not a classless oasis. That's a lie we tell ourselves. And the person who knows what everyone else gets paid and can fire you is not in your class.

A technical job does not have equivalent prestige to a management position with an equivalent salary just because you say it does. Even if you conquer this within your own company, it's not true in the rest of the industry, and it's not true in the world at large. In the world our parents live in, it's a big deal to be somebody else's boss.

You're hiring people from the world at large all the time. Without continuous effort a technical track decays to its ground state, where the jobs are second class.

Halfhearted Managers are The Worst

The natural result of a system in which technical promotions can't be counted on and are viewed as suspiciously-maybe-second-class anyway is that people who don't really give a shit about management wind up going into management. Given the choice of waiting for a technical promotion that may never arrive and taking an offer to manage others, almost everyone is going to take the bird in the hand.

Once you let the soulless suspendered lizard in the building, you are screwed.

Managers that have no passion for management are a blight on society. I can say this because I have been one of them. I was never a good manager, and for that I apologize to anyone that ever had to report to me.

I am not an isolated case. Many people in management are frankly terrible at it. And they would rather have technical track jobs anyway, but they have no idea how to make the switch. A credible technical track is a great way to ensure a higher level of satisfaction and competency among the managers.

Ratios Observed in the Wild Make No Sense

You don't need to take my reasoning about the intrinsic pressure favoring management bloat at face value. You can actually look at the ratio of managers to technical employees at your company.

At one point, I was alone at my level. There were five theoretically-equivalent directors at the time. The ratio was at least that bad on the lower rungs. (I have no idea if this is still true at that company, and it might not be.)

For that to make sense, we'd have to believe a few things that don't stand up to scrutiny. First, we'd have to believe in a very high proclivity among engineers to manage, and I think that betrays our expectations. Not very many of us got into this business with the hope of not actually building things.

Second, we'd have to believe that although it took five directors to effectively manage the organization, only one technical leader was required to advise the same group on the details of the work they do every day.

What Might Help?

Promotions Should Not Be Miraculous and Rare

Of course, it wouldn't make logical sense to say that the ratio of individual contributors to managers at a given level must be 1:1. I honestly don't know if 1:2 or 2:1 is closer to correct. The answer is probably contingent, and the relationship might not be linear.

But I think it's important for any company that takes the ideal of having a tenable technical track seriously to put a stake in the ground on this question. It's hard to build a credible technical track, and we need a baseline to grade ourselves against.

I don't think that proceeding with the assumption that leaders will just naturally emerge produces the best results. Adding a self-imposed quota achieves accountability. It acknowledges the possibility that problems can lie in the system of recognition, and not only in the talents of the people in the pool for promotions.

"Do we think that we hire smart people here? Yes? Then we should be able to find N of them worthy of promotion for every manager. If we can't then the problem is most likely to be found in how we're recognizing people for their work."

I know that the word "quota" is verboten for many, and I gleefully await your flames.

Address Prestige with Superpowers

If we think about why managers and technical employees on even salary footing may be perceived to not truly be equals, it comes down to superpowers. The managers have special capabilities that the technical employees don't: hiring, firing, compensation, and the like. Is it possible to give technical employees a different set of superpowers, to address the prestige problem?

Maybe. I don't think that I have seen this done correctly yet. If I had superpowers, they were:

  • The ability to work on whatever I wanted.
  • The ability to talk to anyone I wanted.

These were indeed powerful, but using them to create positive action was difficult. It would have been easy for me to opt out of projects that I didn't believe in and to do my own thing. I did often do my own thing. But I also worked on projects that I didn't believe in, because I knew that opting out was a selfish act. One of my friends would just be forced to work on it in my place, and sometimes leadership is about jumping on grenades.

I guess there are worse superpowers. For example, the ability to allow oneself to be framed for the good of the city.

Talking to other teams made it possible for me to point out places where resources weren't intelligently allocated. But this also begat mostly negative actions. "Hey, this isn't the best way to use these folks," I'd find myself saying all the time. It was draining, and a bummer.

Giving the technical leadership deeper involvement in the planning process could address this. Of course that would involve dragging the technical leadership to meetings, which I admit is tricky.

In Closing

I hope I've demonstrated that creating a career path outside of management for technical employees is only the beginning of your problems. It's a good and necessary step, but it's not an achievement by itself.

I'd love to hear from anyone with better ideas. These issues are difficult and I don't claim to have all of the right answers.


RSS | Atom | Copyright © 2004-2015 Dan McKinley. At no point has the writing here constituted the opinions of my employer(s).