Lenin and Driving Change

When Vladimir Lenin posed this question in 1901, socialism was riven.  Most early Marxists believed that the core prediction of Marx’s theory — an inevitable proletarian revolution — was just around the corner.  But by the turn of the 20th century, the revolution appeared farther away than ever.  If anything, the contradictions among the classes were cooling in advanced capitalist states, not boiling over.  

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

Ranchers and Farmers…living together!

Nice post here by Hass Chapman on hunter-gatherers, play & software development.   I can definitely relate to the way of working outlined.  While we were hunter-gatherers, we did take to agriculture eventually. 

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.

Great example of value of architecture governance (RT @mkrigsman #CIO #entarch)

Michael Krigsman received a lot of good feedback on his post about getting IT and business together. The second point was top of mind as we’re standing up new and improved architecture governance.

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!

‘Pocket Neighborhoods’ For Sustainable Suburbs

I loved this Atlantic piece about “pocket neighborhoods”, though the suburbs weren’t the application that first came to mind.  This design philosophy appears perfect for those “blighty” neighborhoods I see in town, just off the core.  They’re often convenient locations that become marginal because of a dodgy block or a rundown house (or three). 

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”!

Rethinking Performance Reviews for 2012

Dan Markovitz at Timeback reminds us that performance reviews are a dangerous exercise. Even if we grant their utility,  they have a profound credibility gap to bridge.

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.

Guidance for building a credible plan

Glen Alleman suggests that you download this and put it to work on projects.  However, for some the defense focus and jargon are daunting or off putting.  My suggestion for putting this guidance to work: first transform the tables into a checklist or two. 

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!

Interview: Common obstacles PMs introduce

This question — about problems project managers impose on their projects — wraps up my interview with Stephen Ritchie (@ruthlesshelp, blog here). author of Pro .NET Best Practices (Amazon paperback & Kindle, Barnes & Noble).    Remember that Stephen describes a promotion to get 40-percent-off his book at his blog here.     I hope you all found it as interesting as I did:

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.

A few thoughts on Stoos

I’ve enjoyed the bits and pieces of Stoos I’ve picked up, mostly via Jurgen Appelo‘s summaries (the discussions at the LinkedIn group have been valuable as well).  For those who aren’t familiar with the Stoos Gathering, the goal was modest, but the topic was bold:

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.

Ten things that the info revolution have made obsolete

Here’s a list from Forbes of things that kids won’t need to worry about because of the modern information revolution. 

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.

Interview: Ruthlessly helpful project management

Continuing my interview with Stephen Ritchie (@ruthlesshelp, blog here). author of Pro .NET Best Practices (Amazon paperback & Kindle, Barnes & Noble).   Also, Stephen describes a promotion to get 40-percent-off his book at his blog here.    We turn to the project manager’s role:

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