As I've implied through my other posts, I'm still fairly new to the workforce. During team meetings, I tend to be able to keep up with technical discussion, but when my project manager starts talking about how we've won a new contract, or we're involved in a new proposal bid, or... anything that's business rather than technical, really... I can get lost pretty quickly.
What is the bare minimum all developers need to know about project management/business to function?
I think you need to understand how your company makes money. You also need to be able to evaluate if you should do anything to help it make more money, i.e. do your job better. Most importantly this means that you need to be able the tell which task you're working on you should put the most effort into and how to prioritize the tasks you've been given.
Also, programmers need to understand that even though something might technically be the best choice, that choice might not be the best choice for the business. And that is a good reason to not take the technically best way.
Knowing about business and management - and marketing - certainly cant hurt. It really depends on the context in which you work.
In a large business where there's levels of management making decisions and where tasks are very well devided up based on job titles, it may not be that important. Your company probably has dedicated people to handle that end of things.
In a small business, on the other hand, the more you know, the more direct value you are to a company. For example, having a good marketing sense might help you feel out better/worse designs for a web site. Or you may have to deal more with customers, or go along with a salesperson to help close a deal, or attend trade shows, or just plain be on the lookout for a possible new revenue source/saving opportunity.
So, as usual with a 'how much do I have to know' type question, the answer is, more knowlege is always better, but the extent of its importance really depends on your individual situation.
At least you have to deeply understand that your salary is not just automatically coming from somewhere. You're not getting paid for sitting and coding. It's the success of sales and relationships with customers that makes or breaks your company's (and ultimately your) success. That's where the money comes from.
Even in a large company where the programmers aren't directly in contact with end customers, it's worth emphasizing that it's shipping products early that matters most. That's how the company wins sales and gets money and you get paid. Granted, shipping a half-assed product (too early) is a mistake too, and finding the right balance here is hard, but programmers tend to lean too much to the "ship when it's completely done (which is almost never)" side. But looking at the successful ones reveals the truth; few of them had a mature, finished, polished product to start with.
Knowing and accepting that essence of running a business is the important thing. Even if you're not particularly interested in business (I'm not), you simply can't ignore it as "white-collar stuff" if you're yourself interested in getting paid. Technical details and vocabulary of business/management aren't that important to know, IMHO, although learning some basics certainly doesn't hurt.
What is the bare minimum all developers need to know about project management/business to function?
"...good technology is only 10% of success. If your management doesn't know how to manage a successful engineering project, or your marketing department doesn't know how to access the customers, or doesn't tell you what the customer wants, or if your lawyers don't handle your intellectual property correctly, or if the chief architect doesn't have the ability to create a consistent and simple architecture, then your work can be for naught, and you can spend years building things that never see the light of day." (The Things I Wish I Learned in Engineering School...)
Not wanting to be mean, but I'd say "they need to know to leave it in the hands of people who's job it is". As much as this sounds like heresy, you can't know everything.
But, yes, one should know some minimums, some fundamentals of economy. So, let's say, fundamentals of microeconomics (microeconomics <- economics that deal with a small system, say a company), some basic economic theories (Is inflation good or bad for you? What does it mean? Is raising import good or bad? How does it affect other factors?), some basics of how the social system works (if you're in a country that is organized in that way), basics of bond trading (if you're in a company that is organized in that way) ...
If I've however, misunderstood your question, and you're asking what is a proposal, or a bid, ... those can be better explained on wikipedia. The rules concerning them are however, more of a law topic, than an economy one.
but when my project manager starts talking about how we've won a new contract, or we're involved in a new proposal bid, or... anything that's business rather than technical, really... I can get lost pretty quickly.
The only to learn more about the business is to actually get involved. The meeting may not be the best forum to broach certain questions, but most definitely after such meetings ask your manager to expand on the proposal or the business related stuff that you got you lost.
Questions like,
Each of the above are small indicators of how your company works. It gets you closer to the internals and inner-workings so at least know how the business makes money. I think the main point here is to ask about the stuff you don't know!
Also "I can get lost pretty quickly" either means to me, you give a sh1t or you really don't know. The attitude you have can make a difference if you want to learn more about it.
What is the bare minimum all developers need to know about project management/business to function?
On this aspect, I don't think there is a concrete answer. My initial thoughts would be some basic accounting and people skills. Project management and running a business are two different things, however there will be some overlapping skill sets.
Just remember - the skills you learn as a developer 'sometimes' (if not most most times) become null and void when you shift to a higher position (such as a manager). Eg. your people skills will really need to more focussed on now compared to your previous role as a developer.
General tip - learn/practise/improve on other less technical skills early in your career since this will be beneficial in later years (unless of course you still deciding)
Knowing what is asked to your manager can help you undestand why he asks somes things, or why work is done in the current way. You then can adapt yourself, or find a better way to give him what he wants/needs.
The bare minimum depends on the company. I've worked at a place where other people were responsible for program design, and I had to translate detailed specs into COBOL. That's really not much fun, but I didn't need to know anything about the business at first.
Once you start having some say in program design (or, preferably, if you start there), you need to know what the business is doing, so you can understand what your users actually need. Knowing more about the business means that people need to tell you things in less detail, so your value to the business grows. You can sometimes do things on your own initiative that help the business, also increasing your value. This is often reflected in your job title and paycheck.
It's also helpful to have some idea of where the money comes from, where it goes, and why some of it goes into your pocket. You really should have some sort of idea why the company pays you. It may help your motivation to learn to know that those new contracts are the things that provide your pay.
It's also likely to help if you know what business affairs mean to you, how a new contract affects you.
Obviously, if you don't want to stay in a purely technical role forever (and, empirically, that seems a little rare), you will need to understand the business much better, but it will help anybody to understand what's going on.
As other answers have stated the minimum will vary from situation to situation. For example, a self-employed contractor may need to know a bit more than the full-time employee as the former may need an accountant and others to help run the business the contractor has.
There are some basics on financial health that I'd consider some basics like understanding where is your company in terms of maturity: Is it a start-up still burning angel investors money or venture capitalists money now? How close to profitable is the company? Are there any big lawsuits that may kill the company in the near term?
I think some of the basics of understanding a project plan at a high level, how change requests are handled, and what kind of general process is there to get through a project are key things to know, as well. I'm not saying you have to know all the steps in the change management process, but do be aware when this is used and how it may impact your project.
If you want to get more into the business side, you may want to inquire about more details of the contract that was won. How many units are being sold? Is this an initial pilot project at the client or is there a mass adoption now? Those basic kind of questions that may help give a bit more detail to what you may end up having to tackle next. For example, if your company started getting massive orders, couldn't this lead to some systems being pushed to their limits that may need to get remedied ASAP, no? While I did give some vague areas and only a few specific examples, these are the parts that I tend to notice with a company. How bureaucratic HR is would be another factor to not forget here to some extent.
