I met Peter Griess last night and heard him talk about his career. Even though he still has plenty of years ahead of him, he has already worked for NetApp, Yahoo, and now Facebook.

He was part of a nine-person startup that worked on some interesting social email apps that eventually got acquired by Yahoo. Along his career he has seen very different kinds of cultures in these various software engineering departments, and as I was listening to his talk, I thought about the many software companies that I have covered over the years.

I would break them down into three different kinds of cultures (the names are my own construct):

• Mature Turtles. Until the Internets came along; this was your typical enterprise software company, such as IBM, Microsoft, Sun/Oracle and others. It was a slow adopter, came out with new releases once a year or so, after careful testing and lots of quality control. The company would have extended maintenance windows of several years, because customers would latch on to one release and stick with it, without upgrading because they were fearful that changes would break something that was mission-critical. Developers had firm specs before they wrote any code, and took that code through a lengthy dev/test process before it ever left the premises. There is a hierarchy of engineers and different silos depending on which pieces of the code you are working on, and usually you can’t cross over easily from one silo to another. Customers often had to wait months to see their suggestions make it into a code base.Why work for them: Not all departments are as evil as others. For example, being a data scientist at IBM right now is probably one of the best gigs going. If you can deal with the silos and the hierarchies, then this is a good place to learn some solid skills.
• Middle Earth.This is the type of company that was founded in the early Internet era, say the late 1990s. They want to be a changeling but are stuck in the slow-moving past. Yahoo and Cisco are good examples, but there are lots of others. They have large and mature markets but don’t know what to do with them. They have oddball product strategies and conflicting products that segment their own focus and split their development teams’ attention. Silos are still ever-present, and accentuated by frequent acquisitions that were never really absorbed into the corporate mainstream culture. They have legacy products and users who are reluctant to move off of them.Why work for them: If you want to get experience with an international company and find out how to support legacy products, these guys are the places to be. If you want lots of exposure to mergers and acquisitions, they have the cash. If you want your own office and peace and quiet while you code, this is the place for you.
• Internet Chameleon. This is the type of online software vendor that we are used to these days, such as Facebook, Google, Twitter and others. They move quickly and tend to break things as they add code on the fly. They get the cloud or are wholly based on it. They are using agile coding techniques and everyone is sitting in bullpens often at close quarters. Releases happen daily, if not more frequently, and get pushed out to real users, often to their dismay and frustration when they find something that is broken. There is a development culture where any engineer can add code anywhere: silos are gone and forgotten about. Features get added, morphed, or cannibalized whenever and wherever. These companies are controlled chaos sometimes. Gone also is the whole QA department: if you want to test something, roll it out to a small subset of the active population or try your code out on some internal staffers. Of course, it helps to have a level of trust with your end users so that you don’t lose them in the process of making these enhancements.Why work for them: Obviously, most of you are probably focused on this type of company right now, or want to start one yourself. But you have to have the fortitude to roll with the punches and be able to adapt to the constant flux of changes.

I’d love to hear from you about your own experiences in different engineering departments, and if you think there are subspecies to the three that I mentioned.