Mike Coyle’s Weblog

A couple of months back, I had the pleasure of being interviewed by Susan Ladika for PM Network magazine (a publication of the Project Management Institute). They were doing an article about managing small project teams for the March 2008 issue.

I put together a bunch of content in advance of the interview. Now that the magazine’s hit the streets, I figured that I’ll publish the stuff that I wrote that didn’t make it into the article.

I did my prep work by writing out a fake interview with myself. I’m certain that I’ll recycle some of this content in future writings and talks, but here it is in its original form for your reading enjoyment:

–[BEGIN FAKE INTERVIEW]—————————————–

1) Your company uses the slogan “We help small teams solve large problems.” Please explain.

The needs of small, disciplined project teams are largely unrecognized and under-served in the project management community. We started our company to bring the necessary people, process, and technology to small teams so that they can leverage their constraints and deliver value to their customers in a predictable and instrumented fashion.

Too many small project teams either wander their way through the project lifecycle alone, or end up suffocating under a heavy, inappropriate layer of bureaucratic oversight that makes project delivery slower and more painful, but doesn’t necessarily reduce any tangible delivery risks.

We know that there’s a better way, so we put our money where our mouth is. ProjectPipe.com is our project management software solution that embodies our approach to disciplined, high-performance small team project management. Our target customers in corporate settings are the small boats of ambition floating in the sea of big company mediocrity. While we’re not here today to discuss ProjectPipe, any interested readers can find out more at ProjectPipe.com.

We are convinced that the future of project delivery is small, distributed teams. We are fortunate to be in a position to expedite this trend through our software, consulting, and writing.

2) But isn’t bigger generally better?

No. Having more people on your team is not like having more money in the bank.

For example, jazz quartets don’t want to be orchestras when they grow up. The two are different beasts.

If you try to run a jazz quartet like a symphony, you get bad jazz. Run a 20-piece orchestra like a jam session, and you end up with chaos. The same goes for project teams. If you run a small project like a miniature large project, you end up with….pretty much what you see in corporate environments everyday. Namely, too many meetings, lots of low-value boilerplate documentation, and other adminstrative overhead that gets in the way of solving the real problems at hand.

Don’t get me wrong, a team of 4 people still needs to play by the book, but it’s a different book.

3) Why does the size of a team matter? Aren’t there universal best practices for project management?

At a high-level, there are a number of universal truths that the Project Management Institute, and other organizations have done a wonderful job categorizing and articulating. However, when it comes time to tactically implement these best practices, you see the entire spectrum of implementation choices, from hyper-bureaucratic process overkill to Wild West-style chaos.

In theory, practice and theory are the same. In practice, they are profoundly different.

This is why it is so important to have strict adherence to a lightweight process. As a project manager, you want to spend your overhead capital wisely, applying documentation and other process-related protocols to the specific areas of project risk that are relevant to your project.

4) What types of things are more difficult for small teams, aside from the shortage of manpower?

There are three general challenges for a small team. First of all, distractions and overhead can be a significant drain of time and attention. Second, context switching can be expensive, as members of small teams often wear multiple hats. Lastly, having fewer team members to draw insight from can result in less diverse domain expertise brought to the table.

5) Are there any advantages that come from having a small team?

Certainly. Small effective teams understand the nimble clarity that comes with having few moving parts. They have conversations rather than meetings.

Small teams separate the wheat from the chaff, since there’s nowhere for underperformers to hide. As a result, I’ve found that higher-skilled resources are more likely to prefer working in smaller teams, since there’s a bit of self-selection at play. For example, rock stars know that poor performers are more interested in being the 16th person on a 16-person team than the 3rd person on a 3-person team.

6) What kinds of special needs do small teams have?

Small teams need to behave like small teams, not miniature versions of large teams, because bureaucracy doesn’t scale down particularly well. Small teams need to be led by a project manager that understands the dynamics of small team delivery. Specifically, someone who picks their battles carefully and doesn’t mind getting their hands dirty from time-to-time. Additionally, small teams need to use the best tools available, as they cannot afford to arbitrarily throw labor at problems.

7) Are there particular issues that come when team members are dispersed around the globe?

Small teams should strive for “location transparency”, regardless of the team’s physical locale. Collaborative technology (and the day-to-day practices that support collaborative processes) should be employed whether team members are separated by a hallway or an ocean.

8) What ways can small teams work most effectively to accomplish big tasks?

There are four aspects that drive small-team effectiveness: Planning, Process, Automation, and Asset Management.

• Planning: Small teams need to focus their efforts on understanding how the key moving parts of their project fit together so that they can proactively categorize and manage delivery risk. This is far more important than trying to optimize the workload balancing in your project plan, since you’re not trying to distribute lots of work among interchangeable resources on a large team.
• Process: Small teams should maintain strict adherence to a lightweight process. Individual heroics are not scalable nor predictable over time. Even small teams need to play by the book, but they need to make sure that it’s the right book for them.
• Automation: Small teams need to maximize the amount of work that they don’t do, and focus their efforts on the important stuff. If work cannot be avoided, it should be automated. Computers are really good at doing predictable stuff really fast.
• Asset Management: Small teams should manage their important data using some sort of version control mechanism. A good version control system acts as a time machine in case users need to review and/or compare previous versions of a document or other artifact, and a bank vault to protect a single, current version of the truth for each project asset.

9) I also found the comment intriguing that large teams are usually bands of small teams in disguise, and I’d like your thoughts on that.

We coined that phrase to help decision makers understand the true nature and composition of their organizations, and soften any negative connotations that the “small teams” concept would have in larger organizations.

At the end of the day, projects get talked about by large teams and completed by small teams (or groups of small teams working together).

Any team can make a decision. Only small teams make great decisions.

Any team can do work. Only small teams do efficient work.

It’s true that there is strength in numbers, but sometimes that strength lies in small numbers.

–[END FAKE INTERVIEW]——————————————

One of the benefits of having Approach.Botonomy.Com (A.B.C) up and running is that the A.B.C site is now the repository for much of our reference-worthy content. A.B.C is where we are communicating our opinions and beliefs on topics ranging from the rise of folksonomies in project management to the mainstreaming of dynamic programming languages.

That frees up my weblog for much more casual personal observations and such. A quick analogy: If Approach.Botonomy.Com is the legitimate theatre, then my personal weblog is late night basic cable reruns of Sanford and Son.

Or so I would hope.

So, speaking of of uninteresting things that I do, I was at Costco over the weekend, picking up a few gallons of relish and a 12 pack of fire extinguishers. As I was making my way past a throng of 20 people waiting in line for a spoonful of lentil soup, I ran into a guy that I went to grade school with. He too is working on a online startup. He said that he was looking to launch in 6-8 months and is keeping the concept very close to the vest.

Mmm, stealth mode.

Been there. Done that. Have the “I missed out on important early feedback” t-shirt to prove it.

Now, in all fairness, I had already told my former classmate that my company was in the online app business. Perhaps if I was a podiatrist or was slinging hash at the local Denny’s he’d have been more open, but that’s irrelevant. This is not about being nosy, and I wish the guy and his team all the luck in the world. Rather, I bring it up because it was a moment of clarity for me, as I realized how my views on the nature of the “killer idea” has changed over the last year.

Here’s my current take on running your micro-ISV startup in stealth mode: At first glance, it seems kinda cool. Just like cranking the radio on your car stereo when you’re cruising around at the ripe old age of 16 maybe seemed cool at the time. If you don’t get loud music out of your system early on as a teenager, you’ll do irreparable damage to your hearing.

Fast-forward the clock 20 years, and if you’re doing a small startup and don’t get the mystique of “stealth mode” out of your system early on, you might end up figuratively too deaf to listen for early stage questions, comments, and concerns. Maybe even some that might otherwise have a profound impact on your business model and prospects for a timely success.

In hindsight, I now realize that the incremental benefit that you receive from getting an arbitrary outsider’s initial reaction to your idea far, far outweighs the low incremental risk of someone ripping off your idea and beating you senseless with it in the marketplace.

Now if you’ll please excuse me, I have to run back to Costco.  We are going to have hot dogs for lunch, and l must have left my gallon of mustard in the cart.

Preface: I came up with this “Three Ds” model in a post to a Radio Userland blog that I had written a few years ago. The blog subsequently died on the vine from neglect on my part. Since then, I’ve referenced the concept in conversations a bunch of times, and I have not been able to locate my original posting via Google or other search mechanisms. Since I think that the approach is still relevant, I’m taking the time to re-write it and post the article here for future reference.

I also believe that this model has relevance to the linkjacking that occurs on community sites such as reddit, which I’ll address at the end. So here we go:

There are three things that are required in moving content from the place where it happens to the eyes and ears of its final downstream consumer. These are what I refer to as The Three Ds of New Media: Discovery, Decoration, and Dissemination. The following is a description of each:

• Content Discovery: This is the work of actually finding and documenting a news story, typically performed by the folks who are first on the scene. Traditional media examples include the AP, newspaper staff reporters, and local network news personnel. Online examples include the author of original web content, or the “live blogging” that takes place at events like MacWorld.
• Content Decoration: This is the analytic, opinion, or comedic spin that the Leno/Colbert/O’Reilly crowd add to the story.
• Content Dissemination:This is the act of communicating the content out to the consumer. Note that this is not the same as being an aggregator, since aggregation isn’t always necessary (such as the real-time blogger mentioned above).

Where it gets interesting is that the Three Ds were largely “bundled” when you read the New York Times, or watched the network news. You bought the New York Times newspaper containing New York Times editorial opinions about stories covered by New York Times reporters. Now, given that there are a number of “news sources” to choose from online, the game has changed and one’s selection of news Discoverer, Decorator, and Disseminator are a function of the consumer’s trust levels and preferences. We are living in an increasingly mashed-up world.

For example, there are lots of folks whose insight and analysis I find interesting and/or useful, but I wouldn’t rely on them for sole-sourcing the authenticity of a story. These are good Decorators, but unproven Discoverers.

Conversely, as the opinions of the editorial page have been gradually creeping into front page in our major newspapers, I continue to trust the Discovery but question the Decoration.

And lastly, as it relates to the community-driven news sites, I don’t care who initially posted the content, so long as it is sourced from a Decorator or Discover (or other Disseminator) that I trust.

These relationships have a tendency to chain, given the number of content aggregators and cross-links among commentary sites. There is also often overlap, as many Decorators also own a channel for Dissemination. Rush Limbaugh is the classic case for overlap: his opinion/content is offered exclusively through his broadcast, and his broadcast is dedicated solely to his opinion/content. The AP home page is an example of the overlap between Discovery and Dissemination.

If we are able to look at news through the prism of the Three Ds and differentiate between the sourcing, commentary, and delivery of content, we may pick-and-choose our content providers somewhat freely, while still having an objective basis for ascertaining the trustworthiness of the content that we receive.

As it relates to the community-driven Disseminators (such as reddit, Digg, etc.), there is the ongoing problem of Linkjacking, a practice where someone finds a story, includes a link to the story (and not much else) in their own weblog, and then post a link to their weblog to reddit, in the interest of using public interest in the story to drive traffic to their website, even though their contribution in the value chain is minimal.

I think that the Three Ds approach provides a reasonable litmus test for posting things that you’ve found elsewhere:

• If you are simply Discovering an article that is already available on the web, then you should post the original article, rather than your weblog entry, to reddit.
• However, if you are Decorating the article with some analysis, perpective, or opinion, then I believe that linking to your weblog is totally appropriate, providing that you cite your source for the content in your weblog entry as well.

With this approach, your linkjacker-ness varies inversely with the quality of your Content Decoration. Here, linkjackers in reddit are akin to TV news analysis programs that offer no thoughtful analysis: Market forces will kick in and they will both find themselves off the air due to the empty nature of their commentary.