They would couple this with things like standardized coding and documentation styles, common tools, etc. Training on these standards was a regular thing for all staff.

The idea was that they could rapidly move experienced staff around. It also helped staff to understand how their work was applied in an integrated system (having “blinders” on, is a fairly typical issue, with dedicated employees).

It generally worked, but relied on their particular culture, and introduced a fairly significant amount of overhead and rigidity to the system. It would also mean that it takes a long time to cultivate experts.

Personally, I’ve always enjoyed learning new stuff (still do). I actually enjoy taking on projects that I don’t know how to do. I wrote about it here: https://littlegreenviper.com/miscellany/thats-not-what-ships...

Everything is locked behind multiple layers of permissions. It takes weeks to get the correct permissions set up even for my actual job (which I see any time changing roles here, or when onboarding new hires). Getting the permissions to jump in and improve some other part of the system that I don't officially own - even though I might get granted them if I ask nicely, because nobody knows who is actually meant to have what permissions - is so much higher friction than asking the "right" person.

The problem with one is the same with any other single source: you are stuck with whatever they offer on whatever timelines they provide. You are sharing this with a hundred thousand other people, so it's not tailored to your use case, but either made as generic as possible, or full of irrelevant features. Both of these cases make it worse for you.

I have often made in house libraries either based on or completely replacing a free equivalent because the free one doesn't meet our needs and has extra complications we don't need. Yes, it comes with its costs, but sometimes it's worth it for something that genuinely meets your needs.

By forcing everybody to use the same common platform, you are either forcing them to work around the mismatch between the platform and their needs, or your are forcing the platform to provide for everyone's needs. Neither is efficient and it harms every other user.

If you are going to make your own, you had better have a good reason for it, but you shouldn't be forced into a single solution for everything - it can end up being more expensive than making a few special purpose applications.

It's literally the fastest way to have someone get up to speed with the customer profile and product. They can play with it whilst listening in to support calls (if a thing). They can learn about pain points and "hard edges" that as developers we don't always come across.

It's useful.

And then there's times like getting to charge your client $300/hour to drop stuff off at FedEx. Because you can do that and you're here and you'll get it done right -- no one needs to explain the idiosyncracies of this particular deadline or package contents; you've got it.

Even if that's not normally a senior consultant's job.

The comma count is a hint ;)

(I had to parse a few paragraphs several times to get the idea.)

I really wish this was more common in the industry, now as a Product Manager, while I do a lot to engage with field teams (Support, Sales) and work across every group in the company (Legal, Finance, Eng, Ops, Support, Sales, et al), I still only get interactions and snippets, it'd be great to go walk a mile in their shoes.

It all depends on stock options allocation, no?