Creativity

Another book that I read recently is Richard Florida's The Rise of the Creative Class. His thesis is that human creativity is the ultimate economic resource, and people who make their living primarily through exercising their creativity are becoming the dominant class in America and other economically advanced countries. He offers lots of data, charts, and statistics. He profiles various parts of the country, ranking them by creativity, tolerance, and technology.

One of the things that Florida sites as important in building a first-class creative city is creating a vibrant street-life, filled with cafes, clubs, galleries, etc. Seattle, my home for nearly twenty years now, ranks #3 on his "Creativity" index. Recently the mayor of Seattle proposed regulatory changes to make it easier to get a license for a sidewalk cafe. Apparently Seattle does understand some of the things that really matter for building a first class creative economy.

The other piece of the book that particularly caught my eye was when he talked about the differences between companies that truly understand how to get the best from creative workers and old-style companies. Old style companies, he says, put the senior management in big corner offices away from everyone else and put low-ranking workers at or near the central parts of the office. New-style companies put open spaces in the central part of the office, with managers near the open spaces.

This reminded me of some of the companies that I've worked at over the years. As a software engineer I've worked at some companies that were extremely successful, that clearly showed they were able to get the best out of their workers. Those companies (F5 Networks, Microsoft) followed that model of open spaces for people to congregate near the center of the building, and keeping even senior pretty management in offices that were just like everyone else's.

By contrast, one company that I worked at recently had their engineers crammed into tiny spaces while the executives had very large offices that were set off in the corner, away from everyone else. I remember looking at the offices of the CEO and the COO and being offended at the size of their offices, especially when they were cramming 6 programming managers into a conference room because there wasn't any cubical space left.

Really well organized...

I was talking with the V.P. that my manager reports to earlier this week. He and my manager proposed that I take on the role of "Release Czar" for the next major release of the company's flagship product. It's kind of a big deal, and certainly a big career growth opportunity for me.

One of the reasons he mentioned that they thought I'd be good for the task was that "you're really well organized." I was slightly taken aback when he said this. I don't think of myself as being well organized. In fact, I think of myself as disorganized by nature.

I was talking with my wife about it that evening. She said that these days, I am pretty well organized. Thinking about it, I realized that it is true. In fact, it's something that I've been working on pretty hard over the last year or two.

It's nice to have external validation that I'm succeeding in becoming more organized.

How big is a test case?

I run an automated testing team, and I've noticed something interesting lately. As we start adding more test automation, and looking at the test automation numbers used by other teams, it's impossible to tell at glance what the scope of a test case is. What does it mean to say that you have 10 automated tests for a particular feature area? How does that compare to 10 manual tests? Some of the tests that we run in our automation system are pretty much direct ports of manual test case. Often the manual test case was defined by another tester at some point in the past. Many of the tests that are currently being automated are tests of the rules engine. In the test you create an rule, apply it to the device under test, pass traffic of various types through the device, and look at the results. The test may set 5-20 parameters on the device, and check the results of a similar number of distinct pieces of traffic sent through the DUT. This all counts as one test. In contrast, some of our automated tests contain an enormous number of setting changes and traffic checks per reported test case. The SSL test suite that we've built around the codenomic does 7200 discrete pieces of traffic for each of the 144 tests that we report in automation summary. Our compression test suite tests 432 discrete settings for each of its test cases. We have 480 test cases in our compression suite, for a total of 207,360 checks. If we were to say that a manual test case averages 15 checks, then the compression test suite would be the equivalent of nearly 14,000 manual tests. Obviously, it isn't the equivalent. The manual test suite for the entire project only contains about 2000 tests. So how big should a test case be? Is it possible to define tests in such a way that you can meaningfully compare manual tests to automated tests? Would that be worth doing?

Got called by one of my employees on Avoiding Productive Conflict

I had a one-on-one meeting this morning with one of my reports. He was expressing some frustration about working with one of the other team members. He also was concerned that his ideas were being ignored. As we discussed it he said that I tend to side with another team member most of the time, and that has discouraged him from raising issues.

I thanked him for calling me out on it. I said I was really pleased to see him do that--it's tough to tell your boss that he's doing something wrong. I complimented his courage to bring it up directly with me. This is a good example of my own tendency to prefer harmony over productive conflict, the fourth of the Five Temptations of the CEO.

He is pretty conflict averse himself, and not very verbally articulate (he needs time to think before he can express himself clearly), so he is not naturally inclined to push his ideas in meetings. We talked about various ways to handle that. I suggested that he write up his ideas and come talk with me directly. Then after he and I have had a chance to discuss the ideas and flesh them out, he could raise them in the larger group.

I was really pleased, both with him for being willing to take the risk he took, and with myself for creating a team environment in which he felt safe enough to take the risk.

The Five Temptations

I stumbled across a book at the library last week called The Five Temptations of a CEO: A Leadership Fable, by Patrick Lencioni. Intrigued by the title, I checked it out and took it home. It turned out to be both a good book and a quick read.

The ideas in the book are neatly encapsulated in “The Model”, a short section towards the end of the book. The model lists the five temptations:

• Choosing status choosing results
• Choosing popularity over accountability
• Choosing certainty over clarity
• Choosing harmony over productive conflict
• Choosing invulnerability over trust

I’ve been thinking about my own strengths and weaknesses and how they manifest in this particular model.

Status over results

I don’t think that this is particularly a problem for me. My primary motivation for work these days is paying for my children’s autism therapy, not moving ahead in the world. I have worked with (and for) people for whom this was a primary motivation. The big problem that I saw coming out of this was risk-aversion. They didn’t want to do anything that might endanger their status.

Popularity over accountability

It is tempting to try and be friends with the people who work for you. When everything is going well, it isn’t a problem. But when there are problems, it usually makes the problem harder. I have, and do, struggle with holding people accountable, but popularity isn’t the core of the problem. The core of the problem for me lies in temptation number three.

Certainty over clarity

I am fairly risk-averse by nature. In my early years as a manager, I put off a lot of decisions that I should have made because I wanted to be absolutely sure that I was making the right decisions. With the help of a good therapist and some good managers, I’ve gotten a lot better at this in the past five or six years. The desire for certainty made it harder for me to hold people accountable. Because I was waiting to be certain, I didn’t commit to a decision and make it clear to the team. Since I hadn’t given them clarity, it didn’t seem fair to hold them accountable. That’s a point that the author calls out explicitly, and it really rings true for me. While I have improved here, this is still something that I need to watch out for.

Harmony over productive conflict

This is another one that poses a challenge for me. I spent 2002 working on a Masters degree in counseling (then my kids were diagnosed with autism and I realized this wasn’t a viable career change, I never went back for the second year of the program). One of the more interesting things that we did was something called the Thomas-Kilman Conflict Mode instrument. It rates you in various styles of handling conflicts. It took me a while to make sense of my results. My two high areas (much higher than the others) were Avoiding and Competing. In fact, they tied each other for #1. After thinking about it for a while, I realized that it did fit. I preferred to avoid conflict if possible, but once it was clearly unavoidable, I became very competitive and tried to “win”. In fact, I tended to come out swinging for blood. Neither of these are terribly effective ways of handling conflict, and now I know that I need to watch that carefully. As a manager, I need to make sure that I don’t squash the conflicts that a team needs to go through in order to evaluate alternatives and reach good decisions. At a previous company I watched one of the senior executives squash any conflicts that involved his staff. It prevented some serious personnel problems from getting solved. I work hard now to distinguish between unproductive conflict that needs to be squashed and productive conflict that needs to be fostered.

Invulnerability over trust

I’ve made deliberate choices to be vulnerable. As I see it, in order to be invulnerable, I would have to behave as though I didn’t trust anyone. That’s just too depressing of an assumption for me. Assuming that people aren’t trustworthy, and then acting accordingly makes me unhappy.

Lessons learned from Civ IV

I've been playing Civilization IV again recently, and realized that there are lessons in Civ IV that are applicable to a problem I've been wrestling with at work.

I run a team that builds test automation tools for a large company in Seattle. There are several other groups within the company that have built similar tools. Recently I was charged leading a team to look at all the different tools in use within the company and figuring out how to reduce the amount of duplicated work, as well as increasing the total amount of our testing that is automated.

After much conversation we came up with a kind of intellectual framework describing 6 tasks of test automation and 4 contexts in which automation is used within the company. Some time soon I'll post about that in more detail. The tool that my team has built addresses the most complex types of test automation, but is more cumbersome than some of the other tools that address only the simpler automation contexts. We've spent a lot of time trying to figure out how to make it easier to use our tool for less complex automation tasks, without a lot of success.

In my recent Civ IV games (I bet you were starting to think I'd forgotten about that...) I've been focusing on winning Cultural victories rather than military or scientific victories. In a cultural victory one of the most powerful things you do is assimilate the cities of other players. It occured to me that we could assimilate the other automation tools in the company--we can wrap our tool around them, use it to handle the most complex tasks, and let the testers and developers who don't need that complexity continue to develop their automation using the simpler tools.