Comment by dmix
6 years ago
I just cringed at the thought of some BigCo software company project management tracking obsessive approach being pigeonholed onto a startup. Or the various other ‘processes’ that built up continually over the years at BigCo to minimize any sort of risk at the expense of speed and flexibility.
The bigger benefit is working with really smart people. I think you’re over valuing the utility of a lot of the stuff that goes on at bigger firms, mostly out of necessity but also many times due to managers trying to justify their own existence in the company so they create ‘processes’. But also just merely the scale of the operation where highly automated fancy systems would be a complete waste of time for a startup with a small team and a short run way.
GP comment never said "processes," so I'm not sure why you're focusing on that. They said "best practices", which is totally different.
Sorry I just think I wanted to go on a rant at all the big software co "project managers" that got hired into startups I worked at and ruined everything.
That wasn't a proper response to OP's comment.
Yeah, I could have been more clear - the BigCo I'm at is still pretty light on process, and teams are free to use whatever project management approach they want. As seattle_spring conjectured, I was thinking more about technical best practices. I've learned many patterns from the software I work with now, and I've been able to grow from working with really smart engineers that have enough experience to be pragmatic without compromising on quality.
An (admittedly controversial) example is repos-per-service vs a monorepo: now that I've worked at a bigco with a monorepo, I would have used a monorepo at my previous company.
Personally having also worked at monorepoCo, I would only recommend it to another company with a good enough system to support it. I’ve heard of places trying to implement it with git sub folders and hellacious branching, to great lack of success