So why the two-bit summary of a turn-of-the-20th century dispute among socialists?  Simply this: Lenin’s pamphlet paved the path for revolutionaries around the world.  As I was noodling on The Meaning of #Stoos, I re-read it and picked out a few things that change agents can learn from Lenin:

1. Show that you know “What Is To Be Done?”  The title itself is a clear call to change, which Lenin knew would intrigue and inspire his audience.  It also hints that he had the answer.
2. Show that you know the problem  Lenin realized that Marxist theory was a powerful “call to take the field against the enemy.”   But its guidance was so focused on the economics of workers vs. capital  that most volunteers went into “battle with astonishingly primitive equipment and training.”  Success would take a group of professional revolutionaries  using “all the rules of the art” of organizing.  Furthermore, his arguments hit hardest at the premises of his adversaries; in other words, he not only didn’t argue on their terms, he argued that their terms were part of the problem.
3. Professionalization can make change dangerous.   Lenin’s point won the day.  Now just about all revolutionaries prefer professional, vanguard-led organizations.   Even corporate change is driven this way; nearly every transformational project engages professional change experts.  But if small, apparently imperceptible changes can make things worse — Steve Denning has a great product anecdote here — what can happen when professionals turn things upside down…on purpose? 

I’ll get back to this topic later…

That move is not natural for me, though.  I’m more of a rancher than a farmer.   The challenge for me, therefore, is how to accommodate other styles of work. 

To highlight potential role mismatches, I fall back on models like the “finders, grinders, minders” consulting model David Maister popularized.   Consulting comes to mind because I’ve often heard customers say: “I’d like the folks who built it to be the ones who support it.”  That sounds plausible in theory, but that usually involves taking a “grinder” and making him/her a “minder”.  Which rarely works unless that person is explicitly looking to change his/her lifestyle.

A basic governance checklist can catch the type of folly Michael describes. A project that proposes to create an app entirely from scratch — like Michael’s example — should stand out as an initiative to receive heightened scrutiny. Well, it should if you have a set of standards! But that’s another post!

Unfortunately, most of our redevelopment arsenal destroys the village in order to save it.  I’m not just talking about old-school urban renewal with its high-rise projects and sterile plazas.  The mixed-use redevelopment now in vogue tends to a gigantism that overwhelms the character of the surviving neighborhood, even if there’s a nod to affordability in the planning.  On the other hand, single home approaches — think Habitat for Humanity — can fix a house or two.  However, they can stick out like a crude cap on a broken tooth.

Pocket neighborhoods are an intriguing response to this challenge.   They have enough scale to completely repair parts of bad blocks – like a well-fitted crown replaces a bad tooth — while connecting to the still-vibrant villages beside them.   If well done, they also don’t scream “I’m poorly-built affordable housing”!

Leaders must go into performance discussions with a humble heart.  As Dan’s notes, your colleagues likely will be very skeptical about the usefulness of those chats you’re about to have.

1. The “validity” topic focuses you on whether a plan is ready for “prime time”.  Use this when evaluating early stage gates. 
2. The ”effective”  items are obviously relevant as one evaluates the quality of your projects’ execution.  These items should be a part of regular status reporting.

Then learn what “level of effort” means!

What are common obstacles that project managers introduce into projects?

Haste. I like to say, “schedule pressure is the enemy of good design.” During project retrospectives, all too often, I find the primary technical design driver was haste. Not maintainability, not extensibility, not correctness, not performance … haste.  This common obstacle is a silent killer. It is the Sword of Damocles that … when push comes to shove … drives so many important design objectives underground or out the window.

 

Ironically, the haste is driven by an imagined or arbitrary deadline. I like to remind project managers and developers that for quick and dirty solutions … the dirty remains long after the quick is forgotten. At critical moments, haste is important. But haste is an obstacle when it manifests itself as technical debt, incurred carelessly and having no useful purpose.

 

Other obstacles include compartmentalization, isolation, competitiveness, and demotivation. Here’s the thing. Most project managers need to get their team members to bring creativity, persistence, imagination, dedication, and collaboration to their projects if the project is going to be successful. These are the very things team members *voluntarily* bring to the project.

 

Look around the project; anything that doesn’t help and motivate individuals  to interact effectively is an obstacle. Project managers must avoid introducing these obstacles and focus on clearing them.

At the Stoos Gathering we will discuss how to accelerate change in management and organizational transformation.

That’s all?  More seriously, I love the ambition and it it has been great grist for my mental mill, especially these three themes in the documents and discussions:

1. Leaders should change themselves first: A fellow named “Hank” noted this in the pre-gathering documents.  For example, leaders who have not learned to self-forget may find they struggle to build trust.  And putting spiritual traditions aside, those who have not tended to their spiritual armor will find they cannot resist the forces of reaction.
2. “The Problem” will prove a crafty and adaptive foe: Steve Demming notes that “the participants left for a future time evaluations of the best ways of getting from “the problem” to “the desired outcome.”  Wise move, because IMO these “best ways” will have to contend with Anna Karenina Syndrome: “Happy firms are all alike; every unhappy firm is unhappy in its own way.”  The solutions must be viral, in every sense of that word.
3. Beware introducing “corporate managers”: I’ve seen a desire to involve corporate managers into Stoos what Jurgen calls Management 3.0.  That’s great, but some of us are “The Problem” and aren’t self-aware enough to know it (see point one).  I’m especially concerned about two types: those who’ll want to boil it all down to “one particular approach” and those who’ll pick any work product apart as “impractical”, “not actionable”, “unrealistic”, etc.

I would have quibbled with #1 until recently.  A few days ago I saw my (almost) seven-year-old son typing away merrily with both hands.  From hunt and peck to touch typist in a few months…amazing.

Q: Can you give an example or three of how project managers can be “ruthlessly helpful” to their development teams?

A: Here are a few:
1) Insist that programmers, engineers and other technical folks go to the whiteboard. Have them draw out and diagram their thinking. ”‘Can you draw it up for everyone to see?” Force them to share their mental image and understanding. You will find that others were making bad assumptions and inferences. Never assume that your development team is on the same page without literally forcing them to be on the same page.

2) Verify that every member of our development team is 100% confident that their component or module works as they’ve intended it to work. I call this: “Never trust an engineer who hesitates to cross his own bridge.” Many developer’s are building bridges they never intend to cross. I worked on fixed-asset accounting software, but I was never an accountant. The ruthlessly helpful PM asks the developer to demonstrate their work by asking things like “… let me see it in action, give it a quick spin, show me how you’re doing on this feature …”.  These are all friendly ways to ask a developer to show you that they’re willing to cross their own bridge.

3) Don’t be surprised to find that your technical people are holding back on you. They’re waiting until there are no defects in their work. Perfectionists wish that their blind spots, omissions, and hidden weakness didn’t exist. Here’s the dilemma; they have no means to find the defects that are hidden to them. The cure they pick for this dilemma is to keep stalling until they can add every imaginable new feature and uncover any defect. The ruthlessly helpful PM knows how to find effective ways to provide the developers with dispassionate, timely, and non-judgmental feedback so they can achieve the desired results.