14 comments

[ 2.7 ms ] story [ 48.5 ms ] thread
How was technical debt not one of the things mentioned? In my experience that’s by far the #1 reason for poor velocity.
Edited out for space, mostly :)

My target audience is founders of very early-stage startups, so I cut the section under the assumption that they probably won't have much technical debt yet.

Speaking as someone who has worked as a developer for multiple early-stage startups, the opposite is true.

Early-stage startups tend to have rampant technical debt for two reasons:

1) They need to get a product to market immediately and they need to iterate on it rapidly—so using technical debt as a tool to achieve short-term goals quickly is actually awesome.

2) Startups tend to pivot. Making fundamental domain changes to a product quickly tends to give you very weird systems, often with large unused portions.

I would include overburdening processes.
How does this guy make money only charging $1,000/week?
I'm a fractional CTO, so $1,000/wk is only a fraction of my overall earnings.
(comment deleted)
And they get slower as you add/change requirements.

Managers don't get that you waste time if you put a sewer canal in the street, close the street and pave it, then break it up again to put cables in.

(comment deleted)
> Schedule meetings at the beginning or end of the day, or near lunch.

Please don't unless you can make sure it won't make your devs miss lunch or leave late because it got extended.

I'd prefer to just schedule meetings ahead as a suggestion.

No mention of burnout?

If a developer becomes suddenly unproductive burnout is often the culprit.

Also, in my experience another culprit is: your developers are slow because you aren't willing to pay them market rates or show them respect so even though their conscious mind wants to work their butt off for you, they just can't do it because moral is so low.

5. Don't interrupt a developer unless the building is on fire

Yes, please don't !