Patience and Impatience
A few weeks ago, my new boss sent out a memo to all of his direct reports on his philosophies of leadership. While I understood what he was trying to do, I was a little skeptical about what he was sending. After all, leadership is a personal thing and everyone has their own styles. I’ve been through a lot of courses on it (some good and some not so good) and even read books. For the record, I recommend Rudy Guiliani’s book (even though he grew tiresome during the presidential election as a shill for the Republican party—not a slam on the Republicans as much as me being tired of how both parties exploit anything it can get its hands on, but I digress). But when I saw the principles, they quickly resonated with me.
He had a pair that really come to bear as I am embarking upon this new opportunity that I spent some time thinking about afterwards. One was "Be Patient" and the next was "Be Impatient". The idea of being patient and, at the same time, being impatient is great. I think of the legendary basketball coach John Wooden, who would implore his players to “be quick, but don’t hurry”. Understanding how to balance a well-thought strategy with full-throttle execution is the difference between successful projects and ones that go down quickly. When there’s excitement around a project, there’s a tendency to jump in with both feet and not spend enough time drawing out a blueprint. At the SD West conference, I was working the booth for patterns & practices when a developer came up and this conversation started:
Attendee: “Why should I care about architecture?”
Me: “Applications are complex. Would you build a building without a clear architecture?”
Attendee: “You are losing this argument.”
Me: “I didn’t know we were having an argument. Would you really building something without giving it the proper forethought?”
Attendee: “This conversation is useless.”
And then he walked away. I don’t know if he was just picking a fight with Microsoft (there’s one in every crowd at these shows), but I found it fascinating that this guy gave zero credence to architecture--which is all about being thoughtful and thinking more broadly. I got the impression that someone tells him something needs to be done and he opens up his IDE and puts fingers to keyboard to whip something out. Patience is a virtue. That goes for building software as well as building the business case around the software. I feel like we are in that stage right now with Workspaces. As many of you may have seen, we were fortunate enough to have Jim Newkirk join our team. Jim describes himself as pragmatic and I love that description. He knows the value of time, but he also knows the value of doing things right the first time. Sometimes, that means fending off the insistence that things be out sooner than expected. Don’t get me wrong—I am all for “sooner rather than perfect”. But in Microsoft’s results-oriented culture where people need to see tangible progress, I worry that in the panic to get something out the door to “check the box as being done”, sometimes that leads to mistakes that aren’t easily reversed. With the next GDN, we are trying to be quick, but we are not hurrying. It reminds me of what someone on the XML team was saying when talking about an issue with the WS-I spec: “Make sure you are comfortable with what you do. We have the ability to define a generation of web services applications and every decision counts.” Recognizing the impact you can have and understanding that the decisions need to be made with care. Once we have a grasp of the long-term view and the short-term plan to get there, we will run hard at the problem. Until then, we will resist the urge to open the IDE and simply write a short-term fix that will bring us back to the situation we are in now one year from now.