It's fascinating that the biggest problem is bureaucracy. I don't think the big companies are aware that it's such a big problem. When organizations institute bureaucratic rules, it's always to avoid problems-- e.g. duplication of effort. They never seem to consider the cost of the rules, only the cost of not having them. But this shows how high the cost is. If you're too bureaucratic, it doesn't just make people demoralized or unproductive. It makes them not want to work for you at all. Which means you're not even measuring the cost of such rules accurately; you're only measuring the effect on the people they don't cause to opt out of your sample.
During my last earn-out, after the honeymoon period, the bureaucracy piled up very quickly. To take an extreme example we hired a rather insecure engineer who proclaimed himself a "UDP expert", and successfully petitioned management to put in place a rule that anyone wishing to implement even the simplest piece of UDP code must talk to this guy before every commit for his stamp of approval (the result being that the rest of us tended to stick with TCP even when UDP might have been a better choice).
My first day at justin.tv was quite a contrast. Justin and Emmett pretty much just said "go implement a very scalable chat system - the one we have right now is breaking. And try not to interrupt anyone if you can, we're all very busy". That was quite a breath of fresh air.
I think that many big companies are aware that bureaucracy is a problem, they're just not aware how big a problem it is at their company. Everyone knows that bureaucracy is bad, but if you ask a decision-maker at a big company what steps specifically they could take to reduce bureaucracy, you'll probably draw a blank.
A lot of this, I think, is because of a meta-problem. Bureaucracy is basically a restriction in information flow within the organization: at some point a while ago, the right information didn't reach the right people, and so the organization instituted procedures and rules you have to follow to prevent the problem from occurring again. But over time, information flow adapts to follow the rules instead of the shortest path from A to Z. And that prevents the people in charge from ever knowing that there's a problem. After all, the bureaucracy developed because there was too much information to fit into any one person's head, and then if they wanted to reform it, the only thing they can see is the path that information and decisions currently takes.
It's like Dunning-Kruger for organizations.
This'd explain why bureaucracy only seems to grow, never shrink, despite the best efforts to reduce bureaucracy. It also makes me a little pesssimistic about the long-term survival of any one institution, and optimistic about the long-term need for startups. It seems like organizations are like Microsoft operating systems: they need to be periodically rebooted to function effectively.
It's far easier to be the person writing and enforcing policies and procedures than it is to be the one who must accomplish something within the bounds of all of those policies.
At the last startup I worked for, management loved to hire heavy-hitters from big companies. Almost universally, they spent more time writing proposals, calling meetings, soliciting approvals, and gathering input than they did working on actual solutions. Not surprisingly, they accomplished very little and had a hard time keeping up with the demanding schedules of a startup.
Within a big company, it would be easy to mistake all of this bureaucratic churn and superfluous paperwork for progress and hard work. In a startup, it becomes obvious to all that it is anything but progress.
This is definitely one of the things we're trying to fix with Rahfeedback.com - we imagine the world a far more transparent meritocracy than is currently the case.
An example of rules and unwanted outcomes. I once wrote an application at a big company, which had a strict application packaging process, for remotely installing apps on machines. A last minute change was requested, which resulted in a small error being made in the 'tab order' of the screen. It would have taken one compile and 20 seconds to fix, but because the rules said the executable couldn't be updated once packaged, it remained so. 7 years down the track, the same application was still being used, and the users of said app had to skip using the tab key to get around fields and instead mouse backwards. 7 years of aggravation and frustration on the part of users which could have been avoided with 20 seconds worth of rule breaking. I'm aware of what those rules are for, but having a structure so fixed that it causes this type of inefficiency is frustrating to all involved. It's not like anyone benefited from following the rules, save for the guy who could honestly say to his boss 'I made them follow every last rule'.
Ahaha, this is like what happens in my company. They allow you to create packages right up until version 1.0, and then after that you have to create awkward 'patches'. The problem is that they force you to call something version 1.0 due to politics alone.
BTW, if you have a range of answers, map it onto range of colors. Don't use blue for no, red for weak yes, and purple for strong yes, because chromatically purple is between blue and red.
I needed to solve this problem about 12 years ago:
Digging through the scraps of Fortran available on then-much-younger Internet (I may have even resorted to the university library!), I discovered that a standard trick for coloring 1-dimensional data onto a (Red, Green, Blue) color space is to start in ([H]ue, [S]aturation, [V]alue) space, map your data into the H dimension (holding S and V constant), and then transform that into RGB.
I have absolutely no expertise in this field at all, but that Worked For Me (and does indeed place purple between blue and red).
Maybe I misunderstand you, but I think the point was it would be easier to understand if there was less contrast between adjacent answer groups. Strong Yes should be distinct but similar to Yes, which should be distinct but similar to Neutral, and so on. A stepped gradation between two colors works, or even just tints and tones of the same color.
Also, just another minor quibble, could the bars be sorted by some weighted score? So the statements they most agree with pile up on one side. Or, perhaps score by strength of feeling in either direction, so the "important" factors line up on one side.
To some extent it's the natural consequences of shifting priorities. Once there's reliable revenue, part of the objective of the company becomes minimizing the downside risk. With a small company before profitability there is no downside risk. There's literally nothing to lose.
Some amount of innovation eventually becomes worth sacrificing in order to not "fuck things up."
Growing up in Greece, I was more afraid of bureaucracy than of death. Bureaucracy (and some corruption that went with it) drove many scientists out of the country. I believe it is incredibly difficult to eliminate this beast once it has infested an organization, because people don't appear to be as creative in eliminating rules as they are in setting them. I'm glad to see a positive outcome of the bureaucracy problem: it drives the best people to start their own shop.
The problem is that for a lot of big companies, their brand is worth an order of magnitude more than the actual work that gets done by the employees. And the cost of paying lots of people to do nothing is trivial compared to the risk of destroying your brand, especially if you can find some way to cheat your employees out of health care and pension.
Maybe these two things are related, but having just given my notice at a big corporate software company my experience is a bit different; It wasn't the bureaucracy that drove me away it was the mediocrity.
Day by day, I saw us doing things to account for the fact that we had a lot of mediocre developers working there. Worse yet, I felt myself sliding into mediocrity as well.
Perhaps it's a cycle. Once a dev team grows over a certain size you are guaranteed to have 25% of your dev staff being under performers and you start to come up with bureaucracy to account for that. The bureaucracy causes some of your A players to leave. You replace them with more mediocrity requiring even more bureaucracy causing even more of your A players to leave...and then one day you wake up and realize that you've spent 6 billion dollars and released vista on an unsuspecting public.
I'm sure big software companies are good at something, but I no longer care to find out what it is. I'm done with bureaucracy and the mediocrity...as soon as I finish this exit paperwork.
In this study, we had people from a variety of departments in companies respond. Not all departments are created equally; some are more progressive and creative than others. Unfortunately bureaucracy still seeps in--no matter the special rules you put in place or physical distance you add between groups.
I worked at an incredibly progressive group inside T-Mobile, and although my team was able to accomplish a great deal internally, the infrastructure around us stunted our productivity. This frustration ultimately led me to leave T-Mobile to start rahfeedback.com
They never seem to consider the cost of the rules, only the cost of not having them.
The problem is big companies have cost/overhead regardless. You can engineer for super-efficient (no duplication) and you end up with a ton of red tape.
You can engineer for no rules and you (probably) will end up with duplication, difficulty in keeping to corporate-wide strategic goals, etc.
Bottom line: big companies are inefficient beasts. But successful ones have profits that negate the inefficiencies and allow them to work on the type of projects and solve the type of problems a startup can't.
From what I understand, this seems to be a bigger problem in European countries (government/regulation included).
The cost of forming a German equivalent LLC is about 27,000EUR after legal fees, and take about a week to complete.
I heard a similar story from a friend who used to work at a German bank (a regional one). She mentioned that four or five copies of almost every single paper had to be made, with a copy going into a separate individuals inbox (a physical in-box).
Now she works for an IT startup in Alaska... You can imagine that she really appreciates the difference!
As someone who went through the acquisition of a software startup, the year in golden chains, and who is now working 12+ hours a day at a software startup again my biggest problem with working at the "big" (in mentality and geography if not employees or success) company was that it atrophied my skills. This is of course ultimately my fault for not working harder to improve myself during that time, but I certainly at the time got dragged under the water by all the wrong incentives.
Standing out enough to get recognition, compensation and other perks required a minimum of legitimate technical innovation and rewarded all the wrong kinds of effort, mostly political maneuvering and the cultivation of a swaggering, executive demeanor that I really hated about myself. Now that I'm back to being judged by my (esteemed) peers on the basis of my direct work product, I'm learning at a crazy pace and enjoying life more even though I'm tired from the long hours.
Startups may not be for everyone, but they are for me, and that would likely be the case even without the possibility of an exit payday.
Interesting. A couple of follow-ups, if you don't mind:
Where did the acquisition lie on the talent-/product-acquisition spectrum?
Also, how did those perverse incentives seep into the former start-up's culture? Was it a result of working closely with people already at the acquiring company who bought into the system? Were the executives at the acquiring company directly to blame? Or something else?
The acquisition was done for a number of reasons, but most paled in comparison to obtaining a particular piece of software (web browser and JS VM for tiny feature phones) and the team who wrote it (and went on to maintain and extend it). In addition a couple of the founders of the startup went on to be important members of the management team at the new company, so I guess both.
The folks who came from the startup got scattered into every corner of the new company both organizationally and in some cases even geographically and as a result the values of the startup just sort of diffused into the larger company and when we wanted advancement we quickly learned to play by the new rules. At least I did.
Having been through that with you (different company which was acquired by the same company) I wholly agree with you. Way too much focus on being a politician instead of really focussing on getting ahead.
Not a YC founder, but I was the first employee at a startup that was acquired by MSFT in late 2001.
The founders and I were college friends and we were all quite green, having graduated in 1999. As a result, I had a ton to learn. For the first three years, Microsoft was a fantastic engineering training ground. I worked with, and learned from, truly brilliant engineers and architects.
The _next_ three years at Microsoft taught me how not to design management hierarchies, how not to determine customer needs, and how not to structure incentives for individuals and teams in large organizations.
I'm no longer with Microsoft, and I'm quite excited about my current work, though leaving was a difficult decision given how great my co-workers were.
It seems the really sad fact is that a ton of middle managers make a handful of mistakes. We're really hoping to be able to level that field through education as well as giving clearly smart employees, such as yourself, the ability to drive change from within.
It's interesting to me that so many people in the startup community hate the bureaucracy and overall attitudes in big companies, yet for quite a lot of people, the high-paying exit is the ideal fate for their startups. Exits normally involve one of these big, bureaucratic companies swallowing your company whole.
The exit allows you to eventually start a new startup and go through it all again, an IPO/ continuing private business means that your doing the same thing for a long time and may eventually become big company you were trying to escape from initially.
I guess that would be an interesting question to pose, if your startup continued to grow would you wlecome the challenge of expanding it to more of a big company or would you prefer to jump off and do something small again?
Tony Wright is a good example, leaving rescuetime to jump back into something new now that rescuetime has become a more stable, growing company.
I guess they call it bitter sweet =). Of the respondents there were only a few that had been through an acquisition; had there been more we'd have been able to draw more conclusions. From a personal point of view (heysan (YC) acquired in '09) - you're 100% right, we got our exit at the expense of some of our humanity.
The most striking point was obviously bureaucracy. I wonder what the reaction this would get if it was company specific and included only people who had left the company.
