recruit for simplicity
avoiding complexity starts with the organization you build
In an excellent blog post, Yammer’s VP of Engineering Kris Gale discussed the cost of complexity. His quotes are call-outs throughout.
When I interview prospective PM candidates, I ask basic questions about tests I’ve run before or seen run on other sites/apps. I’ll even give candidates resource constraints and a time limit.
The best answers are usually absurdly simple, sometimes just copy changes. The very best would be for you to challenge me that that thing is actually valuable and try to figure out how to kill it. The candidate can have my job if they manage to kill one of our features.
But that’s not what most people do.
Most people overbuild, it’s human nature. I’ll talk them through that and see if they can be taught. The unforgivable sin for me, however, is casually tossing out that he or she would use “an algorithm”.
Complexity cost is the debt you accrue by complicating features or technology in order to solve problems.
Seems crazy, right?
Software’s just a bunch of algorithms after all. PMs just strap on their Steve Jobs turtlenecks and Engineers go hack away in the algorithm caves, mining UX gold, right?
Engineers will probably look at this from the other direction. Of course there’re algorithms to do what the PM wants. Machine learning, huge data, natural language hooha, those are all things. We hire smart people who can build smart things.
the initial time spent implementing a feature is one of the least interesting data points to consider when weighing the cost and benefit of a feature.
Here’s where I’m coming from:
Magical algorithms are not a product, they are attempted optimizations of an aspect of a user’s experience. Even assuming everything works perfectly, there’s a lot more that goes into a successful UX than the output of a big calculation.
1.0 of a “clever” solution is inevitably a failure. One of these systems is inherently large and tricky to instrument. When it fails, will the PM know why? Is any PM or Engineer prescient enough to build in the right levers into an algorithm before they ship it? You’d be amazed how much better rand() is than nothing.
It’s just lazy. Dump the difficulty of building good product onto Engineering? Sorry, no, that’s not the gig. If and when you do decide to get clever, this is an open discussion with Engineering about the complexity cost and benefits of the feature in question.
Given the same result, the simpler code is more valuable to your organization.
The offense may not be fatal if I’m interviewing an engineer for a PM job. Maybe they’ve done this kind of work before and don’t understand our obsession with starting simply or that they don’t get to prescribe technical solutions anymore.
MBAs are out of luck.
