12 ms·
> It seems like a lot of people here have been in an ineffective large organisation and an effective startup. I was at an effective startup that turned into an
by PragmaticPulp 5y ago
> It seems like a lot of people here have been in an ineffective large organisation and an effective startup.
I was at an effective startup that turned into an ineffective large organization before my own eyes. Your three (excellent) points ring very true.
However, the company actually tried to implement each of your three points and recognized their importance. The problem was in the execution.
Old products: These were neither retired nor given appropriate resources, so they instead decayed over time. Empty promises about longevity were made and then broken. Attempts were made to outsource maintenance to countries with the cheapest engineers, which backfired when each update become more buggy than the last. The end result was a lot of customers and early adopters getting burned and a destruction of our reputation in the industry.
Shared infrastructure: The C-levels saw shared infrastructure as an opportunity to reduce costs and speed up development, but they took it too far. At the worst, they wanted to have one gigantic team of back-end engineers, one gigantic team of front-end engineers, and so on, spread across every project across the entire company. Individual engineers were assigned to many projects and each had to deal with multiple managers fighting for their time. End result was that nothing got done and politics reigned supreme as the way to get attention on your project.
Best practices: The company hired “subject matter experts” to enforce best practices. They were expected to be involved in everything across the company. Imagine being hired as the “security best practices owner” and then told that you’re accountable for the security of everything at the whole company. Instead of promoting best practices, they went into full defensive mode and interfered with the shipment of every product and feature that they didn’t have time to work on. We would have products ready to ship and have the best practices experts panicking to halt it because they wouldn’t have time to look at it for months after completion. Getting them involved at the start was a pipe dream.
The overarching issue was that they tried to do big company practices in the move fast and break things startup style. For every well-intentioned move toward being a proper company they managed to screw it up by trying to inject startup-style speed and improvisation.
- ido 5y agoThe overarching issue was that they tried to do big company practices in the move fast and break things startup style. For every well-intentioned move toward being a proper company they managed to screw it up by trying to inject startup-style speed and improvisation. What would have been a better way of handling the transition?
- PragmaticPulp 5y ago> What would have been a better way of handling the transition? The problems all came from the top-down direction. Replacing the CEO with an experienced big company leader could have solved so many issues. The CEO was good at founding startups and running small teams, but that’s all he really wanted to do. He was trying to run a big company like a small startup and actively fought big-company organization styles. Companies like Microsoft, Facebook, and Google don’t try to pretend they’re still startups. They embrace the fact that they’re a big company and they make it work. They’re not perfect, but it’s better than a slowly failing big company that can’t accept that change is necessary.
- Accujack 5y ago>it’s better than a slowly failing big company that can’t accept that change is necessary. Or worse, a big company that is in a growth/high profit area that takes in enough money to not fail despite dozens of missteps. If you do the wrong thing long enough and don't go out of business, then the wrong thing becomes "our way".
- charles_f 5y ago> I was at an effective startup that turned into an ineffective large organization before my own eyes Somewhat related, I've been in effective teams that turned into organizations, a couple of times. One of the main issues I've seen is that they're especially prone to survivorship bias, on both accounts of process and people. You get the usual "this is how we managed to get there, it must have been right, let's do more of it", and people get protective or suspicious if you propose anything else. There's also a tendency of over-attributing success to the people who happened to be here while the team/product became successful. They tend to be promoted to responsibilities, their voice is over-amplified and their opinion becomes dogma. The result is that rather than adapting to the turning point both organizationally and architecturally, you end up with dungeon keepers protecting their babies under the cover of "this is our culture". The growth is not painful and rather than re-thinking things from the ground up, we correct by patches and ad-hoc fixes - approvals, reviews, build queues, more planning, backlog sign-offs and such.
- dcow 5y ago> There's also a tendency of over-attributing success to the people who happened to be here while the team/product became successful. They tend to be promoted to responsibilities, their voice is over-amplified and their opinion becomes dogma. How do you fix this? Assume all success is pure luck and ban dogmatic things like style guides and code reviews and force entire rewrites of sowftware and infrastructure every few years so that best practices change and don't become dogmatic? One of the allures to getting in early somewhere is that you get to build the foundation and become the thought leader and define to an extent which dogmas shall be adhered to because you have the context to make those decisions. I'm sure it can get overbearing when abused, but I also think it's quite presumptuous to join a mid-stage startup thinking you're going to come in and uproot everything and make things happen your way. If that's what you want go make the sacrifice and join a small place and earn it. And grow the business with it. And then incorporate it into what you can bring to the table as an experienced industry professional so you can be hired as a director somewhere else when you're ready to move and do it at larger scale. IDK...
- ctdonath 5y agoI’ve concluded that anyone using the term “best practices” in earnest doesn’t understand them.
- Spooky23 5y agoThere’s a lot of anti-patterns. Big orgs tend to reward careerism and punish risk. The biggest reason for that is that as you grow, the consequences of failure exponentially increase. Startup pivots are failures made good. Big org failures means people get fired or arrested.
- hinkley 5y ago> Individual engineers were assigned to many projects and each had to deal with multiple managers fighting for their time. The misunderstanding I saw across several organizations of different sizes was the mistaken rationale that surely, I should be able to take up "just" 25% of your time. When there are 5 other groups, there is nothing at all sure about that statement. Either you are lucky to get 10% or you're riding that employee into burnout and don't understand how they just up and quit one day.
- hnick 5y ago> Old products: These were neither retired nor given appropriate resources, so they instead decayed over time. This is the biggest one where I work. Call it technical debt, legacy systems, or aborted migrations - we have multiple generations of products doing the same thing. Management comes in bright eyed with a desire to migrate to the new system. Not too bad at first, we get some quick wins. Then the 80/20 rule hits, people realise how hard the rest will be and we decide to put it on hold temporarily (i.e. forever). This is the worst of both worlds, as we now only have the most complicated and ugly applications using the old system. There is nothing easy to train new people on. Over time fewer and fewer people truly understand the old system, work gets slower, and more error prone. But hey, there's another new system coming along - maybe we can move to that, along with all the fresh easy work we setup in the last few years. Cue xkcd comic about a solution making more problems. The other side of this is policy and procedure cruft: having so many different systems makes mistakes more likely. Every mistake means an investigation and an item added to a multi-page policy document. You'd never get everything done if you fully adhered to it, but it makes people feel safe.
- a9h74j 5y agoSounds like they switched to Matrix management. There must be some studies of when this switch is most effect, and to what degree.