6 ms·

Pacing: the most important skill in startup engineering leadership

61 points by hasheddan 3y ago

guender 3y ago
[dead]
arminiusreturns 3y ago
> 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.
dilippkumar 3y ago
Just want to point out how nice it is to read justified text. It absolutely makes a huge difference.
- kemiller2002 3y ago
  Unless you're dyslexic, then you might not be reading it at all.
hartator 3y ago
> 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?
- swatcoder 3y ago
  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.
- pflenker 3y ago
  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.
  - pflenker 3y ago
    *sense, not things.
- 082349872349872 3y ago
  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 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.
ilaksh 3y ago
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.
wavemode 3y ago
> 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.
- lulznews 3y ago
  Great way to look at it.

61 points by hasheddan 3y ago

[dead]

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

dilippkumar 3y ago

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

kemiller2002 3y ago
Unless you're dyslexic, then you might not be reading it at all.

hartator 3y ago

> 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?

swatcoder 3y ago
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.
pflenker 3y ago
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.
- pflenker 3y ago
  *sense, not things.
082349872349872 3y ago
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 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.

ilaksh 3y ago

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.

wavemode 3y ago

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

lulznews 3y ago
Great way to look at it.