201–210 of 464 posts
One reason acquisitions fail is the differing planning cycles of the two companies. If a company that does annual planning buys a company that does things at a faster rate, then they often run the acquisition into the ground, as waiting a full year to shift directions can be far too long in many industries.
It's probably easier and quicker to change the app to work with their platform. If nothing else, it's going to be much easier to staff the project; your team knows the app.
> The first engineer I talk to doesn't even attempt to answer my question but redirects me to their manager. Ok, that's odd, I think, but whatever.
That's not an unusual response (https://devblogs.microsoft.com/oldnewthing/20070522-00/?p=26...).
> Manager says sure, just fill out this feature request doc. It's a Google Docs template with 4 (!) pages of required documentation to just explain why I want this feature implemented. It asks for my team name, the motivation, why I can't solve the problem some other way, yada yada...ok, I guess it's good to document your work, so sure. I fill it out and submit it.
This strongly suggests that ad hoc feature requests are or have been an issue for the team. It's also a good way to weed out requests that the requester isn't serious about or has an available alternative.
> No response after two days. Then I get an automated email that their skip level manager has approved the work. Huh? This is followed by an email that the team's eng manager approved the work. Why do two layers of management need to approve work on something they have no knowledge about?
These managers are running interference for their team so they can get work done.
> Finally, after many rounds of arguing about why this needs to be done in the first place (ahem: you told us to migrate to your platform, and it literally does not work for our app), they quote us a delivery timeline of end of Q1 in 2022.
Most development teams have a backlog; I'd be concerned about the work quality of one that didn't.
> At this point I am in absolute shock. This should take no more than a few days to implement.
The change might take a few days but the team already has a backlog of WIP (work in progress) (http://www.leanmanufacture.net/leanterms/wip.aspx). The time to completion is based on the other tasks in the queue. If the migration needs to happen sooner then that's between your manager and the manager of the other team.
> So I reach out to the manager and ask what is going on. This is a simple task, I said. Why does it take an entire quarter for your team to deliver? He doesn't have an answer.
Every task is simple when you aren't the one doing it.
This was a bad move tactically; calling him out is not going to get you the results you want.
> I tell him I'm happy to fix the issue myself, if they link me to the relevant codebase. "It shouldn't be too hard to dig in and submit a patch," I think to myself. He says he cannot give me access to the codebase for compliance reasons, and that only members of his team have R/W on that repo. What???
Maybe they don't want to support bespoke features for your app. You can check in the code and be done but they're stuck supporting the change forever.
What you should do, is realise you are no longer alone. You're not a small team at the fore-front anymore, you're part of a whole company of teams now and like it or not, these teams, whatever divisions they fall under and the company as a whole have deadlines and budgets. Someone looked at your request and plotted time. Does that not work? Find another solution. Don't complain about how its a small feature and you could fix it yourself easily, it isn't and you won't. Instead of arguing, being shocked and complaining about how insane it is, take a step back, talk to these people and try to understand how and why this company works the way it does. If after that it still doesn't work for you, you can always leave, but I'd honestly suggest you try to find a few people who can guide you around a bit instead of acting like the mistreated outsider, the only one who suffers there is you.
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.…
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 their hard-won knowledge becomes obsolete.
Earlier quoted context omitted.
> very grown up sport, more like running a country than building a house We need to stop calling things "grown up" when what we mean is that they take a different set of skills. It's childish, and I think it's been causing harm in our industry.
So it’s okay to refer to something as childish but not as grown up?
There are really two considerations.
1) Do you have any financial interest in sticking around? A lot of times when there is an acquisition, the acquirer offers employees a bonus to stick around for some period of time and hit certain goals. Or the salary might be a lot better. It could be in your interest to stick around even though the work situation isn't great.
2) How crazy is this making you? One option is to adjust your expectations and get used to things moving a lot slower. If you really can't put up with this, then there are a lot of other jobs out there. The bright side of this gridlock is that you probably have plenty of time to look for a new job.
In my case, I lasted about 4 months before I left. Within about two years, the product had been shut down and everyone involved with the acquisition had left.
Earlier quoted context omitted.
>Is this how military's organize themselves, or do they just get shi*t done? If you think the military isn't a large government bureaucracy with mountains of paper work, I recommend you talk to a veteran.
It depends. Special Forces team typically cut through a lot of that bullshit. Perhaps there in lies the answer. If you want the resources of a large organization and the freedom of a startup you need to look for the smaller elite teams within the org.