4 ms·

Echoing others who have gone through the startup -> $LARGE_CORPORATION acquisition, and having been there myself: just leave. It won't get better. On the contr

Echoing others who have gone through the startup -> $LARGE_CORPORATION acquisition, and having been there myself: just leave. It won't get better. On the contrary, it'll get worse as those worth their salt see the writing on the wall and head for greener pastures. Before you know it, all the people you love working with will have moved on, you'll be the only one fighting for progress, and worst of all, the burden of responsibility will fall increasingly on your shoulders as one of the remaining few with domain knowledge. Consider it mission accomplished, startup acquired, check the box, journey over, on to the next one. The market for software developers is on fire right now. You'll have no problem finding a new startup to join, and you'll be instantly relieved.

channel_t 5y ago
This is probably the correct answer in most circumstances, unfortunately. It's just the circle of life. Acquisitions are rough and if you aren't being significantly incentivized to deal with all the extra BS that comes along with it, then it's time to move on.
Eiriksmal 5y ago
But while you're along for the ride (or trapped on the slowly sinking ship), it can be really helpful to see where the big company's policies and procedures are outright dysfunctions. Not everything they do is merely "this is how things are done in all large organizations." Then you can take a list of a few practices that result in ossification and a slow death to your next small startup. Maybe you won't take away a polished playbook on how an industry leader handles product development, but having firsthand experience on what breaks at "scale" is also useful. Some hypothetical examples: What happens when there are more than four engineering teams? What changes when dedicated scrum masters are introduced and begin arguing about whether work belongs in sprint 133 or sprint 134 while walking past your cubicle? How do enterprise contracts for PaaS providers work? And, at my current employer, what happens when more than 100 engineers' work is shelved for holiday "frosts" and "freezes?" Afterwards, you'll have more interesting conversations with the bright-eyed 23-year-olds working with you at The Next Startup. Instead of "I feel like this is a bad idea," or--heaven forbid--"Because I said so," you can confidently state "Company X tried Y. Z was the tragic result. How can we implement Y, but avoid Z?" It's one thing to have head knowledge of why frequent releases are beneficial, but watching what happens the moment a code freeze is lifted and hundreds of commits hit production? That's priceless.

channel_t 5y ago

This is probably the correct answer in most circumstances, unfortunately. It's just the circle of life. Acquisitions are rough and if you aren't being significantly incentivized to deal with all the extra BS that comes along with it, then it's time to move on.

Eiriksmal 5y ago

But while you're along for the ride (or trapped on the slowly sinking ship), it can be really helpful to see where the big company's policies and procedures are outright dysfunctions. Not everything they do is merely "this is how things are done in all large organizations." Then you can take a list of a few practices that result in ossification and a slow death to your next small startup. Maybe you won't take away a polished playbook on how an industry leader handles product development, but having firsthand experience on what breaks at "scale" is also useful. Some hypothetical examples: What happens when there are more than four engineering teams? What changes when dedicated scrum masters are introduced and begin arguing about whether work belongs in sprint 133 or sprint 134 while walking past your cubicle? How do enterprise contracts for PaaS providers work? And, at my current employer, what happens when more than 100 engineers' work is shelved for holiday "frosts" and "freezes?" Afterwards, you'll have more interesting conversations with the bright-eyed 23-year-olds working with you at The Next Startup. Instead of "I feel like this is a bad idea," or--heaven forbid--"Because I said so," you can confidently state "Company X tried Y. Z was the tragic result. How can we implement Y, but avoid Z?" It's one thing to have head knowledge of why frequent releases are beneficial, but watching what happens the moment a code freeze is lifted and hundreds of commits hit production? That's priceless.