Steve Todd recently wrote about the experience of building EMC Navisphere from the ground up. His discussions of the Connect Library and the Factory Classes really brought me back to the mid-late 90s.
While Steve talks about the technical aspects, I thought I’d talk about some of the other reasons why the product was successful, and why the development team that worked on it was so engaged in the product and its success. I had dinner the other night with a teammate from those years, and though we’ve both moved in quite different directions since then, we both agreed our team was something really special. So maybe there are some lessons we can take from it, a decade later. I apologize in advance for any rose-colored glasses involved in looking back at this time. I invite the other team members to come and correct me!
Strong Team Identity
What are you working on? What value does it have to the company? Who is going to use it? We knew the answers to those questions. We were the Navisphere team, “hand-chosen” to implement the architectural direction set by the first few people (like Steve). We were using new tools, new design methodologies, and supporting new hardware. Our product had to be made — there was no alternative solution out there. We also knew that the product had to be viable for years to come. We may have let some of this go to our heads, but we really took pride in what we were creating.
It was more than just that, of course. This was before the age of global teams, and everyone involved in the project was in the same location. We had conference rooms we could just sit down in, without a lot of overhead. We could easily walk to each others’ cubes for design discussions. We played Frisbee in the parking lot after lunch, socialized outside the office, went out for lunch together, and had a rich shared history. Granted, we weren’t all friends, but there were enough social connections on the team to get us through the inevitable tough times.
Technical Leadership and Ownership
We were fortunate to have some skilled and dedicated individuals in charge of the technical direction of our team. If you weren’t sure on some technical direction, there was no question about who you should talk to. These people were not just skilled and dedicated, they were also decisive and accountable. They took responsibility for everything under their umbrellas. They attended (often led) code reviews and pushed for necessary changes. They knew that by extension their name was on every piece of code under their umbrella, and they took that responsibility seriously.
There was no doubt about who these owners were. Over time, as the code base grew, it became necessary to subdivide, but there was always some idea of technical ownership. This led to a powerful combination of responsibility, accountability, and pride of ownership.
Results-Matter Management
I’m not going to say our management was perfect. There are certainly some stories I could tell which would send you screaming. But in general, (front line) management was more focused on results than details. The technical leaders knew the management trusted them and would enforce their decisions, and individual contributors knew their work was valued. I rarely worried about what I wore to work, what hours I put in, or whether I was perceived as working hard enough. I knew my output spoke for itself.
New Technology
As much as we all know that combining well-designed and well-tested already-written components can produce quality software, there’s something exciting about being on the bleeding edge. Like Steve said, we had to write an abstraction layer for things like cross-platform 32-bit unsigned integer types, since support was so different in all the different OSes. There’s something fun about being on the front line like that. There’s a certain freedom that comes with knowing there isn’t an industry standard yet for what you’re about to do.
Industry Timing
Of course, the part that can never be recreated is the timing of the project in terms of the overall industry. Y2K was on the horizon, IT spending was high, and the tech bubble was in full swing. People were excited to be working in our industry. Engineering departments were tiny gods, free from corporate interference. We had no Internet filtering, we had decent equipment, we had corporate outings and launch parties, generous training budgets, got T-shirts and mugs, and so on. We had a lot of fun, in and out of the office. And somehow we still managed to put out a good product.
It Wasn’t all Roses
Of course, if I try, I can remember plenty of things we all got upset about, too. Senior managers with vague requirement statements, high-maintenance customer relationships, difficulties with unproven tools, stupid political battles over release dates, hiring freezes, and much more. But for some reason those complaints faded over the years, while the positive memories stayed strong. Maybe it’s because every other team has had its share of warts too, but few of them have had the same overall feeling of shared success.
So What Can We Do?
So, as managers today, what can we take from this story? I personally look at the team identity and technical leadership as barometers for how a team “feels” and how successfully it can deal with speedbumps. How often does a team spontaneously collaborate? If you ask “who owns that?” do you get an answer or a history lesson that ends with “nobody, these days?”
Maybe you can’t recreate the industry environment of 1998, but think about what made that environment exciting and see what you can do to bring some of that excitement into the office today.
