Should I be involved in my project's business side?

Question

Before my current job, I was always involved in the technical aspects of a project like:

• architecture
• design
• performance
• security
• etc

Now I'm team lead of a project that's a game on a web site (not mine) and somehow got involved in the business side of the project:

• what users expect
• ads showing in which pages of the site
• mechanics of the game
• etc

But I quite don't agree with business people's (customer or product owner if you like) decisions of the directions of the site. Of course I raise my concerns, some of them are taken into account, most of them aren't.

I continue my work as usual as I like working here but I feel like the product would be better than what it is now. I think that's because my goal is to make an interesting and challenging game, and theirs is to attract as many people and earn money as possible (it's a paid game). Have you guys ever happened to be in this kind of situation? What are your experiences?

Answer 1

In many projects getting involved in the business side of things is not only inevitable, but good. If you understand the owner's reasons for wanting things you can better react to/suggest/repair/anticipate features you need to work on.

Specifically to your final question: I have, and most of the time you loose more of these than you win until you start to get some positive history on being right with your suggestions.

One thing that sometimes has helped me is to make a demo with things my way and show it to the users as an alternative or conversely make a demo of enough of their way to point out the problems.

In most enterprise situations it is your job to bring the things up, but ultimately their decision if they think that their crazy is better.

When they choose the crazy the best thing you can do is make certain you have a clear exit strategy back to sane worked out when they realize their error.

If the crazy starts to get the better of you consider a different employer...

Answer 2

Yes I have, in many companies I worked for. And I always lost to the business people; they have a higher rank in software companies anyway.

Curiously, making your product more interesting and more enjoyable for your users is the whole point of business: the more enjoyable, the more money, as a rule. On the other hand making money by not making your product better, more often than not means unethical business, which works in the short term and certainly fails in the long run.

In fact, you may be wrong and they may be right on some, or most, or all of the issues you disagree on, but anyway: start your own startup and end this frustration.

Answer 3

In my experience, having a tech person on the business side of things can really be helpful to a company IF, and this is an important "if", the tech person takes the time to speak the business people's language.

Yes, technical awesomeness sometimes has to compromise with UX. If you want users' money, you have to give them something they value.

It must sometimes compromise with business factors. Uber-database-awesomeness may make the DB better or performance a bit better, but if licensing it costs more than the company has it can't be implemented.

However, if the technical awesomeness ever compromises (as it so often does) to the nontechnical leadership's lack of understanding, THEN you have a problem. Either the business leadership isn't listening (in which case, find a new job), or you aren't doing your job -- part of which is learning to put your expertise into words that they can understand.

Answer 4

I think you only need to (and arguably only should) be familiar enough with the business side to be able to get into the business user's head. What you're experiencing isn't necessarily any fundamental difference between code and product. It's a matter of varying objectives.

Business people generally have the objective of building a product that people want. Technies have the objective of building maintainable, non-buggy code that can scale with the company.

In other words, business types will scoff at technical requirements because that's their job. They don't get paid to make sure good code gets written. They get paid to build a cool product. You, on the other hand, aren't paid to create a cool product. You're paid to ensure good code gets written.

My advice is to take a note from the business people. You need to focus on doing your job correctly. If you cut corners and put out a buggy product to suit them, you're going to get the blame. In fact, I'd argue that you deserve the blame. It's your job to stick up for technical requirements.

Now, it's tempting to blame the business people for not listening to you. They are treating you unfairly, but that's not really the point. The point is how you react to that situation. Let me share a secret of working for software companies with you: the code is the product. That might sound obvious, but we forget it so many times. Thus, the key is to realize that you're helping business people to make a better product. Once you realize that, it becomes easy to phrase things in their terms: "We can do that, but it will make a buggy product that no one will buy," or "We can do that, but it will jeopardize our ability to put products out faster in the future".

I'm not suggesting that bad work environments where you can never get the business people to listen to you don't exist. I'm suggesting that the way to handle this situation is to stick to your guns while realizing that the other side has differing goals from you. The correct way to handle it is to find a solution that benefits both sides.

Answer 5

If you aren't involved in the business side, you're doing only what other people tell you to. If you are, then you have at least some slight influence on the project requirements.

You really should have some idea of how what you do fits into your business (and your client's business, if you're doing software for a client), if you want to make intelligent suggestions. If you are perceived as making impractical suggestions, you'll just have more trouble getting any practical ones accepted. Some people have the social skills to deal with that situation, but the typical techie, the one most likely to have this problem, almost certainly doesn't.

It also depends on what you want to do with your career. If you want to develop software for the rest of your life, that's cool. It's what I like. If you ever want to move into management, including software management, you will have to understand the business.

Answer 6

In the distant past I worked at a game company. They had all the clever technology to develop something with the mass market appeal of Quake (and ahead of that product being released) but due to a lack of any marketing input/control chose to develop the kind of game the developers wanted to play; a geektastic extravaganza with a convoluted literary plot and where almost every key (ok, exaggeration) on the keyboard did something. The game was well received critically and is now generally regarded as a classic; the creating team can certainly be applauded for remaining true to their vision... but they never managed to create the blockbuster game the company actually really needed to indulge this sort of "artistic integrity" project (they're not around any more).

I've worked for other "better mousetrap" companies too (hint: the world doesn't need a better mousetrap) which thought they could prevail in the market by superior technology and development skills alone. None of them have succeeded with what they were trying to do (not with their original idea, anyway). Believe me: listen to and respect your marketing people (the good, experienced ones at least), and they'll listen to and respect you.