Architect or Circus Clown

With titles like Architect or Circus Clown, how does one figure out what others do? The easiest way is to

1. Ignore the noun (title).
2. Find out the verbs ASAP.

I read a post on a Microsoft blog from a guy -- a Microsoft Enterprise Architect -- who was venting on the misappropriation of the title Enterprise Architect. His ennui centered about the branding of the title Enterprise Architect and how he is more than a mere Enterprise Architect.

Titles are Silly
 
Organizational titles are silly (cf. Architects & Agile Like Zen Monks & Cell Phones), but they do have nominal value to an organization (e.g., titles are handy for assigning pay grades). Titles like Enterprise Architect are misleading if one pays attention to such things, and meaningless if one cares to dig deeper.

If titles are misleading, what about roles? I find roles have the same shortcomings as titles.

There is an applicable lesson found in Eastern and Western cultural differences that Richard E. Nisbett tells us in an excerpt from his book Intelligence and how to get it: why schools and cultures count

When we presented people with three words such as cow, chicken, and grass, and asked them which two go together, we got very different answers from Easterners and Westerners.

Americans were more likely to say cow and chicken go together because they are both animals; that is, they belong to the same taxonomic category.

Asians, however, focusing on relationships, were more likely to say that cow goes with grass because a cow eats grass.

It seems Westerners have a penchant for objectifying the world. Nisbett’s cultural finding reminds me to move past objectifying nouns. He reminds me to find the verbs, the story, the narrative. To understand a team member's narrative is to understand what they do.

I am programmer contracted for projects. I face the do question with each project. Once I find out what others do, I determine what I can do to help. I can wear different hats, and given time, I can juggle them if necessary - but, it's all in the cause of doing.

On a new project I'll ask What do you do?
Most people respond by saying a title or a role such as, I’m a Senior Software Engineer; I’m an Senior Enterprise Architect; or I’m a Senior Product Owner, etc.

I will then follow up with, So, what do you do?  Sometimes I repeat the question again, Yes, but...what do you do?

It is challenging for people - who might never have thought about it before - to create a narrative around what they do.

If I have to cook and wash bottles, will you at least put Chief in front of my title?

An Admission

After eschewing titles, I admit I would like to put Circus Clown on my resume like Derek Sivers, founder of CD Baby, does. But, unlike Sivers, I have never done circus work. Plus, I'm too honest to fib about such as esteemed title.

Leader From Thin Air

He's a born leader. I don't buy it.

Leaders come from thin air. Leaders are people infected with an idea who make others jump the chasm of doubt and ridicule.

I've had some good ideas, but FAILED to lead them.

Here's a reflection on progress and movements, and the role of leaders & followers.

Yin and Yang of Leadership

Progress lives or dies on the yin and yang of leader and follower. Today one leads, tomorrow one follows. Leadership is NOT permanent. Leadership is transient. Sometimes one is compelled to be an enthusiastic leader. Sometimes one is inspired to be an enthusiastic follower.

Leaders and followers have the same qualities. Number one is they both can recognize a good idea.

Leaders and followers are essential to progress. Without followers, there’s no movement. Without leaders, there are no ideas.

Leadership Defined

Leadership is the ability to bubble up, and publically champion, ideas that others feel compelled to follow.

Characteristic of a Leader

Leaders seem to be that slightly off-beat person bursting at the seams with enthusiasm about an idea that’s waaaay too good to ignore.

This idea is so good, I can't seem to get any sleep over it.

Management & Leadership Distinction

Historically, managers control.  Leaders inspire.

Placing Management and Leadership on a Venn diagram, I’m not sure they’ve ever intersected in the communities I have inhabited. 

We are in a period where Command & Control Management is a rapidly metastasizing cancer. The prognosis is good because my notion is that a percentage of the attrition is being backfilled with Facilitators or re-purposed Managers.

The reason so many organizations hire consultants as coaches is that they’re trying to re-purpose the water-logged dead wood of command & control managers into wave-bobbing buoys (facilitators).

Facilitators create non-threatening conditions where a team of people are free to try slightly crazy things without fear.

Contemporary Challenges

• The speed at which movements go viral
• The din of new information makes it challenging for leaders to find a forum suitable for engaging others.
• The realization and acceptance that one will never be a permanent leader.

To Lead a Good Idea

I have FAILED to lead my best ideas. Upon reflection, to lead the next good idea, I want to

• Understand how ideas and movements “go viral” - then determine how it applies.
• Be public about the idea knowing that enthusiasm must infect people.
• Be courteous to naysayers, but not court them.
• Attract, welcome, engage, and sustain Derek Sivers' concept of First Followers.
• Convince First Followers that they make the idea live or die.
• Find First Followers who can teach others.
• Get to the equilibrium of co-ownership ASAP

Acknowledgment

These ideas are inspired by Derek Sivers' 3-minute TED talk Leadership Lessons from Dancing Guy.

David Koontz emailed me a leadership philosophy questionnaire with questions like: Do you make a distinction between management and leadership? If so, what is it? David's series of questions guided me in arranging my thoughts.

To be concise in my critique, Alan Cooper coached me to use the phase Command & Control Management, rather than the blanket term Management.

 

Leaders Yes, Managers No.

I ignore people writing about, or yapping about leadership because my long-standing bias is that these TAG Body Spray-ed charlatans are fleecing $9.95 from hoofed ruminant suburban TV viewers for a CD full of snoring bromides.

At least with this blog post, you get what you pay for.

I agree with some-time circus clown Derek Sivers when he says

Leadership is over-glorified

I have long confused leadership and management.

I bristle at being managed. I can abide being managed by someone if they are mensa-scale smarter, or more experienced. But in collective modesty, our ability to figure out how to proceed is as Garrison Keillor would say, slightly above average. If all goes well, we can persuade everyone to work as a team of equals lending talents to the effort. I believe in self-organization. Other biological systems to it, why can't humans?

Here's the thing

Leadership is some nut inspiring me to do crazy shit. 

while

Management is a lamp shade blocking my light. 

If someone hasn't done it already, let me say without equivocation command & control management is dead.

Management  & Leadership have never intersected on any Venn diagram universe I have known. One's about control. The other is about inspiration. I don't know about you, but I ain't having the control shit.

Are most innovations born in environments of control or inspiration? Easy question.

Leadership Lessons from Dancing Guy

Derek Sivers' Leadership Lessons from Dancing Guy is an inspiring must-be-seen 3-minute video



Derek's salient observation is that

The first follower transforms a lone nut into a leader.

This simple observation was a slap on the head from Captain Obvious. Sivers espouses the First Follower idea.

If the leader is the flint, the first follower is the spark that makes the fire.

Sivers is also the first person to explain how cultural movements get started that made sense.

Coca-Coda

• The leader embraces the First Follower as an equal. 
• The First Follower transforms a lone nut into a leader.
• The First Follower calls his friends to join then publicly shows everyone how to follow.
• Being a First Follower is an under-appreciated form of leadership. 
• A few more followers joining the movement stokes momentum.
• Sustainable movements eventually reach something akin to Gladwell's Tipping Point.
• As more people jump in, it's no longer risky

Before you know it Bob's your uncle - you've got a movement. We need leaders and we need early adopters bold enough to jump in even if it invites ridicule from peers. Today, a software generated experience might well be the wood pellets that stoke a movement somewhere, but it won't happen without inspired people - crazy nuts and emboldened followers alike.

More

Read the full text of Derek Sivers' TED talk in his blog post Leadership Lessons from Dancing Guy.

Acknowledgments

• Derek Sivers keeps saying stuff that makes sense to me.
• Also, thank you Alan Cooper for the subtle coaching to replace management with command & control management - which is a concise way of saying what I meant.

Professional Advice & Finger Food

The day I turned 50 an AARP application arrived in the mail. Screw AARP. One advantage of being a gray beard is that the Ski Patrol lets you stray outside the ski area boundaries without bothering to check your pack for an avalanche beacon or a shovel.

The Ski Patroller assumes you've had a good life and is comfortable knowing that hypothermia is a pleasant way to die. 

The other advantage is that one earns the right to give advice knowing it's rude for polite folk not to listen to gray beards.

Professional Advice

1. Be Flexible
2. Cultivate Humility
3. Question Assumptions

Be Flexible If someone gives you a doll-house-sized white plate attached to a ring, then make a tiny sandwich and call it finger food. Longevity in the work force depends on Yoga and Jujitsu rather than Power Lifting grunts and Bruce Lee theatrics.

Make it a habit to be flexible, agile, and accommodating. You might think you're destined to be a tennis ball...

I think Pringles original intention was to make tennis balls... but on the day the rubber was supposed to show up a truckload of potatoes came. Pringles is a laid-back company, so they just said, "Fuck it, cut em up!"

   ~Mitch Hedberg

Cultivate Humility One could spend a life seeding and watering humility, then never have a bumper crop. That's okay. The penultimate in humility is an okay crop. The ultimate in humility is its dastardly flip-side hubris.

You'll probably never have the right amount of humility. Still, you can be diligent about weeding out hubris.

We are all one black swan from being homeless.

   ~Bobtuse

Toyota's hubris is about to tank its quality reputation (see How Toyota Can Find Its Way Back). The black swan of electromagnetic interference that seems to be causing gas pedals to stick has Toyota engineers scratching their heads and Toyota management too proud to fess up to systematic flaws.

Question Assumptions Be as pesky as a corn-stealing crow with assumptions. It's human nature to be lazy so most of us formulate strategies based on notions and whims, rather than on data. Is what you think is true really true?

If we worked on the assumption that what is accepted as true really is true, then there would be little hope for advance

   ~Orville Wright

Usually data are better than notions and whims. VP of Search Products & User Experience at Google Marissa Mayer expresses a familiar Google mantra,

Data is apolitical. 

Of course, data might be biased, misunderstood or misapplied. If your assumptions are based on data, are you collecting the right data?

There are assumptions made in this seemingly far-fetched laissez-faire capitalism scenario:

First sharks grow legs to become LAND Sharks. Then LAND sharks morph into LOAN sharks. These LOAN sharks offer unsecured loans to unsuspecting consumers at astronomical rates by burying the terms of the loans in fine print.

Implausible? Perhaps. Yet stranger things have happened.

Most things we consider to be facts are little more than hypotheses that have yet to be disproven.

Software Value Verification

Software value verification is a new concept for me.

Is the agile community paying attention to verifying value in software? Not so much.

I have been trying to get my arms around measuring value -- having been inspired by what David Hussman and Jeff Patton have been calling Discovery in road-shows stretching from Minnesota to Mumbai.

In the post We're Fast, We're Not Cheap, But Are We Good? I paraphrase what David opens with in his Discovery & Delivery meme:

We've gotten good at delivery at the expense of discovery

Discovery is discovering what your user community, or your investors, value about your software. Why does this matter? Because few teams have devised a verifiable method of tracking it.

Discovery is an equal partner to Delivery in our mission as programmers since

It doesn't matter how fast we deliver if we deliver junk.

Concise Definition of Value

The concept of value can be squishy. To be clear, my use of the word value is limited to 

• Satisfaction in the user community your software is used in, or 
• Satisfaction in the investment community staking your software. 

High Value = High User Community or Investor Satisfaction.

If Discovery is what the agile community needs to improve upon, then verifying value is something we need to determine how to measure.

How do we know the software we're building provides the most value to our user community or our investors?

Direction Component in Velocity

When David questioned the utility of the iteration dashboards our community has become so enamored with, I realized that most teams assume they're tracking velocity, when at best they're tracking speed.

Do you think we measure direction as well as speed? Our backlog is supposed to comprise direction (e.g., encompass vision and priorities), but I contend we measure speed under the delusion of velocity.

Most of us – particularly product owners - don't have a clue what the right direction is because we haven't the time to understand the people using the software (i.e., the people supposedly deriving value).

We are not measuring where the proverbial rubber meets the road. Say for example our software is a social networking site, simple value measures might be

1. How many members did we enroll,
2. How engaged are they on the site,
3. How good are we at retaining members and fostering brand loyalty.

Criteria like these might give us more more sensible and verifiable direction. I long to talk about these criteria in a retrospective, rather than pat ourselves on the backs over how fast we completed stories.

The Earth is Flat

If the well-intentioned people prioritizing the backlog had a verifiable grasp of the value delivered to the user community, THEN we might have the component of direction in our Velocity. It has been my experience that the people prioritizing backlogs are making wild-assed guesses based on scant data.

It's easy to say we're all paddling in the right direction, until we paddle ourselves off the edge of a flat earth. 

We are good at patting ourselves on the back in retrospectives simply because we've completed things. We are not forthcomingly introspective about the value of what we've completed.

Raving Applause?

Do users or investors rave about our software? Sadly, none that I've built. I am either a crappy programmer or I am disconnected from whatever value the users or investors derive from the software I have helped to build.

Sidebar

The Google News team was nearing their debut release. Six engineers respectfully disagreed over which feature they had time to include in their first release. Three engineers vehemently supported Search-by-Date. Three engineers passionately supported Search-by-Location. Deadlock.

Google VP Marissa Mayer made the decision to polish up existing functionality and not add new functionality. So they released Google News without Search-by-Date and without Search-by-Location! Shortly after the roll-out, they were bombarded with emails asking "How come I can't Search-by-Date?"

Email requests were running about 100 to 1 for Search-by-Date over Search-by-Location.

Guess which functionality had top priority in the next iteration?

Wrap a Bow on it

The Google News story demonstrates verifiable direction change. Contrast this with the wild-assed guessing we've grown accustomed to and grown complacent with. There's no comparison to butts-in-the-chair data for verifying team direction.

This is the verifiable direction we need to evolve toward.

The Interaction Design community has much to teach about understanding users and providing trackable investor value. I want to learn more about persona development, A/B testing, eye-tracking studies, feedback experiments, and the like. Google runs from 50 to 200 experiments at any given time on their websites around the world (e.g., test of a new Google News homepage design).

I would like to obtain and act on user feedback rather than being steered by the whims and notions of a user proxy (i.e., Product Owners). I want to identify meaningful measures and avoid what Eric Ries calls vanity metrics.

We're Fast, We're Not Cheap, But Are We Good?

Using the software term Sprint Velocity, I've mistaken Velocity for Speed for several years. Truth is, when I think of a treadmill, I might be confused about Speed too.

Speed and direction define Velocity. On the dashboards the software community is so enamored with, at best, we depict speed. Direction is mysteriously absent without leave (AWOL).

With Direction AWOL...

If you don't know where you are going, it's easy to iteratively not get there.
       ~David Hussman, 5:40 PM Nov 3rd, 2009 from TweetDeck

Good at Delivery, But Not-So-Good at Discovery

I have programmed with development teams that range from pretty good to pretty stellar vis-à-vis rapid incremental product delivery. But the products we built could have been better - particularly if we had been better discovering what our user community valued about our software.

The consensus at Code Freeze 2010 and DevJam's developer Jam Session last night is that few of us have much of a clue about the people trying to accomplish things with our software.

Many projects cling to monitoring speed, but that's not good enough. It reminds me of lyrics from the Steely Dan tune Babylon Sisters.

Well I should know by now
That it's just a spasm
Like a Sunday in T.J.
That it's cheap, but it's not free

It doesn't matter how fast we deliver if we deliver junk. Are there ways to measure quality? The Interaction Design community says so.

My Pet Product

I am laser focussed on a pet product. I want to experiment with giving my future user community a place at the table in iteration planning. I want my future user community to help us prioritize the product backlog.

I want to be abundantly transparent to them that their suggestions are acted upon and not ignored.

The cheapest and most direct measures of quality I have considered for this particular product are

• How many community members can we enroll? 
• How active are they? 
• How long can we retain them?

Enrollment, Activity, and Retainment are the legs of this product's stool.

Averting Usability Calamity Software

Can Usability Calamity Software - you know who you are - be averted by paying better attention to users?

What would the measures of quality be for your pet product?

Credit Due

Most of the observations I make about software these days -

the notable exception being giving the user community a hand in prioritizing incremental improvements

have been adapted, or stolen verbatim, from the folks on my software luminaries list. The gist of this post is derived from things David Hussman has said (and I probably mis-understood).