Monday, July 20, 2009

Just Enough MBA to Be a Programmer

There's that awkward moment in your software development life when you realize that most of the people in your company aren't programmers. Scanning your address book reveals Marketing, Sales, Accounting, Human Resources, and yes, the "business people" with their Masters of Business Administration (MBAs).

I've always been curious about what MBAs really do. In my weaker moments, I've even thought that the only reason people got an MBA was to demand a higher salary or to "move up the corporate ladder" into some management job. What did these MBA ninjas actually learn in school? Would having an MBA help me better understand how I affected my company's bottom line? Although I had the curiosity, I never acted on it. This changed when another programmer recommended that I read The Ten-Day MBA by Steven Silbiger.

Sure, I knew that no one would anoint me with a real MBA at the end of the book any more than watching MIT lectures online would make me an MIT grad. Besides, going to a nice MBA school is more about being around other motivated people and professors. The real value in having an MBA is in applying the concepts, not the concepts themselves.

Disclaimers aside, I was determined to read the book and take notes on what a programmer should know about an MBA.

Day 1 - Marketing

Every developer painfully learns that technology doesn't win on its own. At best, it just gives you a shot at marketing. Marketing is proof that software doesn't sell itself, no matter how good it is.

A software company might have a Marketing Requirements Document (MRD) that outlines what the next version will contain. This usually is the result of a standard marketing analysis that the book outlined:

  1. Consumer Analysis - Who are they? What do they want? How many different segments of people do you have? Is the buyer of your product different than the user? (The book gives the example that women buy the majority of men's socks and underwear, thus it's good to market appropriately).
  2. Market Analysis - How big is your target market? Is it new? Is it growing? Where is the product in the life cycle?
  3. Competitive Analysis - How do your Strengths, Weaknesses, Opportunities, and Threats (SWOTs) compare to your competition?
  4. Distribution Analysis - What "channels" does your company use to reach your customer? Who are the intermediate players (e.g. the Apple Store, Amazon.com, etc)? What cuts do they take? What are their motivations?
  5. Plan the Marketing Mix - How will you differentiate your products? How will you place it, promote it, and price it?
  6. Determine the Economics - How long will it take before you break even? What are your fixed costs vs. margin costs? (Thankfully software has a low marginal cost)
  7. Revise - Tweak and repeat as needed.

One big marketing theme is to "own a word in the consumer's mind":

If you establish one benefit in the consumer's mind, the consumer may attribute other positives as well to your product. FedEx means "overnight delivery." Only one company can own a word and it is tough to change it once it's established... The easiest way to own a word is to be first. Consumers tend to stick with products that work for them. Kleenex cleans runny noses. p.26

This explains why your family still uses MapQuest despite your repeated attempts to show them how much better Google Maps is. It's also helpful if your product name matches what it does. "Drano" is easier to remember than a "Web 2.0" name like Qoop.

I was surprised to learn that the popular online advertising term Cost per Thousand (CPM), is a relatively old term that has long existed in print media. In general, the more targeted a group is, the higher the CPM is. This explains why a programming ad on Stack Overflow can probably fetch a better CPM than the same ad on a site like Pandora, even though programmers use both.

Marketing people typically have their reasons for doing things that frustrate us. For example, if your software will take a long time to get through a distribution channel or marketing foresees a long customer buying process, they might begin to "market" your code long before a beta is available with the belief that it'll hopefully be read by the time the customer is ready to buy.

Sometimes marketing has to make an extreme choice. When GTE faced rebuilding its tarnished brand in the 1990's, it was probably a clever marketing person who suggested that they give up on fixing their brand name and re-brand themselves as Verizon.

Despite all the good advice, I was disappointed by the book's lack of coverage of the Apple/BMW style of "marketing" the engineering department can do by creating a remarkable product. Creating a product that allows users to quickly jump over the "suck threshold" is just one example where a programmer can make a tremendous "marketing" contribution.

Day 2 - Ethics

Ethics seems easy to understand: "Do to others as you would have them do to you." The hard part is realizing how the "others" are affected by your actions. Others include customers, executives, shareholders, suppliers, employees (and their families), the government, the planet, and the "future generations."

Unfortunately, when simplicity is lost, Sarbanes-Oxley Acts are found.

Day 3 - Accounting

In theory, accounting is simple. Just answer these questions about your entity/business:

  • What does a company own?
  • How much does a company owe others?
  • How well did a company's operations perform?
  • How does the company get the cash to fund itself? - p.72

If you get nothing else out of accounting, know how to read a balance sheet. Although Microsoft CEO Steve Ballmer dropped out of Stanford's MBA program to become employee #24, he knew balance sheets were important:

In 1980, I came in to "be a business person" whatever that meant. Didn't know much. Frankly all I'd ever really done is interview for jobs and market brownie mix. I wasn't exactly well credentialed. I'd taken the first year at Stanford Business School so I can read a balance sheet -- that was pretty important. We didn't have that much money back then so there wasn't much to read. But anyway those lessons were important.

Balance sheets are simple to follow:

As the name implies, the balance sheet is a "balance" sheet. The fundamental equation that rules over accounting balance is:

Assets (A) = Liabilities (L) + Owners' Equity (OE)

What you own (assets) equals the total of what you borrowed (liabilities) and what you have invested (equity) to pay for it. This equation or "identity" explains everything that happens in the accounting records of a company over time. Remember it! - p.83

For example, your work computer is a company asset (which explains the "asset" tag on it). Your company created an equal liability to pay for it. When your company started, the founders gave up some of their money to increase the new company's cash assets (left side) in exchange for stock in the company (right side).

For example, we can read Google's balance sheet for the first quarter of 2009 and see:

Assets = $33.51 Billion
Liabilities = $3.66 Billion
Owner Equity = $29.85 Billion (which includes $14.98 Billion in "retained earnings" that Google is keeping for growth rather than giving it back to the owners of its 315.75 million shares)

Sure enough, everything "balances":

From basic data, we can derive a bunch of helpful ratios to see how healthy Google is:

  1. Liquidity/Current Ratio = (Current Assets / Current Liabilities) = 33.51 / 3.66 = 9.14 (Greater than 1 means there's room to pay for liabilities)
  2. Financial Leverage = (Total Liabilities + Owners' Equity) / OE = (3.66 + 29.85) / 29.85 = 1.12 (Greater than 2 indicates a company is using a lot of debt to operate)
  3. Return on Equity = (Net Income / Owners' Equity) = 1.42 / 29.85 = 4.77% (Which indicates how efficiently the company is using shareholder equity)
  4. ... and many more ...

Day 4 - Organizational Behavior

The whole purpose of Organizational Behavior (OB) is to get you to think before you act around people. You want to motivate people? OB has an equation for that:

Motivation = Expectation of Work will lead to Performance * Expectation Performance will lead to Reward * Value of Reward.

Feel free to tweak the variables as you see fit. You can Manage by Objective (MBO) where you set goals and then get out of the way or you can Manage by Walking Around (MBWA) where you play a more active role in day-to-day execution. The best choice depends on your environment and culture. You might need to mix the two. Remember that we humans are delicate creatures with our own wants and desires. Be careful.

Day 5 - Quantitative Analysis

Quantitative Analysis (QA) explains why Excel has so many functions that I'd never heard of. A core idea is that "a dollar today is worth more than a dollar received in the future." (p.173).

Imagine that someone promises to pay you a dollar in a year if you give them money now. What is that worth to you today? Obviously, it matters on how much you trust them to pay you back. The more you trust them, the more you're willing to give them now. Similarly, the less you trust them, the more you might "discount" that dollar in the future because they're tying up money that could be used for better investments. This is called the "discount" or "hurdle" rate. Having a 10% discount rate means that the dollar in the future has a net present value of $0.91 today:

$1 * (1 + 10%)-1 = $0.91

This simple idea has lots of consequences. For example, let's oversimplify things and say that you can spend $2,000 today to buy and maintain a server that will last for 3 years or you can lock in a price with Amazon for that same server for $800 a year for the same 3 years. A naïve person would just see that $2000 is less than $2400, but a QA person that assigns a 10% discount rate would see:

... and come to the conclusion that it's about $10 cheaper, in today's dollars, to have Amazon maintain the server.

You can also do the inverse calculation. Assume you're Amazon and that server costs you $1800 today and you can get someone to pay you $800 a year for it for 3 years. What is your internal rate of return for this investment?

Here we see an internal rate of return of about 16% on the server.

We could also use the time value of money to include valuing users. Early adopters of eBay and Twitter were worth more per user than late adopters because the early ones were more likely to tell their friends who hadn't used the service and thus attract more new people.

Day 6 - Finance

Finance blends time, money, and risk.

To start, a business needs a structure that gives it some capital. Popular options include:

  • Sole Proprietorships - An individual or a married couple. You are effectively your business. All earnings are treated as personal income and taxed appropriately. You take in all the profits but also have unlimited liability. You can't divide the company up. It's simple, but the downside is that it makes it hard to raise money.
  • Partnerships - Involves more people than a proprietorship. Several people come together and can be general partners (each having unlimited liability) or limited partners (liable up to the investment). As a partner, you pay taxes on your percentage of the business's income on your personal taxes.
  • Corporations - Effectively you give birth to a new legal entity that is distinct from the shareholders. Most large companies are "C Corporations" and have a double taxation issue where the corporation's income is taxed and the dividends it issues to shareholders are taxed as well. If you have a smaller company with fewer than 100 shareholders, you may qualify for "S Corporation" status. S Corporations usually don't pay income tax and instead rely on shareholders to pay the associated tax on their percentage of the income. This tends to give S Corporations the legal liability benefit of corporation status and the single taxation benefit of partnerships.

Corporations issue stock to raise money. Stock entitles the holder to a residual claim on earnings and assets after other debt obligations have been met. One obvious question is "what's a good stock price?" This has a lot of factors, such as a company's growth potential and the company's earnings. Popular metrics include a company's ratio of its stock price divided by its earnings (P/E ratio). Higher P/E ratios tend to indicate that shareholders have higher expectations the company will grow and eventually make more money in the future. Some examples:

CompanyP/E Ratio
Google31.47
Microsoft13.98
Amazon.com54.98

After you raised some capital, you should carefully think how you'll spend it. There are many ways to do this. The Payback Period Method has you calculate how long it'll take to recover your investment. The shorter the payback period, the less risky the investment is. For example, adding RAM is so cheap that the productivity boost has a short payback period. In contrast, completely rewriting a huge codebase might have put your company out of business before you get your money back.

Another approach is to use the Net Present Value Method to see how much the investment will return over its lifetime in terms of today's dollars. Once you determine the discount factor to reflect the risk, you only consider investments that have a positive Net Present Value.

Day 7 - Operations

Operations is about making stuff. Popular operations guys include Frederick Taylor from the late 1800's who is famous for breaking up tasks into small pieces and walking around factories with a stopwatch to find the "one right way" of doing them. Elton Mayo's bold claim was that caring about your employees mattered. You could even make terrible working conditions if the employees were otherwise treated well and felt important.

Although some MBAs might use some programming techniques like optimizing flow-charts to improve operations, it's more likely to see factory techniques used when managing programmers. Oversimplifying things, software development is a factory that turns capital into code. To this end, you'll often see popular manufacturing processes like Toyota's Kanban method of using visual cards to control workflow making their way into our world as "new" or "agile" software methodologies.

Day 8 - Economics

Economics is the magic that allows me to write software in exchange for steak burritos. As Adam Smith realized, society as a whole becomes "wealthier" when we seek division of labor to specialize and do something well rather than trying to do everything ourselves poorly.

At a micro level, economics is a simple matter of supply equals demand. When you look at the larger/macro economies, more complicated equations pop up like this one:

Money * Velocity = Price Level * Real Gross National Product

This equation shows that it's important that money is moving around (e.g. isn't hidden under your mattress) and that prices are stable or have reasonable growth.

One of the best things about the economics of software is that it has really low marginal costs (e.g. the cost to copy it). With processors, bandwidth, and storage all roughly following Moore's Law exponential curves, the capacity is doubling every 18 - 24 months which implies that the cost for a fixed amount is falling by half over the same period.

As Chris Anderson points out in his book Free, it can sometimes makes sense to round these increasingly lower marginal costs down to zero and make money in different ways such as advertising or selling complements. It's hard to find other industries that have as many economic freedoms as software.

Day 9 - Strategy

Strategy should be simple: have a remarkable product that people want. Bad things happen if you don't do this. It's especially helpful if you have a cash cow you can milk for lots of money to fund new initiatives. For example, Google makes so much money from ads that it can have this strategy:

Revenue = Amount of Web Pages Viewed

Google's strategy of getting you to view lots of pages (which conveniently have Google ads on them) explains a lot of what it does. From wanting to speed up the web, to making a free phone OS, to creating a ton of free services to keep you hooked on the web. Google really doesn't care what you do so long as you enjoy it and take in the targeted ads.

The book tended to focus on more traditional forms of strategy such as "cost leadership", "differentiation", and "focus on the customer" as well as applying lessons from the famous prisoner's dilemma. I acknowledge that these are important as well, but I think that at its core, strategy can be simple.

Day 10 - Minicourses

The book ended with "minicourses" in areas relevant to business such as:

  • Property (real estate, patents, copyright, etc)
  • Leadership (e.g. schools want to create 'leaders' because they'll be better future donors).

Although those were interesting, the section I enjoyed the most was on business law.

In our jobs, we often bump into legal matters. We face End User License Agreements (EULAs) and Non-Disclosure Agreements (NDAs) that we rarely read and often don't fully understand. It was interesting to see any proper contract requires the following four conditions to be valid:

  1. Capacity of Parties - Parties must have legal authorization and be mentally capable to enter into the agreement.
  2. Mutual Agreement (Assent) or Meeting of the Minds - There must be a valid offer and an acceptance.
  3. Consideration Given - Value must be given for the promise to be enforceable.
  4. Legality - You can't enforce a contract dealing with illegal goods or actions.

When bad things happen, it can sometimes escalate to a "legal action" which has a standard procedure involving steps you sometimes hear in the news:

  1. Jurisdiction - For a court to hear a case, it must have "jurisdiction" to hear the case and power to bind the parties the decision.
  2. Pleadings - The paperwork to start the trial process. The plaintiff (p) files a complaint asserting that the defendant (?) has done something wrong and requests a punishment or remedy.
  3. Discovery - Lawyers gather witnesses and evidence before a trial. Each side is allowed to see the evidence held by the other side.
  4. Pretrial Conference - The lawyers and judge try to focus the case on the most important issues. This is also good time for out-of-court settlements if possible.
  5. Trial - Occurs before the court. The jury decides the factual disputes. The case can be thrown out by the judge with a "summary judgment" if it has no merit.
  6. Jury Instruction by the Judge and the Verdict - The judge instructs the jury about the relevant law involved and the jury makes its decision about the facts and penalty within its authority.
  7. Posttrial Motions - Options include asking for a retrial if an error of law or procedure occurred (e.g. jury misconduct).
  8. Appeal - Each party in a lawsuit is entitled to one appeal at an appellate court where they can file a written brief with arguments for a new trial.
  9. Secure or Enforce the Judgment - Send the person to jail and/or collect money.

While the short overview was intriguing, it enforced my belief that it's important to have an attorney or a lawyer when it comes to the legal matters. At the very least, they usually have malpractice insurance if things go really bad.

Conclusion

The Ten Day MBA helped me move from being unconsciously incompetent about business administration to becoming consciously incompetent in just a few days. I think that alone made it worth the time. I don't have aspirations to get a real MBA, but I now have more respect for those that do.

And now, back to programming...

28 comments:

Anonymous said...

Great post. I applaud you for taking the time and effort to understand the other side.

Having been on both sides of the table, formerly a Java certified programmer with over 5 years of programming, each side cannot understand the other until you fully get into it.
Over simplification gets everyone into trouble. Try explaining caching schemes to an MBA and their eyes glaze over. Try explaining the non-cost of debt versus equity to a programmer and you get the same results.

Thomas said...

Nice summary of the book and I would agree whole-heartedly with your comments and position that knowing what an MBA does is important. Just as they should know what programmers do (they don't need to know how to code, but they should know what programmers really do).

Adil Dhalla said...

Good Job and your desire to see the other side and share it is laudable. I was particularly happy with your conclusion as I'm used to defending the value of an MBA. Like most things, it comes down to the person and the people they surround themselves with. Like you, I thought I could get all i needed via reading on my own but going to school anyway opened my mind (or filled it, depending on how you looked at it) and most importantly introduced me to my two partners. That alone made it worth it

Anonymous said...

Nice summary. These are just what finance MBAs do, just glorified accounting. All the finance issues come from accounting. Then there are other MBA types that get into every profit and non-profit activity. The one place I see MBAs and programmers work similarly is in operations research, transportation research, environmental protection, and so on. In fact many MBAs in these fields come from programming backgrounds.

Anonymous said...

As a person with an MBA and a MS in Comp Sci, I would like state that a little knowledge is a dangerous thing. I went for an MBA when I was asked to manage people as I was always annoyed when people started to code with no background. Also, the mistakes as a manager can be a lot worse, "Sorry for screwing up your career, but I was to lazy to be trained". Knowing what other do is valuable, trying to do professional work without experience and training can be a disaster.

Jeff Moser said...

Anonymous #1, Thomas, Adil Dhalla, Anonymous #2: Thanks for your kind words and anecdotes.

Anonymous #3: I especially enjoyed your personal experience and the quote. How long ago did you get your MBA? What have you learned through experience since?

I'd love to hear more stories, especially "in the trenches" stories/anecdotes.

Also, if anyone thinks I missed an important MBA topic, I'd encourage you to add it as well. I'm trying to get a real picture of the "other side."

Thanks!

Lux Mentis said...

I forget the fellow's name, but the head of Chapter's book chain, before they somehow merged/amalgamated with Indigo, was an ex-officer from the Canadian military.

He realized that the MBA was a good step for moving into the corporate world (probably got a fair bit of leadership training in the military, but not all of those lessons are applicable in the civilian world and in fact some are a really bad idea to try).

He said anyone who is running a corporation of any size had better go and get an MBA as it would be a huge asset in that sort of role. He obviously saw the value directly in his day to day work of running a major chain retailer and overseeing everything from marketing, to personel, to product and finances.

On the other hand, much like an engineering degree, you can have useless MBAs just as much as you can have useless engineers. I've met both sorts of folks in 15 years of programming.

Where I went to school, a small but good Ontario college program, they taught us how to read and understand balance sheets and a lot of the sort of background of how businesses work - but that was because one of our instructors was ran his own business (computer consulting) on the side and in the summers. It also helped that the program head had formerly worked for Intel and had come out of the Irish education system.

Donald said...

I remember Joel of Stackoverflow telling me to take Economics/ Business Administration seriously in one of his posts (I'm still in college).I Took Micro-economics last semester and was asking myself why I was doing this... I could have been doing something more interesting (programming). Happens the course thought me a lot about the world of business and I'm gladly going for Economics next semester. Who said programming was all about "code monkey'ing"?
Great post Jeff.

jtes0111 said...

Excellent post. I think I might get a copy of the book myself.

I feel it is very important for any programmer to have an understanding of business even if they are only ever doing development work. It gives some perspective to what others in the organisation are doing and can even help you to make better technical decisions. But far too many programmers just seem to focus on programming and treat "business" as something foreign that doesn't concern them.

It is also something that companies are starting to realise. For instance where I work, all the new graduates (in technical roles) get sent on a part time management course over 2 years. It covers all of the topics you have mentioned above and is equivalent to about 1/3rd of an MBA.

Anonymous said...

This is an excellent posting, and I thank you for it.

One thing to note -- in doing this independent research (self education), you've done far more to complement your skills than do 90% of MBAs. Really good, insightful (and esp. the entrepreneurial), software engineers want to understand the entire scope of a problem domain, because we look at things as complex and connected 'systems'. We can observe, find patterns, generalize to an abstraction, reconcile and rationalize our models with reality, and then automate them.

Thus, software engineers learn to be creative in a variety of problem domains. Most other disciplines, conversely, map the world into _their_ thought models. That is, just try to get an MBA type to think of the world in anything other than MBA-speak....it's hard to do. As part of the MBA persona (we have our proud geeky persona, after all), they tend to be a bit dismissive of ideas not expressed in their terms.

I find the substance of an MBA quite interesting. But, the name 'MBA' has been meaningless since its introduction and hype in the late 80s and early 90s. The name itself is egoistic, and misleading. I've met _zero_ MBAs who are entrepreneurial (and I know some from some well-known name brand institutions). At best, they learn how to think about business analytically. Perhaps it makes them better managers ... I don't know.

mezped said...

Due to the fast changes in technology, a programmer learns to adapt to new concepts easily and solve problems. And considering that a programmer can understand how dijkstra's works and how to use it for example, then most business conecepts shouldn't be too hard to grasp with enough time. While in the other way, a business person can be really good with his stuff, but he/she will hardly be able to (not just program) but solve complex programming problems.

Jeff Moser said...

Lux Mentis: It's always good to have a teacher that's been there.
Donald: What stuck out from your courses? What surprised you?
jtes0111: Interesting... what sector is your company in?
Anonymous #4: Could you elaborate on the "misleading" claim? Does "business administration" imply an entrepreneurial aspect is needed?
mezped: It's a give and take, right? If the business side doesn't succeed, then there won't be cash to fund the programmer. If it was easy then why don't we do it? Is it just because it's uncomfortable to us? Is it just too different?

Sujit K Singh said...

Nice post, It tells the truth about various perspective of the same thing from the different view point.

Thanks

Cameron Robertson said...

Very good, high level summary - those are certainly the points that someone needs to walk away with from business school.

Conversely, I agree with all of the points noting that business people need to take programming courses in order to grasp the area conceptually.

The one piece that needs to be demystified - sales. I feel that business schools (speaking from my undergrad experience) offer far too little in the way of actually having students close deals.

Donald said...

@Jeff:The concept of opportunity cost was really prominent in my course. The cost incurred due to the choices made in an economic sense fascinated me. What surprised me the most was realizing how coupled life is to economics.Every action we take has economic relevance.Back then economics was as disjoint as it could get from everyday life.

Jeff Moser said...

Sujit K Singh and Donald: Thanks for sharing.

Cameron Robertson: Can you share any advice on how to close deals?

mark said...

It's siezing the opportunity to share and annotate content like this that makes the internet worth powering, Jeff. Thanks!

Looking forward to the sitck figure version :-)

On the "flip side", I think, if you haven't already read it, Singh's "The Code Book" would be a fun read. Not being on the crypto/tech side or the bus side, I think it make a great case out there for the "It takes all kinds" argument to make the world go 'round.

Mark Chernisky

Jeff Moser said...

Mark Chernisky: Stick figures would have taken a lot longer ;) I read The Code Book in high school. You're right, it's a fun read.

evan said...

fun post to read as I've worked for MBA-types all my professional career. I get frustrated dealing with them but I understand why they are there (and your synopsis of "their" world opens my eyes a bit). But, my passion is for coding (and de-coding sometimes). On the crypto side, another fun book is David Kahn's "The Code-Breakers" as well as, my fav, William Friedman's "Military Cryptanalytics" as well as Lambros Callimahos accompanying volume (declassified a while back).

I'm a former cryptanalyst now making codes instead of breaking them...

Jeff Moser said...

evan: Agreed -- I still enjoy the technical side more than the MBAish stuff, but it's good to see both sides. I haven't read Friedman's book, but I've read good things about him. Thanks for stopping by!

Kristanna said...

I'm thinking of doing my MBA... I've heard around alot that it effectively, in a few years, but you in a good management position, and easily puts your salary at 130k+. There's so many sub-fields for MBA (I'm a developer myself, and I'd like to get into PM or management, some form of mangement), but it's really tough to find any information on exactly what I'd be getting myself into. Any insights, what are your responsibilities?

usb sticks

Jeff Moser said...

Kristanna: I'm a developer as well and don't have MBA-type responsibilities. Our MBA people create things like a Marketing Requirements Document (MRD) that defines the market environment that our software will be going into and core things we need to have in it to differentiate it. Software design usually comes after this.

knud said...

I concur with all the other posts in that I found the summary very good and have added the book to my wishlist.

If I may, the one book that I've found most useful in this context is High-Tech Ventures by Donald Bell. A few parts are a bit dated (like the business plans for Apollo and Sun!), but the principles are still very sound. After more than 25 years of programming, hardware dev, startups, big R&D, small R&D, etc., I still turn to it for a better understanding of the gestalt of high-tech.

High-Tech Ventures

CL said...

Jeff: Very informative post, thanks for sharing your insights.

I have also contemplated pursuing an MBA for the past few years, and more seriously in recent years. I have been working as Developer for 6 years since completing my B.Sc Computer Science in 2004. I've often felt that unlike a lot of the colleagues I've worked with, I've always been fascinated with the bottom line in terms of numbers, how projects impact the company -- essentially the accounting aspect of a business.

I am thinking of applying for a school for Fall 2010. But I am unsure of what I want to do after it, namely whether to abandon the technical career track to go into project management, business analysis, etc. Also I've heard a lot of people say that an MBA is only worth pursuing for the "networking aspect" or if you are seeking a career change (e.g. 'the Bachelor of Arts degree isn't getting me a very good paying job'). And until I read your post, I thought that those would be the only reasons for studying for an MBA. So I'm happy to see that there are like-minded programmers who want to study because they want to LEARN.

And personally I think all MBA programs should require a minimum of 4-5 years of work experience. There is a substantial (and valuable) difference between 2 and 5 years of work.

Jeff Moser said...

CL: Thanks for sharing your story! My only advice would be to do what you like doing instead of being lured by prestige or money only to do things you don't like doing. For me, I like the technical side too much to switch to be primarily operations/admin focused. That said, I still think it's good to at least know things that the "other side" uses that I mentioned in the post.

I've heard of some balances where you do both (e.g. Jeff Atwood managing Stack Overflow and working on the code.)

Jeff Moser said...

knud: Thanks for the book suggestion.

Aspiring Engineer said...

Jeff, nice overview analysis and observations from your post on the "Just Enough MBA for Programmer." I will def read this book for further self-inquiry.

Some points I also thought of.

This is an excellent post for us other software folks who think MBA is to demand higher salary. Instead I think a MBA is designed to make you a stronger contributor to both the technical and professional worlds, well-rounded, and provides you a foundation to become a highly successful individual. Several successful industry leaders specifically in the technical field who have both the MS/PhD and the MBA are able to drive some of the strongest research based companies in the world like IBM and Google.

Furthermore, the MBA provides the project perspective means to put the great idea of the engineer into the market place without breaking the company's development budget. Having both is in my opinion a tremendous asset.

Jeff Moser said...

Aspiring Engineer: I think an MBA can help if you already have the drive to work hard. I'd be curious to see the difference between a highly motivated person that just read and applied this book vs. someone that went to a elite MBA program but with just average motivation. Knowledge is helpful and can be an asset, but execution matters a lot as well.

Thanks for stopping by!