If you had a look at my calendar you would think that most of my days were the same. Daily status meetings, design reviews, one-on-one meetings with team members, client presentations, and so on. They’re not. Some days feel like a mad rush and others are more contemplative. Still others, the days with 90 minute project reviews and training and updates and alignment exercises, are a slog. On those days the mind wanders and in the odd moments when I am not checking twitter I ask myself, “What am I trying to achieve?” When I answer my own question I realize that with one tug at the bow I’m trying to hit two targets at once: the perfect product and the perfect team. The team often outlasts the product, and is often more important to the business. How tempting, and how dangerous it is to focus on the product to the detriment of the team.
Steven Sinofsky is blogging again; he’s focusing on the interplay between engineering and human factors in building technology. This focus leads him to consider how and why things are built, rather than what is built – which is why his blog makes for interesting reading. (**) In his internal blog at Microsoft Sinofsky killed countless virtual trees describing and justifying the organizational structures he feels are necessary to build big software in big companies. “Don’t ship the org chart”, Sinofsky is claimed to have said. I don’t remember if he really did, but who cares – he meant to. The point is simply for leaders to create an organizational structure where employees are best positioned to succeed. Brad Garlinghouse, formerly of Yahoo!, agrees. His widely-known “Peanut Butter Memo” warned his colleagues of the dangers of spreading organizational focus too thin at the expense of a coherent vision around which initiatives can be organized. It sounds almost tautologous when put this way, but the practical wisdom from this general point is elusive. Seven years later, Garlinghouse writes:
In a recent blog post, venture capitalist Ben Horowitz relegated corporate culture to a second-class citizen behind creating a great product. I respectfully disagree. Great products don’t come out of thin air. They are an outcome of environments where innovation can thrive and talented people are encouraged to be bold.
Garlinghouse says that building great teams is the ultimate objective because they produce worthy products. Yet a team without works is dead. Sinofsky focuses on structures and process because creating the right environment is essential. A key message is to get the right structures in place before it is time to execute. The lessons are too hard to apply on the fly in the heat of the moment, when deadlines loom, requirements stack, and you’re reminded daily of the incredible importance of the project upon which the fates of many rest, and upon which upper management is laser focused. “Our initiative to produce automated TPS reports could not possibly be more important!” And in some sense this is true. But this is the wrong time to be thinking about how to build a great team. The foundation needs to have been laid long before, so it all holds together when the storm hits. I realize I am not saying to much about what the frameworks look like, and that’s intentional: read Sinofsky’s blog and you’ll find out. It boils down to:
- Having a clear vision.
- Making sure that everyone has a clear role that they understand.
- Empower everyone to do their job.
When I say or write something, there are actually a whole lot of different things I am communicating. The propositional content (i.e. the verbal information I’m trying to convey) is only one part of it. Another part of is stuff about me, the communicator.
You are broadcasting on two channels and often the second one – what you’re trying to say about yourself in the way that you say what you say – is often more important than the first. And that’s okay. Similarly, as a manager when I discuss project-related business goals I am also discussing how to develop the team professionally in a way that is fulfilling and productive. In practice this means that project-related tasks (e.g. “write the user guide for the advanced optimization UI”) often have a broader, hidden meaning (“understand the complexity of the processes we are ask our users to carry out”). The goal-behind-the-task can be lots of things: to provide the opportunity to do something new or fun, to mentor a new teammate, to work with someone with a different communication style, to learn a process few people understand, to struggle, to get the chance to take a breather. It is not a hidden Karate Kid-stye lesson; we sometimes discuss it up front. I don’t know how to think about professional development outside the context of the things we are asked to do, and I don’t know how to get projects done without thinking deeply about the diversity of the skills and characteristics of each member of the team. This is why “matrixes organizations” confuse me: you can hit at most one target.
You’re building two things: be mindful of them both since they rest on each other.
(**) Side note: Steven’s blog is also praiseworthy because it is snark free. It’s filled with ideas, data, and observation. Truth is interesting when told well, but it feels dangerous to rely on it too much for fear of sounding boring. Perhaps the lesson here is that we should not care so much about being adored and simply write what is true.