Almost Famous

Ever type your name on the Google page to see what comes up? I searched on mine today and found I am high on the list. When searching for "William McCann" I come up first on Google and Yahoo!, and third on Live (as of 2/28/2007).

When I search for "Bill McCann" I come up third on Google. Yahoo! does not find this site under "Bill McCann", but lists my LinkedIn profile second. I didn't see myself when searching Live with my nickname.

The irony here is that I have taken no steps to assure that I am found by search engines. It must be getting easier to get noticed; no need to take special steps (Doing something right). Or maybe I'm almost famous ;).

Leadership and Self-Deception

I received the book Leadership and Self-Deception as a gift from a close friend of mine recently. The book is written as a parable much like another leadership book, The Goal given to me as a gift (but not from a friend). I have to admit, I do not like the parable format. The stories told in this way seem contrived; no wait, they don't seem contrived, they are contrived.

The book also has no author. Well, OK, no single author. Instead, credit for the book is given to the Arbinger Institute. There is no research behind the story, and no academic references other than to an obscure doctor Ignaz Semmelweis. The book felt like a white paper for a leadership consulting firm. Maybe that is Arbinger's intent, or maybe that's my self-betrayal.

That's not to say that there aren't helpful tips in the book. Like all material of this ilk, there is plenty we can apply to ourselves. In Leadership, the authors make the case that spend our time in boxes, where we rationalize our behavior and blame others. Coming out of these boxes must be like a self-actualizing experience.

I wouldn't be honest if I recommended the book. Certainly the lessons, taken with a grain of salt, could be very helpful. Myself, I will take away some of the concepts and I will be more conscious of delusions. In the end, maybe it will make me a better leader and person after all.

What is a CTO?

Recently someone asked me "What is a CTO?" I answered with nonsense about software engineering and network infrastructure. Thinking back on the conversation I realized how badly I described the role. What's more surprising is that I've held the role, albeit under different titles, at three firms.

First and foremost, the Chief Technology Officer is the technical visionary for the company. In this role he must be the evangelist for technology; keeping products and services competitive. He must set a clear path to achieve the goals for the vision. And he must assure that everyone knows the vision.

A great CTO will be a passionate advocate for best practices of engineering, quality assurance, and technology operations. Of course, to advocate best practices, he has to know the best practices. These practices will include agile development methods, test driven engineering, and thorough securing of infrastructure.

The CTO have intimate knowledge of the technologies required of his vision. He must be passionate about the platform, when the platform is specific; and agnostic of the platform, when the vision is independent of it. The best CTOs are not concerned about Microsoft vs Linux or Java vs .Net. Instead he pushes the platform needed to accomplish the goals for the company.

The best CTO are excellent managers and leaders. They recruit talented staff and have great retention rates. He understands the value of knowledge capital and continuously encourages learning. And he keeps his own knowledge sharp too.

Through vision and planning the CTO will instill confidence from other senior managers. He will keep his products and services best-in-breed. And he will give customers confidence that their solution will get better and better.

These are the points I should have made when asked..."What is a CTO"?

Implementing Agile Development

Sometime late last year I was introduced to the concept of Agile Development. Actually, I had been formulating iterative techniques over the past 10 years. Craig Larman's book simply reinforced my thinking. That is, software is best developed in manageable increments.

The bigger problem is moving a team steeped in serial waterfall methods to interative methods. Some people simply don't get it; they don't get collaboration; they don't get accepting change; and they don't get emphasizing software over documentation. All of which is surprising because most development teams never receive adequate documentation, constantly deal with change, and usually brain storm to solve problems.

For us de-emphasizing documentation shouldn't be so bad, after all, we don't receive good requirements anyway. But strangely enough, there are developers who still believe that one big master documents is necessary for successful projects. These people are wrong. It is wasteful and expensive to attempt to write a complete specification prior to engineering the software.

I saw this first hand a DoubleClick, Inc several years back. The firm hired a team (larger than my current department) dedicated to writing specs. The documents produced by this group were huge, numbering hundreds of pages. And the details were debated ad-nausium, leading to stagnation. What was produced was documents, what wasn't produced was working software.

A greater problem for us is managing multiple projects. Our technologies are not constructed on a common code base. Therefore each project becomes its' own set of increments. Currently we have five projects under development. That's a lot of work for a staff of seven plus four consultants. With all these concurrent projects, managing increments becomes difficult. Afterall, it isn't practical to deliver an increment every week. Or is it?

We seem to do alright with collaboration, but there is room for improvement. It helped to implement daily stand-up, or scrum, meeting. The meetings are short and focus on the goals for the day. We have not attempted to implement strict pair programming, althought there is very frequent teaming on tasks.

I remain a strong proponent of agile and iterative development. Over the next couple of months we will be able to take an objective look at the results of these methods.