Steve Jackson: Lead with Passion

guest post[Note from Daniel: This guest post, from my friend Steve Tolman, is part of an occasional series about important career role models. I also worked with Steve Jackson, and I agree with Tolman that his energy and dedication instilled many great skills in those who worked on his teams.]

While I worked at PowerQuest, and Symantec after its acquisition of PowerQuest, I worked with a man named Steve Jackson.  He started somewhere around 1999 or 2000.  In our organization we had about seven or 8 Steves so we all went by our last names.  I was simply, “Tolman” and he was “Jackson.”

Jackson was the director and VP of all software engineering.  He was my manager and quickly became my friend.  He took his job very seriously and I learned a great deal from him.

By the time I left the team in 2008, I had learned how to run a team, how to build and release software, and how to work well with people.  One of my peers, Lane Johnson (one of the best managers I have ever known, who left the team at the same time) asked me what it was that made Jackson so dang good.  We thought about it for a while and concluded that there was not that proverbial one-thing-you-need-to-know that made him great, but more along the lines of about a bazillion qualities.  A little time brainstorming gave us a list of 45 different skills, techniques, or approaches.  Here are just a few of the highlights.

Believe in the individual

Jackson’s default mode was to trust people.  Trust them to fit into the team and trust them to do their job, but expect them to do a stand-up job for you.  Get the right people on the bus (read the book Good to Great for more info), give them an assignment, then get the heck out of their way and let them shine.  Continue reading

Roland Whatcott: Manage momentum.

(A post in my “Role Models” series…)

In late 2000, I joined a small team tasked with rewriting the core technology at PowerQuest. The old codebase–despite embodying a number of patent-pending concepts, and serving as the foundation for all our revenue–was fragile, rife with technical debt, and unfriendly to localization, new platforms, and other roadmap priorities.

Building our new engine wasn’t exactly rocket science, but we expected our output to be cool and generate lots of thrust. We took our work as seriously as NASA… Photo Credit: Wikimedia Commons

This rewrite had been attempted before–more than once, by some of the brightest engineers I’ve ever worked with. Each time, the press of looming releases, and the lack of obvious progress, culminated in a “we’ll have to come back to this later” decision.

Our little team was confident that This Would Not Happen To Us. We were going to build an engine that was cross-platform from the ground up. No weird dependencies, no assumptions about compiler quirks or endianness, would permeate the code. Internationalization (i18n) and localization (l10n) support would be baked in. Errors would be clearer. Modules would be small, beautiful, and loosely coupled. Gotos would disappear. Vestiges of C dialect would be replaced by best-practice STL, boost, metaprogramming, and other cutting-edge C++ ideas.

Experience Versus Enthusiasm

Before I tell the rest of the story, make a prediction. Do you think we crashed and burned, muddled through, or succeeded wildly?

How you answer will say a lot about you.

If you’re young and optimistic, you may expect me to tell a story with a happy ending. But if you’re an industry veteran, you probably expect I’m going to tell a cautionary tale framed by failure. You know that rewriting a core technology from scratch almost never succeeds, and you can give a dozen excellent reasons why that’s the case.

If you’ve got Roland Whatcott’s genius, you can imagine either outcome — and more importantly, you know how you can choose the future you want.

Continue reading