Having worked at various levels in five startups and having observed a great deal more, I've come to believe that there is a very important tension that takes place within startups between idealism and opportunism. How well a company manages this balance is probably one of the single most important controllable factors in their long-term success. At its heart, the idealistic startup company is an idea company. To them it's about turning a certain idea into a reality and convincing people how great that idea is. In an idealistic company there is a lot of talk about the long-term vision and people focus on keeping things clean and simple and true to the core. People tend to think of Google and Apple as having been idealistic startups. An opportunistic startup sees a need and someone who will pay to fill that need and seizes the opportunity. Opportunistic companies focus very closely on what particular customers want; they listen carefully and meet the need as fully as they can. In an opportunistic company you will hear a lot of discussion about deals and how they are coming and what's in the pipeline. An opportunistic company takes the old adage that "a bird in the hand is worth two in the bush" very seriously. People tend to think of Microsoft as having been the iconic opportunistic startup (many years ago).

Developers very often think of idealistic startups as "good" and opportunistic ones as "bad." When I ask developers who have never been a part of a startup company what they think is important they almost always talk first about having a really great idea and building it well. Opportunism is viewed as the domain of the "MBA" startup and hence something to be detested. Interestingly, MBAs frequently give me the exact opposite spin. They point out all the failed startups with great ideas and talk about how important it is to be in the right market and find the ideal opportunity. In this world view, ideas are cheap and excellence is the product of drive, determination and smart business decisions. Successful idea companies are thought of as being successful due to market forces that they were fortunate enough to capitalize on.

The problem is that both these world views are wrong. It is doubtful that Apple or Google were fully idealistic companies, and it is doubtful that Microsoft was fully an opportunistic one. In practice, almost all successful startups find a balance between idealism and opportunism to one degree or another. Companies that are completely idealistic almost always fail, and while extremely opportunistic companies may succeed, that success is frequently either very limited, or it is a success at the expense of others (in which case the people succeeded but not the company).

The biggest strength of an idealistic company is also its biggest weakness. Idea companies Believe. Belief is a powerful motivator, and wanting to make a difference is a laudable goal, but it can lead to pride. When you think you know the truth you listen to people with an ear to convince and not an ear to learn. When you stop listening to your customers with an ear to learn failure is the short step and long drop you are about to take. No idea is perfect, and every idea exists in some real world context. Shortcuts, imperfections, evil-hacks and custom solutions are not uncommon necessities, but to find out when they are needed and when they are not you have to think beyond your own ideas and understand how people can actually put your ideas into practice in a way that works for them (not for you).

Interestingly, opportunistic companies often fail because they don't do enough thinking for the customer. Their product is whatever people want it to be, which is to say that they have no product. Companies like this tend to find their first sale quickly, their second more slowly and their third not at all. Alternatively they end up making product after product and eventually being unable to support any of them. By making the individual customer the center of their universe they can end up solving problems that are not more generally useful to other people or they can bury a good idea in an avalanche of useless complexity.

To create a balance between idealism and opportunism some companies attempt to build high-tension teams. Teams that include opportunistic sales and idealistic product management and development. The idea with this approach is that the two sides will drive towards compromise. This idea makes since at an abstract level but in practice it's virtually impossible to carry out. Sooner or later one of the teams will gain sway and the other team will grouse interminably about the outcome. The "healthy conflict" loses its adjective leaving just "conflict."

The better approach is to understand what kind of company you are and then work harder to have some of the characteristics of the other kind of company. In other words, it's OK to be idealistic, but work extra hard to make sure you are understanding your customers and what opportunities are present to make their lives easier for them. It's OK to be opportunistic, but if you want to do more than bend over every five minutes to pick up another penny, pull your head up and look down the road a bit. Try to see not only what the current opportunity is, but also what the effect will be on your long-term prospects. Idealistic companies should take opportunities that don't seem "just right" to them and opportunistic companies should turn down business that doesn't fit what they are doing very well.

Of course, some startup companies already balance these factors well. These companies exist in a state of idealistic opportunism or perhaps of opportunistic idealism. If you work for a company like that then now might be a good time to buy your vested options!

There are three main theories that I occasionally hear people expound for how to organize developers: 1) organize resources around technology layers, 2) organize resources around business areas, and 3) let everyone do everything. There are a number of fancy names for these approaches but they all escape me now. Actually my mind almost never remembers the names for things; it seems to just hook notions into my brain somewhere and then later when I need to discuss them with people or blog about them I usually have to look them up on the web, but I digress.

The first theory assumes that the complex thing is learning the technology skills and so you need only know about how the UI works or how the database works or how the middle-tier works, etc. You may still need to understand the whole of the business problem, but by having resources dedicated to a technology ring the feeling is that people can be more efficient. It is usually proposed by good business people or bad technologists.

The second approach is the same as the first but with a ninety degree change in orientation. It presumes the complexity lies in the business domain and so resources are aligned along business problem boundaries. For example, some people will be experts on the calendaring components (but be able to work on databases, UIs, APIs, etc.) while others will be experts on the todo list and others on the analytics. It is usually proposed by good technologists or bad business people.

Sometimes these models are combined.  The end result being an extremely high degree of specialization so that resource number 57 (with the arbitrary designation of Hank) works only on UI elements of the calendar component. This hybrid approach is universally proposed by people who work on very large projects and are successful MBA graduates. It is the manufacturing specialization model and can be taken to any arbitrary degree of specificity given enough resources. I remember a friend of mine who was working on a project for the fly-by-wire systems for the Joint Strike Fighter. I asked him what he was working on and he said he just worked on a set of language elements for the simulation language. He had been given the maintenance responsibility for the commands numbered 31-60. Apparently they were considering moving each resource to manage only 29 commands instead of 30 in which case they would move him to manage commands numbered 30-58. I'm pretty sure he was joking but he never cracked a smile.

The last model is that projects should be organized to be simple enough that the resources assigned to them become completely interchangeable. In this model the code is so well factored that anyone can read it and the business problems are so well thought out that anyone can understand them. This model is frequently proposed by really-really smart people, by somewhat less smart people who have never worked on large projects, by escaped sixties radicals and by my Uncle Sid in Chattanooga who just bought a Commodore 64 off EBay so that he could "do some larnin bout them thar computer things."

I actually have a fourth theory. My theory is that software isn't written by resources it's written by people, and people are a lot more different than these theories would have you believe. My theory is that you figure out what people are good at, what they WANT to be good at, and what they CAN be good at, blend it all together along with three tablespoons of information about people's personal lives, a massive grain of salt about the future project requirements, as much tortured brain extract as you can squeeze out of your ears, and a dose of informed opinion from your best friend down the street. This mixture should be beaten thoroughly every three to four days until a smooth and even consistency is achieved at which time more people can be added to the mix. Oh, wait; somehow I've confused my instructions for team management with a recipe for fudge brownies. Anyway, the point is that while these theories may make nice diagrams that impress your boss they should never be confused with reality.

Here are some examples of the KINDS of things that you might find yourself doing when working with people instead of resources:

It turns out that when Marty is given a new piece of code to write he bogs down and it takes forever, but he can refactor code like there is no tomorrow so you have Susan (who can blast out a working prototype faster than a Volkswagen Beetle with a five-hundred-horsepower engine but can never bring a project to actual closure) whip out a roughly working prototype and then ask Marty to turn it into a well polished gem.

You might ask people what they want to work on. Then when no one in the company is willing to sign up for the Wandering Whistle widget you can take that as a bad sign for that widget and spend a little bit of work determining that if you give Methuselah an extra week for refactoring he would be willing to bring the widget back from the depths of hell where it seems to have found itself.

Sasha is the expert on the build tool but she's getting sick of spending time working on it and can't come up with a good way to hand it off (maybe it's too complicated), so you have Frederick (who seems to have a knack for making things easy to use) work with her to change it so that it no longer needs an expert to work on it.

Anyway, these are the kinds of things that you do when you have people on your projects instead of resources. Of course, you actually do need to divide up tasks and build separate teams and all of these things, but when you do it's best if you leave your engineering hat at the door and put on your people-first button and attend the party as a friend of those that work for you rather than someone who views people as cogs in the wheel.