←back to thread

167 points godelmachine | 2 comments | | HN request time: 0.411s | source
Show context
ned_at_codomain ◴[] No.41888768[source]
Used to be at BCG. I think it's worth bearing in mind that relatively little consulting revenue -- even at the top strategy shops -- comes from pure strategy work anymore.

You can push much, much more volume and absolute impact through by running big merger integrations, digital transformation, and other large scale change projects at big companies.

It is basically a better business to become something like a premium Accenture, a "get stuff done" kind of consultancy. You can staff an army of junior people for a very very long time on those kinds of projects.

It's just not that easy to keep people staffed on 5-6 person teams solely on 8-12 week pure strategy engagements.

These kinds of projects are also the first discretionary spending yo get cut when times get tough.

If you're going to be focused on the pure strategy work, you'll probably want to stay really really small. We've seen some of this in investment banking with firms like Allen & Co or Qatalyst. Challenge is that consulting doesn't come with scalable monetization via success fees.

It's just not great business to be a boutique consultancy, I think.

replies(3): >>41888922 #>>41890128 #>>41891339 #
1. cpeterso ◴[] No.41891339[source]
> You can staff an army of junior people for a very very long time on those kinds of projects.

Given this is a common business model and has known bad outcomes, what would a Blub programming language and rapid development environment designed to improve the quality and maintainability of an army of rising junior engineers look like? (I originally wrote “productivity”, but reducing billable hours is not a positive outcome for the consultancy. They surely still want to produce quality software like to reduce customer-impacting bugs and negative headlines.)

Go was supposedly designed for a similar audience, inexperienced engineers at Google, but it is pretty low level and still has its own gotchas. I’m imagining some hybrid of Go, Python, and Visual Basic with strong static typing, strong functional orientation with little shared state (to reduce the blast radius of each junior engineer), easy unit and integration testing, excellent post mortem debugging, big ints by default to avoid integer overflow bugs, FFI for integration with clients’ legacy code, and portability to mobile apps, desktop apps, and web front and back end.

replies(1): >>41892083 #
2. Discordian93 ◴[] No.41892083[source]
F#?