Category: management

“Iterate and release” has its problems, too

One of the teams I’m working with has adopted a sort of customized agile-style development process. I really like it, but a few problems are coming up:

  1. Just like after a heavy workout, you need a warm down of some sort. You can’t just suddenly stop and declare victory after a sprint. There are always a few more things to do, and your brain muscles need to flush out the acids that built up during the race. And just like that feeling the day after a good work out, it’s hard to actually get momentum going again, and a cheerleader only makes you bitter.
  2. Collaborating with other teams in the company is very tricky. Team independence is crucial to the agile process, but that means no two teams are ever in synch. It’s like IM’ing with a friend in Europe. You can catch them for a few minutes in the morning if you get into the office early enough, but by the time you’re ready to actually say something, they’ve logged off and hit the pubs.
  3. Similarly, business operations quickly get out of synch with what’s happening on the ground. The roadmap review or the hiring planning or the marketing communications or the performance reporting should all operate with the same “rapid iteration, frequent release” methods.

    For example, in my previous jobs I kept a big whiteboard marked up with all the key metrics of my business. I stared at it all the time. Patterns emerged with each new line row of data which made the short-term decisions much easier to identify. The 3 year plan was then an abstract vision with tangible month-to-month goals. Of course, we weren’t able to act on many of the short-term needs because the planning for the current year was already locked down.

  4. It seems hugely important to have an abstract framework to work within as a guiding light when you’re chasing 30 to 60 day goals. But agile development doesn’t necessarily have an end point. The goal needs to feel like a BHAG, yet it needs to be as measurable as the end date of your development cycle.

    For example, a news media site may want to chase down a long term goal of “High customer loyalty”. That goal then needs to be measured in terms of things like repeat visits. And so the result of each sprint should be an understanding of whether or not that sprint had an impact on repeat visits.

There are lots of great things that come out of the agile process including an intense focus on a goal that everyone can work towards and the freedom to postpone things that block progress, among many others. However the process is not without flaw.

At some point, all the IT solutions you can purchase and project management processes you can adopt will hit a ceiling. That ceiling is most likely a need to fundamentally alter the goals and direction of the business itself.

Leadership lessons from China

There are some interesting leadership and management lessons from some of the Chinese manufacturing systems that can be applied at all levels of an organization to make it more innovation-friendly. The contrast between leading and managing may be subtle to some, but it’s hugely important in making a company capable of competing in the fast-paced Internet economy.

Not knowing the path to a particular outcome can be excruciating to someone who knows what they want. Managers find it much easier to make lists of things that add up to the sum of the final goal, and they like to put checkmarks next to all the items in the list as they are completed. This system never scales no matter how talented the manager is because that system is totally dependent on the manager.


Photo: Hocchuan

John Seely Brown and John Hagel examine how a network of motorcycle parts assemblers in China break traditional centralized management tactics to optimize for innovation in a paper called “Innovation blowback: Disruptive management practices from Asia.” In the Chinese city Chongquing a supplier-driven network of parts developers work together under the loose guidance of their customers rather than under the orders of assemply-line management:

“In contrast to more traditional, top-down approaches, the assemblers succeed not by preparing detailed design drawings of components and subsystems for their suppliers but by defining only a product’s key modules in rough design blueprints and specifying broad performance parameters, such as weight and size. The suppliers take collective responsibility for the detailed design of components and subsystems. Since they are free to iomprovise within broad limits, they have rapidly cut their costs and improved the quality of their products.”

As a manager, when you define what is to be done and how it is to be done, then you are setting the exact expectation of what is to be delivered. There is no room for exceeding expectations, only for failing to meet expectations. Your best-case scenario is that you will get what you asked for.

As a leader, on the other hand, when you set parameters for success, you let the contributors in the system share ownership of the outcome. This is participatory production which includes an important incentive for each individual contributor: pride. The outcome becomes a somewhat personal reflection of each contributor’s capabilities as a person.

There’s another interesting paper on the concept of peer production called Coases’ Penguin written by Yochai Benkler in 2002 that talks about the incentives that drive users of online media to contribute content to a web site such as Slashdot or Wikipedia. One of the interesting conclusions is that financial reward can sometimes have a negative effect on participation and collaboration:

“An act of love drastically changes meaning when one person offers the other money at its end, and a dinner party guest who will take out a checkbook at the end of dinner instead of bringing flowers or a bottle of wine at the beginning will likely never be invited again.”

John Battelle similarly points out that Google’s latest attempt to monetize peer production in online media may actually have the effect of degrading the overall quality of their ad network. As they provide ways for user-generated content (UGC) sites to kick earnings from AdSense back to content creators on those sites, they are inviting spam and click fraud at pennies in earnings per user at the expense of quality contributions.

“I’ve never seen UGC sites as the least bit driven by money. They are driven by pride, the desire to be first, reputation, whuffie. But dollars? That often screws it all up.”

Of course, pride won’t replace the need for salaries, but it can certainly make up for the margin pressure these particpatory production systems are putting on themselves. When the production process reduces waste, that savings will get passed on to the buyer before the profits get passed back to the creators. That’s how this Chinese network has stolen marketshare from the big motorcycle manufacturers like Honda and Yamaha.

“The average export price of Chinese models has dropped from $700 in the late 1990’s to under $200 in 2002. The impact on rivals has been brutal: Honda’s share of Vietnam’s motorcycle market, for instance, dropped from nearly 90 percent in 1997 to 30 percent in 2002.”

Of course, everyone in the Internet business would rather be in a position of growth than one of decline regardless of the profit margins. The way to put your company on the growth track and to stay competitive through innovation is likely based on these types of leadership principles rather than micromanaging your staff through every step of an unpredictable journey.

“Loosley Coupled” does not mean “Easy to build”

The concept of “Loose Coupling” is great on so many levels. I’ve used it to describe different types of things in ideal worlds, but I’m starting to see that there is a lot of gray area there that can be maddening in real worlds.

Here is Wikipedia’s current definition of it:

“Loose coupling describes a resilient relationship between two or more computer systems that are exchanging data. Each end of the transaction make their requirements explicit and make few assumptions about the other end. Loosely Coupled systems are considered useful when either the source or the destination computer systems are subject to frequent changes.”

I’m working with a small team on a really fun web-based product that weaves lots of stuff together. The core app we’re working on has a very powerful layer of intelligence built into it, but it depends on a stack of data sources and rendering environments that are all partially isolated and not necessarily production-ready.

This means that we can’t really test the product end-to-end. It means there are several layers of troubleshooting that get added to each bug no matter how small. It means we have to fake a service layer here and there to emulate behavior.

I’m realizing now that “loosely coupled” means you have to think a lot harder about each move instead of just cranking out everything from scratch the way you want it to work.

Ultimately, the power of our platform services including things like scalability and user data management will accelerate this product’s ability to reach a more profound state of being than it could without loose couplings. But the cost of glueing all the things together in parallel means that we spend hours in meetings and constantly reshuffle our attack plan.

It feels like running through mid-court of a dodgeball game.