The last few years I have worked at a very large hardware/software company. First time working at the very large company since working at Burroughs in the early 1980’s (then the second largest computer company on the planet). The years between I worked at a number of small to mid-sized outfits.
There is something odd about working at a big company, or more exactly, the folk in the company.
Admittedly my experience is limited. Perhaps other big software companies are different.
Burroughs was a very successful outfit in the process of imploding. Did not know that at the time. (Revenue grew strongly the years I was there, then reversed after I left.) As the second job in my profession, I had no basis to judge. Seems the problem was most projects, after much development, were cancelled before going to customers. So customers saw very little progress from a once highly innovative vendor. Odd management.
Now I work for a very successful company whose offerings are (mainly) various themes around storage.
The company seems to have a very effective Sales organization. After they buy a small company (thus acquiring a new product) the years after see massive sales, far in excess of what the acquired company managed on their own. As a software developer, I do not really understand Sales. Clearly this company’s Sales folk are effective.
The company seems to have a very effective Support organization. Customers do a lot of repeat business. Surveys reflect high levels of customer satisfaction. (I do understand support a bit better, as at small companies I had a lot of contact with customers.) Clearly the company is doing something right.
Somehow I cannot quite get my mind around the behaviors of the company Development groups.
The company is highly profitable, and the development groups are quite large. There is a lot going on … but with so many folk, somehow less gets developed than I would expect. Seems the company acquires major new products mostly by buying other companies. (And then as noted above, sell and support the product very well.)
One recent acquisition was a company with a new all-flash storage array. I would have expected the company - with a long history and whose primary products were disk-based storage - to have developed such a product in-house. Sure, the algorithms are a bit different, so the software design needs to be a bit different, but … there is a lot of commonality. Why did in-house development not happen?
While I know very little of the other development groups in the company, my time with the local group may provide clues.
There were quite a number of puzzling moments.
Early on, the manager for a prior project talked about “staffing up” the project. I was puzzled. By my estimate the first version of the product should take less than a year, and could be handled by the three folk then in the group. In fact, I could likely build the first iteration on my own in that time, if I were willing to make that my entire life (with the freedom to ruthlessly prioritize).
Though as I did not have experience building a larger software group, I thought perhaps he was right.
During the design and early development phase, the project architect seemed far too eager to add complexity, and to introduce dependencies on other in-development projects. Seemed to me like a lot of added risk, and much that should not be in a first version. (Once a product goes to customers, you learn a lot about what they actually need. Better to go to customers early, so you do not spend time on unneeded features, and learn what you have missed.)
But the architect and manager were both very experienced folk. Perhaps they could manage the risk better than I thought possible. Perhaps development at a large successful company requires a fatter first version than I expected.
As it turned out, the project shipped after three years, required about twenty folk all told, and … seems to have missed the market. The added complexity and risk all cost time and headcount pretty much as I had expected.
At one point I thought the actions taken by the architect and manager could be explained if the primary aim was building the largest possible development group. Building a product and serving customers were almost non-goals. This seemed excessively cynical, to my mind.
Much later, in a meeting the architect proposed an absurd project, entirely on the basis that funding was available, and a large development group would be required. Suddenly the prior interpretation seemed more likely.
Listening to the folk around me … they are different.