Swaying the Team to Innovate.

Innovation in Corporate America

As I mentioned in Between a Rock and a Hard Place, our team is currently on the horns of a dilemma. I likened our situation to racing on a flat tyre. Do you stop and fix, taking the hit of lost time, or do you make a best effort to keep pace, almost blindly disregarding the situation.

I’ve just finished reading Sway (Brafman & Brafman, 2008). It offers some additional insights into our situation. For example, all my engineering training has been around technology. How computers work, how software works, how to create good software, how software design works, how the software process works, etc. As far as I remember, no time was given to group dynamics. Since most non-trivial software requires a team to collaborate, one would think that taking the group into account would factor into software design and engineering.

Alas, it doesn’t seem to in traditional techniques, while Agile techniques realise the group dynamic, but still put a lot of focus on working software. Our problems are not with working software, as our software works and is popular with customers. Our problem is that the team can’t keep pace with the features requested. To do so, would require a major refactoring of our existing codebase to allow for the current team to increase productivity.

When it comes to groups, it would seem that we all fall into one of four categories: (Brafman & Brafman, 2008)

The first role is that of the initiator: the person who always has ideas, likes to start projects, and advocates for new ways of moving forward. Think of someone like Matthew Broderick’s character, Ferris Beuller, in Ferris Beuller’s Day Off. The entire movie is about Ferris’s new, creative ideas for something fun to do: let’s ditch school, take a vintage car out for a joyride, sneak into a fancy restaurant, attend a baseball game, and star in a parade while we’re at it. When you’re in the same room with a Ferris Bueller type, it’s hard not to get excited about whatever new project or idea he has to mind. You can always count on initiators to come up with new ideas; they aren’t necessarily the life of the party, but they’re definitely the ones who suggest having a party in the first place.

If initiators are represented by Ferris Bueller, their opposites – blockers – are like Ferris’s friend Cameron. Ferris wants to take a joyride; Cameron is afraid of getting caught. Ferris wants to go to a nice lunch; Cameron points out that they don’t have a reservation. Whatever new idea the initiator comes up with, the blocker finds fault with it. If hanging out with Ferris Bueller makes us want to go out and do something fun, spending a minute with Cameron makes us reluctant to do anything. Of course, it’s easy to think of blockers as pure curmudgeons. But as we’ll soon see, they play a vital role in maintaining balance within a group.

Initiators and blockers are bound to lock horns, with is when the supporter steps in, taking one side or the other. If there’s a decision to be made, you can bet on the supporter siding with either the initiator or blocker. The fourth role, that of the observer, stays fairly neutral and tends to merely comment on what is going on.

Most of the tension in the group lies between the initiator and the blocker. Initiators are all about making new things happen. They have a wealth of fresh ideas. They might be wildly optimistic and have a tendency to rush to action, but their creativity, energy and drive can be instrumental when it comes to innovation. In contrast, blockers question the merit or wisdom of new decisions. Instead of merrily going along for the ride, they raise points about the potential harmful consequences that might follow.

In many ways, I see myself as the initiator in our situation. The internal architecture of our products is based on an in-house component model created in the mid 1990s. It attempted to decouple components, but went too far as they lack cohesion. Developing in this architecture leads to a proliferation of boilerplate code, threads, ID objects, etc. It doesn’t play well with existing Java tooling, and is difficult to trace through when it comes to debugging or understanding how the architecture supports the functionality. I have been advocating a move to an architecture based on the Spring Framework, and have done some preliminary proof of concept work, which shows a dramatic simplification of the code and a reduction in code size, though the cost of this is about three developer-days per component. With some products consisting of 15 to 20 components, a transition to Spring would require significant developer time.

My blocker seems largely concerned with loss aversion. They contend that my suggested changes are time consuming for no customer benefit, risky, and besides we’re under the gun to get new features and bug fixes in. Their point is that it is better to mend and make-do with band-aid solutions and allow the project to limp on, rather than do the open heart surgery needed to restore the project to health. As the person who plays the blocker role, also plays the management role, it would seem the blockers have the upper hand at the moment.

That said, within your software team, you need both initiators and blockers. You can think of initiators like the accelerator in your car, then the blockers are like the brakes. You wouldn’t feel safe driving a car which lacked either one. At some point, a compromise will have to be reached. If we take the attitude that neither of us is completely right, and that our points deserve consideration, we can work through each others concerns and hopefully come to an agreement which moves the project forward.

That said, I’d offer the following snippet of advice for avoiding loss aversion from Jordan Walters, the financial adviser from Smith Barney, as recounted in Sway (Brafman & Brafman, 2008):

Jordan offers an example that illuminates his perspective on overcoming this psychological force [loss aversion]: “Let’s say you’re travelling on a long trip and you have a flat tire,” Jordan began. After fixing the tire, you have two choices: you can look for shortcuts to make up the lost time and completely rearrange your trip, or you can continue on your way and accept that you’re running behind schedule. Jordan advocates the latter, “long view” method: You might be a little late, but “you’re on your way again and you know where you’re going.” Rearranging your trip on the fly, on the other hand, can get you thoroughly lost.

When things go wrong, we can either apply a short-term, Band-Aid solution or remember that in the grand scheme of things it’s only a minor misstep. Having a long-term plan, and not casting it aside, is the key to dealing with our fear of loss.

In my mind our path is clear. A long term plan for these products is needed, and we need to stick to it, regardless of the changing fortunes of economy, resources, fickle management, etc. The campaign may be long and hard, but I believe it will be worth it in the end. All I really want is to be a productive software engineer.