Comment by nojvek | Hacker News Reader

Comment by nojvek | Hacker News Reader

I’ve worked at many startups and a high level principle i’ve found useful is “introduce process when not doing it hurts more”

- you could just work on flat files and sync with Dropbox. But losing history and context hurts. Introduce version control.

- hurts more to host your own git than just paying GitHub/GitLab. Do that.

- Small prototype for startup. Don’t need tests. That’s cool. Ship to production directly. Now you have customers and shit is regressing and pissing customers off. Introduce CI so every merge with master has some level of quality.

- Now you have multiple team members all committing code at various levels of quality. Make sure they reviewed by people who have code context and know what good code is. Pull requests and reviews for merges.

- people don’t know what to do. What is highest priority? what is the scope? what are the unknowns? how long will things take? Introduce something like trello or any other task management system. Work against goals broken down into tickets and plan in small increments.

- shit goes on fire occasionally. Have an oncall rotation. Monitor metrics and alert if something needs investigating.

This is definitely a good approach, totally agree with it.

It is bad to introduce too much process too early, and a good measure of when you need it is when the pain of not having it exceeds the pain of the process. I really dislike unnecessary process, but as you grow different processes become necessary and they make life easier and more predictable.

It isn't rare to have the wild west at a startup in the early days and it isn't rare to lose a few people when you start putting in necessary processes because they don't want the constraints. One of the most valuable lessons I have learned over the years is that it is healthy when people leave that aren't on the same growth path or maturity of the organization. Don't fight to keep people when this is the case, it just adds stress to the organization and people internally know that the person isn't a good fit anymore. So let them go. Hard thing to do sometimes, but necessary as companies grow and mature.

> it is healthy when people leave that aren't on the same growth path or maturity of the organization

Yes. That's real!

Yes, and it works in both directions of the relationship.

Completely agree, both the company and individual win here, no one wants to be unhappy doing their work. And no one wants to work with the person that is always complaining about how the company has changed.

Superb set of points; thanks.

Current state: 1. version control [done; branching strategy and flow to be honed] 2. self-hosted gitlab [least of our worries, hasn't hurt to run, so will continue self-hosted] 3. regression has become a serious problem [will push for CI] 4. code/design/architecture/bugfix reviews [will make it more formalized] 5. better prioritization and reduced randomization [will push more for this] 6. on-call roster [will work on formalizing it]

Again, thanks for great pointers.

Reply on news.ycombinator.com