I think an MBA will help you be a better manager if you want to be, because at least there's some clue about what a "good" manager should look like.
I've met sooo many bad managers. In most cases they were bad because they didn't really know what they were doing and they felt they couldn't look "weak" or not be in charge. There's always the urge to authoritarian leadership because it's the default (for some reason).
If the MBA course is any good, it will at least have exposed such a person to other leadership styles and some management theory. They might reject it, of course, but at least they'll know it.
So, yeah, I don't think having an MBA makes you a better manager or leader automatically. But I think a manager who wants to get better could be helped by doing an MBA.
Of course, there are lots of managers who are convinced they don't need to get better, and so won't/can't be helped. And there are lots of people who get MBA's because it's a ticket to promotion and don't really care about the learning.
I think even that part is disputed; we really don't know what a good manager looks like. Some of what's taught in MBA classes now is the opposite of what was previously taught, and there seem to be as many failure stories as success stories. I do take your point that maybe just thinking about anything other than the authoritarian mode is enough to raise a manager above the average, which is distressingly plausible.
I'm totally on board with highlighting the importance of communication, team work, people skills (and I've seen how awful it is to work with people who lack these skills despite their technical expertise), etc. but this statement I simply cannot agree with.
Everyone's experience is obviously different. Some people may work on problems where there are few legitimate technical challenges, or where they aren't solving any problems that haven't been solved before. That hasn't been my experience in most of the jobs I've had so far. There were significant architectural and sometimes even algorithmic challenges to be solved, and not solving them properly would mean either bugs or unmaintainable software.
ITT we talk about the importance of communication, but good coding patterns and architecture (as well as the right level of documentation) are part of communicating to other developers.
I get that, and I don't mean to suggest that some bits of this aren't tricky.
But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can make guesses on what we think the impacts will be. It's a "known known" problem, with usually enough time to research it fully. Implementing it properly can be difficult, but that's the kind of thing that can be iterated if necessary - we don't have to get that right first time.
There are lots of management and people problems where none of this is true and it's very much a "known unknown" that has to be got right on the first try, without knowing all the possible tradeoffs or consequences, and under time pressure.
No, I disagree. Some problems are truly novel (or maybe, there are just a handful of competitors and you obviously can't see their source code) and you just don't even know what kinds of solutions might exist. There might be bits and pieces in the research literature, but good luck even finding them, let alone understand if they are applicable. The space of possible technical and architectural solutions is infinite-dimensional, so it's not always a "known known" issue. There might be crazy solutions out there that you simply didn't think of.
Now, if it's about "create a CRUD interface to you e-commerce store", then I agree that the situation is more similar to what you described, but that's not what everyone is working on.
But in your previous post, you talked about architectural problems and there I disagree with you strongly.
Taken in isolation, individual technology pieces are relatively simple and easy to evaluate. But when you plug in one such piece into a middle of a larger system (let's say typical corporate IT landscape), then it becomes way more complex on all fronts. (Enterprise) architecture is also interfacing heavily with business decisions and company structure. You need to think a lot about how your ivory tower architecture will be actually used by the teams.
But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this.
But the political and social problems of "we got it wrong, we're going to have to start again from scratch" are the real problems. Dealing with a marketing manager who has a product launch scheduled for the 2nd quarter and you're about to tell them that you need to reschedule because you got the architecture wrong on the first try - that is a business problem not an architectural problem.
The tech problems get a lot easier if you have some kind of framework for dealing with the business problems.
This works nicely on a small scale, but not with the architectural problems.
> that is a business problem not an architectural problem
It's an architectural problem because this business constraint forces me to get the architecture right the first time - I won't get another chance.
There's no business reality where it's OK to say "just give me another 2 years to re-do the system in a (probably) better way".
But knowing how to frame that, and manage the expectations of the other people involved in that negotiation, and recognise their objectives and priorities, is a business skill.
And, y'know, if you spend 2 years building a system on the wrong architecture because you didn't know how to ask for more time to make a better decision in the first place... well, you need some management training ;)
And now back to your original claim. You need 3 months of prototyping only to reach a decision, but you still insist that it's an "easy" problem?
Then there's a problem that prototypes often don't uncover unknown unknowns. Investing effort into prototype improves your chances at arriving at correct solution but by no means guarantee it.
No it's not an "easy" problem - like I said, I get that these can be tricky. But in my 25+ years of commercial software experience, I've not bumped into one like this. I have bumped into complex technical problems, but the answers were/are always out there and findable. As I said, these kinds of problems are "known known" - you know what the problem is, there's a decent definition of what "good enough" is, and there's usually a lot of Comp Sci literature around to help.
Remember, this is in contrast to the people/business problems. For these, because they're involved the specific personalities involved, there is no definition of the problem (people will react to a situation according to their nature, and you can't check their source code). Often there is no good definition of what a good solution even looks like (except a broad "get everyone happy and working again" maybe). There is no literature describing the solution to the problem, or usually even addressing similar problems. And the problem always has a time limit - taking no action is seen as an action in its own right - and it's usually days at most. You literally have to make up some solution as you go along, not knowing if it's going to work or not. That's why I called these "unknown unknown" problems. In 25+ years of commercial software experience, I've bumped into at least a dozen of these (that's not including the "normal" run-of-the-mill management problems).
Your experience may vary - mine led me to conclude that the tech problems were not as difficult as the people problems, and that therefore I should get some training for the people problems.
For example: the network admin comes out as gay, starts having a relationship with someone on the night shift. The number of "emergency network outages" during the night shift suddenly spikes. A quiet word didn't seem to have any effect. The night shift supervisor is getting fed up of the disruption. Sacking the admin isn't an option. Sacking the nightshift worker isn't an option. Going down any kind of formal disciplinary process is the "nuclear" option as the company has to make absolutely sure it's not in breach of discrimination legislation. Ideally everyone would go back to work and be happy and the network would stop having problems at night (one of those where there is a well-defined "good result"). I didn't manage to solve this problem - the network manager ended up leaving in a huff (though thankfully not sueing us). I still to this day have no idea if I could have found a better solution to that problem. There is no technical problem that I've ever faced where I wonder 20 years later if I could have found a better solution (though plenty where a better solution has become available later).
If you want to get into management and deal with those kinds of people problems, then there are lots of management training courses around. An MBA is at the upper end of that range.
If you're having problems fitting into teams and getting along with people (actually quite common in dev teams), then maybe look at therapy or personal coaching. I spent a few years in therapy and it really helped.
If it's office politics and the like - some workplaces are toxic. I can't deal with those even with the training and experience. Life's too short to deal with that bullshit ;)
Perhaps read some books on negotiation if you have issues getting others to see your point of view.
Nervous about speaking in front of a group? Try Toastmasters once the world opens back up, or hire a coach.
Books are a good first resource once you identify the areas in which you want to grow.
But the real wins were the leadership and management units, to my mind. Learning the "formal" knowledge around this has really helped in subsequent management roles.
The entrepreneurship unit was vaguely hilarious, as I was running a blog for the local startup scene at the same time and neck-deep in Lean Startup, which no-one on the MBA course had heard of. Writing a really tight business plan seemed to be the hardest part of starting a business ;)
One of the really useful-but-unexpected things was having some kind of head-canon for "what a manager is and isn't" and (in one case) "what a CEO should actually be doing". It was really helpful having a kind of connect-the-dots picture of what should be happening and therefore what dots needed to be connected to make that picture happen.
If I want to be that consultant, what area would be a good choice to become proficient in on that level?
The more specific the niche, the less work you'll get but the higher you can charge for the work you do.
Get known as the expert in that niche. Write a blog on it, talk at conferences about it.
I don't know what areas would be good now, but I've hired consultants in scheduling problems, network setup and management, security, and recruitment.
If I had to pick an area that will never go out of style: security. Get good at being able to secure an online system and you'll never be hungry.
The tech is generally easy in commercial coding. There is usually a definitive answer, and if not then the trade-offs are generally well-known. It's rare to run into a problem that requires complex technical knowledge, and in those cases it's fine to hire a consultant to help.
But the people problems are hard. Getting clued-up on these is important.