3 ms·
IMO, startups rarely have a process issue. They have a management issue. Process is bureaucracy. It adds no value but it helps to minimize the harms of over hir
by jongjong 2y ago
IMO, startups rarely have a process issue. They have a management issue. Process is bureaucracy. It adds no value but it helps to minimize the harms of over hiring which is something all big companies do in their quest for job creation.
- dijksterhuis 2y agoI dunno. In my experience, it depends. Like, $PREVIOUS_COMPANY was a small shop. Not many customers, not many users. Handful of customer product deployments. Even so, releases/deploys were broken most of the time. First thing I did after I got responsibility was add dev/staging with an automated and clearly documented release process from PR -> Prod, including steps for QA etc. Nothing stupidly onerous. Customers complaints stopped almost overnight. People internally knew what to expect when it came to changes being released. People could see when things were released and where etc. People knew why their work might not be propagated out yet. Higher ups knew why things might take longer and why that was beneficial. We could also break down some very simple stats about how deployments/releases were going based on git tags. Applying the limitations of a process can be useful when things have been going wrong, repeatedly, in exactly the same way. However… there were absolutely cases where adding a process didn’t make sense and would have just been adding a process for adding a process sake. For example, ee didn’t need tickets for every PR. If it was a ten minute fix just do it and explain it in the PR, that’s good enough.