I am developer / analyst in an internal IT department at a medium sized business. I have to deal with business people all the time and many of the things I create can have profound impacts on the business. I am starting to regret not taking any business classes in college because I don't understand the first thing about running a business so I don't always understand what people are wanting, the best I can do is "think through it".

Does anyone have suggested methods of learning this stuff, maybe some resources. And please don't just say to ask people who work here. I have tried that before and I get no where.

closed as off-topic by gnat, user40980, Bart van Ingen Schenau, Kilian Foth, GlenH7 Dec 5 '13 at 16:24

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic here. They are only meaningful to the asker and do not generate lasting value for the broader community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – gnat, Community, Bart van Ingen Schenau, Kilian Foth
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Take night classes for your MBA? That's what one of my coworkers is doing. – CaffGeek Nov 16 '11 at 21:43
  • @Chad an MBA would be overkill for this. Simple business classes at a community college should be sufficient and not as hard on the ol' pocketbook. – Jetti Nov 17 '11 at 19:59

The people you work with are your best resource for understanding their business needs. Businesses get and keep a competive advantage by doing things differently than their competitors, you won't find that informtion in books. Perhaps the problem is how you ask them or what you ask them.

First, many developers come across as arrogant idiots who think everyone else is stupid. This attitude tends to make people less than cooperative about helping you learn. So first things first, check your attitude and your body language and your tone of voice when talking to the users to get requirements.

Next, find the person who has the most stake in the product you are tasked with developing. Have him or her give you a Power Point presentation on the business needs the application will meet. Tell him that you need a better understanding of what they do in order to help them do it better. This is not in the terms of the requirements but just in terms of an understanding of what the jobs of the users who will be using the system are. Ask if there are regulartory requirements they have to follow. Ask to get a copy of them or a link to them if it is too much to print out.

Ask about industry trends; subscribe to reading lists about your industry (I read the news in my industry, it helps me make suggestions for possible application changes that can keep us ahead of the competition).

If the product contains data that will need to be audited, talk to some auditors about what they need to see and more importantly why they need to see things that way. Learn something about IT auditing, it is an interesting field that will serve you well in developing business applications. Pay particular attention to the concept and practice of internal controls. These are critical in any financial application.

Spend some time observing the actual users right now as they work. Take notes. You will see many things that no one ever thinks to tell you in a meeting. Don't just talk to managers about what needs to be done. Talk to the actual users where-ever possible. Invariably they will perceive the application differently than managers will. It has to work for them though in order for the managers to see the data they want to see. Ask them what problems they have with the current solution. Again they will tell you things the managers would never think to tell you.

Getting back to the managers, ask about reporting needs. Business applications tend to have a data entry need and reporting need. You aren't done until both have been discussed. It does no good to put data into a database if it can't be gotten back out in the way the managers need to see it.

When they tell you something needs to happen that you don't understand, ask for further details. Ask what problem they hope to address with this change. Often you will find that they are suggesting a solution that won't completely solve their problem. In fact always ask for further details, it is a rare user who will tell you everything you need to know without extensive questioning.

Pay attention to edge cases when you talk to them. If they say something needs a managers approval for instance, ask what needs to happen if the manager doesn't approve.

Ask for reading material or websites that talk about the professional needs of the users. Ask for copies of any corporate regulatiosn that affect the application, any laws or government regulations that affect the application and any paper forms that data entry people will be entering data from (It's amazing how much easier it is to enter data when the form and the paper form have the fields in the same order, I was entering voter application data once and the form was firstname lastname and the data entry weas last name first name, imagine how many errors that creates.).

Talk about what information the user needs at his or her fingertips at all times to do a good job. Do the tasks need to be done in a set order or can they skip around?

Finally, sketch out prototypes and take them back to the stakeholders and discuss again. Often people can't visualize very well, help them see how the program will work before you spend any time building it. Do this on paper as a very rough sketch, so they don't think that just because you have a pretty page built that the application is finished. Users think the Interface is the whole application, if it looks finished, it is finished in their minds.

Start building a list of questions to ask that show you are thinking beyond the data entry. Ask about security of the data, how private is the data and who should have access to see or change it. Think about how the application will work over time not just what needs to be there for launch. Do you need admin pages to keep the drop down lists up-to-date as the items to pick from change?


I am not convinced any general business information will be much help. There is a big disconnection between the theory about how businesses should operate and how things are actually done.

The best source for information is from the people who will be using your application.

After that I would suggest starting with the type of industry your business operates in. There are a lot of highly regulated industries where there are specific guidelines you must follow with the data.

Financial? Sarbanes–Oxley is good to know.

Healthcare? read up on HIPAA.

Granted these are very complex topics and it is not practical to learn every in and out, but you would be surprised how just having some basic knowledge helps.


Good question. I work for banks mainly, but I got there without taking classes in finance. I wasn't even aware of banks beyond what you find in the high street when I first left college. I do a lot of work directly for the business though, so I have to speak some of the lingo.

Things that will help.

First, ask questions. People won't think you are ignorant or irritating or what ever, just ask the questions, get the information and use that to deliver what they want.

Second, focus on delivery. Always keep in mind that the goal is to get software out to the users that solves what ever problem they first brought to you. Use prototypes, mock stuff up in Excel, you that to get early feedback from the users, use that to learn. If you keep that eye on delivery, when you are talking to the business they will get the impression that you are working towards a solution and they will be able to see evidence of that. They will then be more willing to help, and will pick up on errors before they become a problem.

The obvious one is read a book on your area of business. As I said, I'm in banking, so I have books on everything from options to stock lending. With that in mind,

Third, you don't need to know as much as some would think. You don't need to know how to turn oil in to rubber to be able to change a tyre and software is much the same. Honestly a lot of the stuff is reconciliation, getting numbers from somewhere, extracting others and then finding out why they are different using Excel. That's a skill that will put dinner on the table for the foreseeable future.


Your IT department management should define roles and subject areas. You can be part of a team addressing 1 or more subject areas, then you could focus on those areas. If you define the business to business functions (high-level such as Accounting, Marketing, etc.) and you focus on one of those, then detail the business processes that goes into each of these business areas you can understand the business.

However, this is not a practical way for an individual to cover an entire organization, thus my suggestion to focus on a part of the business.

Once your business areas of interest are defined, you may study the software, the terminology, and the business processes that goes into this area and start going deeper into the details. However, this effort must be organized and coordinated with management otherwise, you will waste your time and other people time for only a small gain.

Also note that it is nice to know, but you must have an objective for acquiring the knowledge. Accordingly set goals of what you have to know and why is it important for you and for the business to spend time on acquiring this knowledge. For example, I would not go to marketing and ask them for hours about how they set up campaigns if I am not going to use this information.

Some companies offer training classes for new business hires. Consider joining one of these courses or using its materials, they are usually focused and short.

Not the answer you're looking for? Browse other questions tagged or ask your own question.