[David Strom's Web Informant] March 1, 2012: What Kind of Software Company Should You Work For

David Strom david at strom.com
Thu Mar 1 09:42:33 EST 2012

Web Informant, March 1, 2012: What Kind of Software Company Should You Work For?

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.
Griess told me there is another reason too: "You can go really deep on
a specific project. Not all projects lend themselves to rapid
iteration: those with deep technical challenges often require a fair
amount of thought and supporting infrastructure (which often must be
built specially) before they will work at all."

-- 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.

More information about the WebInformant mailing list