Business knowledge in a large financial org?

Question

As a programmer working in the finance industry, I recently got a project that is a hedge fund adminsitrative application(used to calculate NAVs, allocate assets etc.) From a business point of view this is a good thing.

When we think of our 'next' project, typically the impulse is to think in terms of technology. e.g: 'I want to work on a project that uses SOA/cloud etc etc.' I am interested to know if anyone while career planning also takes into account the business aspect of a future project. i.e. what the application does. So does anybody ever think like this : 'I wish to work on a trading system so I can understand capital markets better.' instead of 'I want to work on a project that uses SOA/cloud etc etc.'

I say this because it appears to me in the finance domain, for senior position, good business knowledge pays well. So maybe a guy that knows more business but maybe not so much latest technologies is at an advantage? The rockstar programmer seems more suited for an aggressive startup. Particularly big old finance orgs rarely invest in tech just for the 'cool factor'.

No?

Answer 1

You should be serious about domain/business knowledge if you want to do any good thing in environment you described. The Programs we generally write classify into following categories.

1. General programs related to sorting searching or some times abstracted to the level of solving some kind of puzzles. They generally specify the problem statement in the form of manipulating data of some form to some form. This sort of programming doesn't actually focus much on business end of things. But these sort of programs focus other important things like for example, checking if a person can solve a problem and think analytically and write a program to solve it. Solving such problems generally requires understanding of some basic concepts of sorting, searching, organizing information and then presenting.

2. Programs that fall in between, things like middle wares, compilers and other tools like IDE's all fall into this category. These sort of problems focus on enabling things at the either end to glue them together properly. Here you need to understand application level problems and logic. For example you may need to understand how to optimize a caching application to work faster if only text data is being cached. This requires problem solving and programming skills too, but they are abstracted a level higher.

3. Programs that interact with end uses and get their job done. This is where you are. In order to provide good software to users, you will have to understand what their needs are. How they work? Their workflow? Issues they commonly face and then try to model them in the program/software world and solve them. These sort of problems involve understanding of the user end of things(What problems you trying to solve) and programming end of things(How well you can solve them).

I think your case fits into the third category. Don't go overboard and try to become total expert in that domain. You must understand as much as you must understand to solve a particular problem. In other words you must be clear about the problem statement and data at hand. It will better if you don't gradually transform you into a bad business guy while you could have been a good technical guy.

Answer 2

For sure, this is my main consideration when taking projects.

Not necessarily specialization in my case. I've worked with computational materials science, remote sensing, BI and finance. I like to have a chance to learn new things and grow. I'm now specializing a little, probably because I now have a few years of experience and I'm starting to have more defined opinions on what kind of software I like to work with.

I'm somewhat agnostic when it comes for technology choices - along it works and doesn't put the project in risk I'll use it. I try to keep up with new things like Diamond on Maglev or wherever. But most of the time I'll stick with wherever works.

If your thing is finance you might want to look at this question that I previously asked. There's a few pointers to books about quantitative finance and it might interest you.

Even for startups, domain knowledge is critical, IMHO.

Answer 3

Think about how you would feel about the company building your house if the builders said "I want to work on a project where I'm nailing pine boards together instead of oak boards" or "I want to work with Craftsman hammers not Home Depot hammers"

Wouldn't you rather want to hear "I want to work on building houses that are high-quality, use green technologies, and are energy efficient."?

My analogies may be a little weak because I'm not a carpenter, but your customers are interested in results, not what technologies you get to play with. You need to remember that you're being paid to build software that speaks to your customers and solves their problems, and these problems can't always be solved by only knowing that Hashtables are thread-safe and HashMaps are not.

To build something for your customers, you not only need to know how to drive nails into wood, but you need to know how to do it in a way that solves a real-world problem, such as putting a stable roof over someone's head, not just randomly nailing pieces of wood together :)

Answer 4

Used to work in a similar environment, writing software for financial market data analysis.

Without some knowledge about the business (which deepened over time) it would have been impossible to find many of the more subtle (and some of the more blatant) functional problems with the software, like a trend which goes down looking at the numbers but the software generated a trend curving up looking at its charts. Knowledge of statistics and mathematics also helped. It helped us find fundamental flaws in one of the algorithms we were told to code by an analyst for example.

Without such domain knowledge, we'd have ended up creating (at considerable cost) a piece of software so fundamentally flawed that, had it gotten past the test department (who themselves require domain knowledge to analyse the test results) could have ended up costing our customers tens of millions of dollars a day. You can I guess estimate the lawsuits our company'd have to face had that happened.