First Post!

Every blog has to have a first post, and this one is no different.  This blog is about herding cats -- also known as "managing the engineering process".

Let me give you a little background on where I'm coming from...

I've been a software engineer for over 15 years now, and in that time I've worked for about 20+ companies.  Not as a contractor or a consultant, but a regular W-2 employee.  The first question you're going to ask, I already know, because I hear it every time I talk to someone about a new job lately...  "Why?  What's wrong with you that you can't stay anywhere?"

The answer tends to be:  bad management.  There have been a few places I've stuck it out for several years, and when I look back and think about what kept me there so long, I can come up with a number of different factors, but the one that plays the largest is that I was in a position to manage the engineering process, and work with people across the board.

I blame early success.  I signed up with a dot-com startup called ONElist back in 1999, a small team, about 20 people when I started, and a year later, we'd merged with our biggest competitor and were then snapped up by Yahoo for half a billion.  A lot of those early guys made millions of dollars in that deal.  I would've had a nice drop of cash, too, if I'd sold it all before Yahoo's stock tanked a month later.  But that got me hooked on startups.  It made me want to get in as early as possible.

I bounced a few places right after that (working for large companies after an acquisition has not really worked out well for me thus far) and I ended up at IronPort.  Very quickly, I was nominated architect, and it was good.  Really bright guys, decent process already in place (still waterfall, but this was in 2002, and nobody's heard of "agile" yet), but I found I was doing a lot more management than development.  I was working with the product management team to help crystalize ideas, help prioritize projects, estimate delivery dates, and then working with the engineering team to distribute the work, track progress.  I was running bug triages, bringing product, engineering, and QA heads together so we could collaboratively identify where things were going well, where things were going wrong, and making sure everyone knew what the impact of decisions were.

I should've stayed.

Instead, I got swayed by the opportunity to be the first paid engineer at a startup, and I jumped ship.  The startup was snapped up in a small acquisition just six months later, which was great, but my equity wasn't all that much to begin with, and once again, I found myself miserable in a large corporate environment.

After that, I went into a bit of a decline.  I bounced from startup to startup, looking for satisfying work but always coming up short.  In cases where I came in as "the first engineer", I'd often find myself being treated as a contract developer, not as a business partner.  Or in cases where I came in as "tech lead" with promises of management, I'd be told later on that they didn't want to "lose my technical abilities by making me a manager".  Lots of unkept promises.

I did become CTO for a startup founded by a friend and previous coworker of mine, and that was a terrific experience.  I actually got to manage two developers (albeit remotely), and I realized that was where I derived the most satisfaction -- being able to herd the cats and generate terrific results along the way.

That's when I realized, starting my own company, or being in really early, isn't really what it's all about.  What it's all about is being able to manage the process, manage the people, and get the best results possible from all the talent you already have available to you.

This blog is about what I've learned, and what I'm continuing to learn, about herding startup cats.