Live data from Hacker News

Ask HN: Startup acquired by a large company and it sucks. What to do?

news.ycombinator.com

311–320 of 464 posts

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#311
post #258

Earlier quoted context omitted.

There is a large gradient between 'fucking around in production' and crippling big corporate process. Maybe the big tech companies all have the perfect amount of process, but much of the process and ceremony at other big companies I've seen is simply in place to keep the lowest common developer employed. Heck, people complain about excessive process on this very site all the time. On other nitpick is that startups li…

Try to think about the other side of this. Do you want to be standing in line at the grocery store and have your debit card just not work at all because Visa aquired this dudes startup and he didn't understand that feature X wasn't implemented because it would swamp the 10 megabit VPN link between Visa and your credit union? It isn't about keeping the lowest common developer employed, it is about keeping the lowest c…

Instead of sending the credit card ID number across the phone line, we will take a picture of the credit card for extra security, and send a full RAW PNG each time.

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#312

Earlier quoted context omitted.

> Take this as a learning experience: don't assume that you are at a startup where people will drop everything to handle a request from you right away. This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I've been in the same situation multiple times. Sometimes I've been allowed to do the work and sometimes not. In the cases where I was allowed to do the work, I certainly took longer…

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I know of at least two teams who would kindly ask me to refrain from doing this; me doing the work doesn't mean they don't have to do any. They still have to take the time to review my code, provide feedback, possibly explain to me their standards and conventions. Afterward, they have to maintain and own my changes - what if I intr…

Heaven forbid someone introduce a popular feature into an internal tool. I do know the concern here, but it seems to miss the forest for the leaves on the trees.

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#313
post #169

Earlier quoted context omitted.

> This doesn't explain why they wouldn't accept the offer of work from /u/lopkeny12ko. I know of at least two teams who would kindly ask me to refrain from doing this; me doing the work doesn't mean they don't have to do any. They still have to take the time to review my code, provide feedback, possibly explain to me their standards and conventions. Afterward, they have to maintain and own my changes - what if I intr…

Setting up teams for inner source work can be done and tends to earn itself back, but most teams aren’t set up for this. Typical solutions for the issues you mention: trusted committers to review and merge work without having that role burden the whole team, contribution guidelines to set standards, 30 day warranty to avoid getting code dumped in their lap that’s broken but also avoid having too many owners of parts…

Interesting and I’d love to hear more about this “30-day warranty” concept. How’s that work in practice and how do you use it to avoid having too many owners? (Does it revert to the original system owners after 30 days?)

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#314

Tell me you never ran a large code base in production, without telling me. Past a certain point there are no "simple code changes" anymore. Automation and functional QA needs to ensure zero regressions, internal and external docs need to be considered, it all needs to be bundled in with many other code changes (feature and fixes), etc. There is no shortcut. Even FB had to dial back their "break shit in prod" mantra.…

You're presenting one way of running, "a large code base in production" as if it's the only way. It's not. The other way is to deploy frequently, accept some amount of bugginess, and build your systems to deal with it appropriately. Running and maintaining a large code base is not the huge technical challenge it once was, but unfortunately the relics of the past remain, and force everyone to do things their way, lest…

The code bases we have today are vastly larger than at any point in history and grow larger every day. The past is not so black and white.

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#315
post #308

Earlier quoted context omitted.

Exactly. When you're a $1T+ company, nothing "just takes two weeks" to implement. What if your tiny change has an unforeseen side effect that takes down a critical auth system resulting in a revenue loss of $10M/minute. Are you going to take responsibility? What are you going to write in that postmortem? What if your change infringes on someone's patent or causes some other regulatory compliance related issue and the…

> it needs to get reviewed by legal so it doesn't expose us to legal liability I'd like to understand this. How does a legal team do a code review that ensures a code change doesn't expose the company to legal liability?

Usually it is more like "legal needs to be notified anytime third party dependencies are updated with a list of the licenses to make sure we aren't accidentally using GPL or proprietary code".

Other times legal gets involved earlier at the planning stages in case a feature or product falls under HIPAA or similar regulatory framework.

Actual code itself doesn't cross legal's desk anywhere that I know of.

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#316

I understand your frustration because I work in a large company and stuff can take forever. And this is the case for 99.9% of large companies. However one thing you should consider is this: there are probably 50 other people like you demanding to just have feature xy implemented. They are all totally simple etc.. until you have seen a large enterprise code base with lots of legacy cruft. Test suites that take hours t…

Quoted post unavailable.

> accept it takes >1 month to get something done

> Is this how military's organize themselves

The world's largest superpower just ended a 20 year engagement, so...

US basic training was also the origin of the phrase "hurry up and wait."

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#317
post #130

First off, how badly does the parent company need you to be on their VMs? It's probably necessary work, but not important. Everyone will still have jobs if it doesn't finish for a couple quarters. In the meantime, let your boss know you're blocked, start tracking this as a dependency, and go work on something else. In my experience, it helps a lot to imagine the motivations behind each process in an uncynical light.…

> It's probably necessary work, but not important.

I like the direction you're going with this but note that a task being necessary also implies that it is important - otherwise it would be optional!

The only success I've ever had (but at a small co) with getting others to work out what is important and what isn't is by forcing the requester/decision maker to prioritize goals against each other. It gives the opportunity cost a more personal, and therefore real, taste.

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#318
post #305
post #295

Earlier quoted context omitted.

Wait...are you suggesting that whole comment is actually just an ad ?

While I have no evidence in this particular case, if I wanted to promote a book, I could imagine making up a related, positive story, which just happens to mention the book positively, and posting it on a popular social media site (I put the book in my cart). Then one could follow up with a softball opposing story on another site to get some controversy and thus visibility. Probably someone will cross link for you (I…

I mean I read it and thought about looking up the book and getting it

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#319

> ahem: you told us to migrate to your platform _Someone_ at $LARGE_CORPORATION told you to migrate, but clearly this team didn't. They have no idea who you are, what you're working on, what your timelines are, what the priority of this work is relative to other things happening at the company, or whether there's other things you can be doing in the meantime. Yet they actually did some diligence, got it approved (aft…

I think I give about the same advice, so I put this here

When life gives you Bozos, enjoy the circus while you're there.

Get the most out of it.

This may very well be your best opportunity to deeply determine exactly what this sluggish bureaucracy needs to overcome this type of weakness and result in improved performance by an excellent margin, or maybe a multiple.

Even if you don't get to deploy many of your ideas under the current situation, it's always good to know how to turn bigger companies around.

In case you do get into a position where that may be expected of you someday.

Develop the qualities that are most needed by this size org and if there is very little uptake then you just keep becoming more valuable to another outfit and more able to avoid places where they actually don't get as much done as they should.

Re: Ask HN: Startup acquired by a large company and it sucks. What to do?

#320
post #308

Earlier quoted context omitted.

Exactly. When you're a $1T+ company, nothing "just takes two weeks" to implement. What if your tiny change has an unforeseen side effect that takes down a critical auth system resulting in a revenue loss of $10M/minute. Are you going to take responsibility? What are you going to write in that postmortem? What if your change infringes on someone's patent or causes some other regulatory compliance related issue and the…

> it needs to get reviewed by legal so it doesn't expose us to legal liability I'd like to understand this. How does a legal team do a code review that ensures a code change doesn't expose the company to legal liability?

The setup I saw is: there is an IP plan that documents whatever 3rd part IP you are using in your product (open-source or not). Someone has to sign-off on that plan, and sometimes developers do self-attestation that they have not deviated from it. Additionally, the binaries are scanned for certain things to avoid escapes of pre-release information, etc.
Post reply on HN