Through the years, a fair amount of my projects have been with small companies and startups. One thing I notice almost universally, is that members of smaller teams tend to have hunger for success, and a real feeling of ownership over their product. They take personal pride and consider themselves invested in the project.
That tends to change as the team size grows, for better and worse. On one hand, relying on “heroes” can be a dangerous thing, and people need to learn to pace themselves out. So a maturing and growing team can be a step in the right direction. On the other hand, it’s hard to see that desire for success and personal sense of pride in a product die off.
Everyone who has seen a big struggling project knows that feeling. “The wheels of bureaucracy are turning, and all I can do is what the product owner has asked of my piece. Suggesting improvements is just going to cause argument. And besides, why stick my neck out and risk being listed as one of the causes for project failure?” Also, there is a big difference between the amount of responsibility you feel when you are part of a successful team of 10, compared to a successful team of 100 or more. And projects of that size face unrealistic expectations and rarely feel successful.
How do you change this?
Maybe you don’t. I was once part of a startup, the 3rd man in. There was the founder (with a marketing background), a designer / developer, and I joined to help with the the rest of developing. The feeling of pressure and control that we all had on that project is something I’ve almost never felt on larger teams.
However, there’s no need to throw in the proverbial towel. There are techniques to strike a balance. Agile methodologies usually push for smaller teams and more distributed responsibility. And products can be broken into smaller pieces using a module or a SOA approach. (Yes, putting SOA into an agile approach is a challenge, and possibly a contradiction).
In the context of your business and its goals, you have to find the balance. All aspects of the business can be controlled and dictated from the top, but your subordinates aren’t going to innovate and grow organically, and they are only going to work extra hours if you force them. For a mature business with stable returns, that model probably fits. But in industries that face a lot of change and require innovation, you probably need to risk the destabilization of delegating out large amounts of responsibility to small teams. You will have less consistent results, but they will hit some homeruns.
I think Microsoft has seen this in recent years. It’s a common complaint that the teams don’t coordinate and share information there, but they have developed some interesting products. Their having been more surprises than there were under the old centralized management of the Gates’ days. Look at products like ASP.Net MVC, Win Phone 7, Windows 8, WebMatrix and Azure. Not the most integrated products, and some are not commercially successful yet (WP7), but they were more surprising and interesting than a lot of prior products.
The real outlier is Apple. Steve Jobs flew in the face of everything I just described. He notoriously kept the decision making power to himself, yet left Apple workers with a feeling of investment and devotion to the company. Even the customers feel invested. I can’t imagine a Windows sticker on the car of a person whose pay isn’t from or closely related to Microsoft, but I see a lot of cars with apple stickers in the back window.
So as a business grows, you can either try to keep the teams small and empower them to feel invested, or find the next Steve Jobs. Best of luck if you chose the former. Sometimes growth is the mistake. There are industries (like service / partner type models) where growth can risk lowering the profit share per owner / partner / investor. See Managing the Professional Service Firm for more on that risk.
What do you think? What has your experience been? Comment below.