Pacing: the most important skill in startup engineering leadership | Hacker News Reader

Pacing: the most important skill in startup engineering leadership

danielmangum.com

61 pointshasheddan19 comments

> As an avid endurance runner, I am very familiar with the importance of good pacing, and the perils of doing it poorly. If you go out too hard in a race, you are destined to crash and burn. On the other hand, if you start too slow, you may have too much time to make up before the end of the race. At every moment throughout a run, you need to be in-tune with your body, understanding the limits of how hard you can push given your current position in the race.

I know it's not a popular opinion, but I hate sport metaphors for business. They make no sense even with tiniest scrutiny.

Isn't endurance running as mean of transportation completely disrupted by bicycle, cars, or public transportation? Wouldn't endurance running even with perfect pace actually kill you if you don't stop?

Once upon a time, while hiking, an elderly fellow shared his three rules for multi-day hikes:

- look backwards from time to time (so you'll know from where you came in case it's necessary to backtrack)

- know where you think you should be after X hours hike, and compare your actual surroundings to ensure they match sufficiently with the deduced location

- if you do get lost, never leave your drainage (when things are going poorly, don't make them worse)

We later learned he was a program manager for the https://en.wikipedia.org/wiki/Rockwell_X-30 , and not only did we use all three rules literally when got lost about half a week later, I've used them metaphorically on all manner of software projects since.

Could you elaborate? I'm not sure what it means to apply these to software development (at least, 1 and 3).

Also, what does drainage mean in this context?

Retrospection, orientation, and I'll re-phrase the last one as "maybe stop digging that hole before it's so deep you can't climb out." (I'm guessing on that last one, not heard drainage used that way either.)

Retrospection: Periodically examine what you've made and how, identifying the good, the bad, and the ugly. Try to structure your future work to produce more of the good and less of the bad and ugly.

Orientation: Periodically check to see if you're making what you meant to make, is what the customer wanted you to make, and is still what the customer wants you to make.

"Stop digging": Ok, you have a bit of code that's almost right, but it fails some tests. Add an extra conditional here, copy/paste a function there, change a constant in the copied code, voila problem solved. Oh, failing another test, let's repeat, and repeat. In the end you have 10x (or more) the necessary code and anyone looking at it would, rightfully, mock you for copying a 10 line function multiple times to make "render_with_black_background", "render_with_blue_background", "render_with_green_background", etc. when you, maybe, could have made it a parameter (with a default value) instead. It's related to the previous two in the sense that if you're actually retrospecting and periodically orienting, you probably won't dig the hole too deep.

1/ "look backwards" - for hiking, literally do so, so it'll look familiar going the other way. For software, remember when and where you've made arbitrary decisions, so you can revisit them and try a different branch when current development isn't working.

3/ "never leave your drainage" - a river-system drainage. for hiking, go downstream when lost: this will narrow the area you might be in, and tends to take you towards civilisation rather than away from it. for software, more metaphorical: debug by figuring out what's working as expected and ruling it out, thereby narrowing the area the bug might be in; the equivalent of leaving a drainage —hiking across a pass into new drainage— would be "fixing" an issue based on what you think the problem is, rather than what you know the problem is, only to wind up with a system that still doesn't work, and now not having any idea if odd behaviour comes from the original problem or from the "fix".

> if you do get lost, never leave your drainage (when things are going poorly, don't make them worse)

I read drainage as a water source and it might still work. In general rivers or any type of running water will have a higher chance of leading to another human being vs not with no other context.

You could relate that to software development by emulating running water in the sense that progress is being made if you're moving in a direction that's not fighting the current or stagnating. This could be taken in a number of different ways such as working on things that naturally let you make progress instead of fighting against it or getting lost and going in circles.

In the mountains a drainage gives you a set of guard rails and a set of bounds on a topographical map. Sometimes walking a half a mile in a direction gives you perspective on a peak or another feature that you can identify on the map based on the shape and then you can shoot bearings and locate yourself. Also if you follow water downhill you'll reach successively larger bodies of running or pooled water until you reach the sea.

I've been on a hike or two with my wife where knowing where the running water is versus where it should be saved us several hours of being lost.

What is drainage in this context?

watershed

A metaphor aims to illustrate a specific point better. It does not aim to be a full equivalent of the thing itself. This does not only apply to sports metaphors.

Sports metaphors are common because the are usually easy to grasp.

And I think in this specific case it makes a ton of things to not pick any metaphor, but an endurance run as opposed to … a sprint, which is currently THE most common (albeit only implicitly used)sports metaphor in the software engineering industry.

*sense, not things.

What do you mean by disrupted here? And don't you have to stop riding a bicycle or driving a car eventually too?

Endurance racing, which is what they're actually talking about as they care about "making time", is a sport that also appears almost identically in cycling and driving. And in all those contexts it's just an elective hobby that helps paint a picture about pacing, goals, and burnout. It's not about transportation at all.

But as far as running goes for transportation, it's 500,000 year old technique that ultimately requires no manufacturing or contraptions and runs on foraged berries. Other options may creep into use for a millenia or two, but it's not going anywhere.

Any metaphor can have holes poked in it. Same as all narrative are reductive and leave out innumerable salient facts. The map is not the territory. It doesn't mean analogies aren't useful.

As a cross-country mountain biker and long-time software engineer, there is a hell of a lot of analogues between mental and physical endurance even if the activities are completely different.

> Push too hard and you are likely to see degraded product quality, and eventually employee attrition. Don’t push hard enough and you’ll run out of money before you can acquire enough customers or raise your next round of funding. Either extreme can be fatal.

Ehhh. I would go so far as to say, pacing in general is not something management really has any control over. I don't recall ever in my career that a manager "pushed" a team to appreciably increase their real productivity.

Your best bet is to just get in tune with your team's pace, then plan based on that. Good managers don't "push", they prioritize.

Great way to look at it.

Overall excellent point about pacing. But I have to point out an issue:

"Missing a goal is not necessarily signal that your pace is too slow. In fact, it often means that you simply didn’t plan well for a more difficult portion of the race."

He did try to stretch the metaphor by mentioning inclement weather, but overall, software engineering is not similar to running a race.

For some features, you literally do not know what could be around the corner. It could be a huge crevasse. There is no known accurate map of the area. Your plans are more like wishes you make in front of a well before you throw a coin in.

If you had a good map then you wouldn't necessarily be doing software development. It would be more like just configuration and deployment.

That is why I would like to add that if you run into what seems like a roadblock, don't blame the staff. They didn't put it there. Give them time to figure out how to dismantle it or go around.

> The key to finding the right balance is honesty, transparency, and constant measurement.

The first two are payed only lip service in all but the most exceptional startups. My last one there was so little honesty and transparency despite the outward appearance of such being polished to seem as if it was.

I think the problem is the boards, especially when you have an engineer heavy founder set, those savvy investor types run circles around the C-suite. I literally had my CTO tell me when complaining about some big partners "there is a power imbalance and they know it" as an excuse to not even try to stop their bad behavior!

Add in sleazy lawyers and it's a recipe for culture disaster.

Just want to point out how nice it is to read justified text. It absolutely makes a huge difference.

Unless you're dyslexic, then you might not be reading it at all.

Reply on news.ycombinator.com