Organizational Self Discovery

It was two and a half years ago that Confused of Calcutta ran a great series of posts on Facebook and the Enterprise. JP has now cycled back around to discuss something he’s calling the Facebookisation of the Enterprise. (I know you’re wondering what this has to do with Organizational Self Discovery, just hang in with me for a few paragraphs.)

You see, the game has changed. Now we aren’t talking about how and whether Big Businesses will allow Facebook to operate inside their walls. Now we’re talking about how our experience with social and collaborative tools on the wild wild Net are changing our expectations for how corporate support systems can and should work. Whether Facebook or Twitter are allowed in your company, tools like them are a big part of your employees and colleagues lives, and having a dramatic impact on our understanding of how people collaborate.

In the knowledge management space, its been clear for a long time that the heavyweight command-and-control static intranet KM systems can’t keep up with dynamic, collaborating, active communities. Sure, you might have to use sharepoint or some document management tool to keep up with the latest copies of formal documents. But the actual give-and-take collaboration of figuring out what to work on next and what the answers should be, and the links most people will use to get to them, are better enabled by a grassroots, organic, wiki-like tool. Rather than some central administrator telling you what information you need to digest and in what sort of structure, the community can figure that out on its own.

JP is envisioning a similar evolution in the corporate directory, messaging, scheduling, and information filtering tools we use. What I love about this post in particular is that the ideas come down out of the abstract philosophere and right down to earth. The self registering and self organizing capabilities he describes are easily deliverable right now.

These tools should (and can) help each person easily slide into and out of roles and communities, discover what their interests and needs are based on their current priorities.

I like the fact that in this environment, the binary distinction we make in enterprise systems between Employee and Not-Employee really start to smear out, or blur, into a spectrum of possible levels of community involvement. And maybe enable us to start thinking about smearing out our corporate boundaries as well. And I’m not talking about the “outlook web access”-style portal into the closed organizational world. Our corporate edges need to work more like cell membranes than Great Walls.

I don’t want a PMO to set up a formal project hierarchy, org chart, and mailing lists. I want corporate systems that support me finding who I need based on what I’m trying to do. With self-referential feedback loops that help me learn which connections are most useful and which are not based on others experiences before me.

James Marwood, in a comment over at Confused, says that having tasted this kind of capability will affect his future employment choices. An open, dynamic, collaborative environment will give clever companies a hiring advantage. Like the free soft drinks, sofas, and foosball tables that ’90′s dotcom startups used to compete for the best talent.

Give your company the right tools, and it will discover for itself how to best organize to get the job done.

What is architecture worth?

I first ran across a reference to John Morefield’s “Five Cent Architecture” booth in this New York Times piece. The spin there is all about “out of work architect looks for unique ways to reboot his practice.”  The stories of John (and other out-of-work architects) is a stark reminder of the state of the economy.

But the quick pic (like a visual soundbite?) of an architect sitting under a 5¢ banner got me thinking about the value that we add as systems architects, whether at the enterprise or application level. On every project, on every interaction, how are you adding value to the systems you are working on?

Because too much of the mumbo-jumbo @enterprisey arguments aren’t very convincing even when our employers are flush with cash. And in serious downturns, when we’re trying to wring max value out of every dollar spent, they don’t even pass the snicker test.

You can’t really convince business partners (or IT delivery folks) based only on the long-term value of the ideas you are pushing. Because if they don’t make their short-term commitments they won’t be around to bask in the eventual glory of strategic success. Keynes’ famous observation that “in the long run we’re all dead” applies doubly so to those of us whose careers live or die by our ability to meet immediate project commitments.

As I read John’s 5 Cent Architecture website, I found his two simple rules resonate strongly:

1. Good design should be available to everybody, period
2. No project is too small for BIG ideas

All too often we IT architects want to think about huge, grand, sweeping reinventions of entire portfolios. We have a much harder time thinking about how to make things better right where we find ourselves, in the real live application landscape. Those greenfield re-imaginings happen very rarely, and 90% of an application’s lifetime is spent in maintenance and sustain. How do we keep improving the design even after implementation?

There’s a great Kent Beck quote that I sort of remember going something like “I don’t care whether your system design is good or bad. I care whether, each and every day, it is getting a little better or a little worse. If it is getting a little bit better every day, I can live with a bad design for a while.” (apologies if I’m misquoting or misattributing that one!)

We have to help project teams choose those day-by-day, little-bit-better design decisions. And we have to have the sleeves-rolled-up, man-in-the-trenches, real-world street cred to be included in those discussions.

That’s how we deliver our 5¢ of value every day.

Architecture Work In Progress

The problem

I lead a group of senior solution architects who are supporting application development and maintenance activities across the GMAC Global Marketing Organization. We are spread thinly across the eastern half of the US, and responsible for assisting with and overseeing the work of roughly 20 development and maintenance teams.

The challenge we face is this: How do we track the work that is in flight, and provide a very clear high level picture of who is doing what? Especially in the rapidly changing, sometimes amorphous world of application architecture?
How do you make it easy to visualize and communicate the items your team is working on, and give everyone a common model for the work moving through

In an attempt to address these problems, we have adopted a lightweight kanban-like work tracking board, with index cards that represent discrete assignments and a simple lifecycle that tracks their flow. Kanban originated as a means of optimizing the amount of work flowing through an manufacturing assembly line, and is closely associated with Lean Manufacturing and “The Toyota Way.” Many software development teams have adapted it as a means of managing their work. (A deeper exploration of kanban, why it works, how it relates to lean and other agile practices, is WAY outside the scope of this post but something I’m really interested in. Subject for another post perhaps?)

Intentionally simpler than a project plan or “dashboard,” the kanban board gives us a single easily digestible view of what’s in flight and what’s coming up, where are resources are allocated and what the key bottlenecks and issues are.

The Cards
In a kanban development approach, each card in the system represents one or more user stories, or a feature that the team is working on. In a development lifecycle, you might have stages like Requirements Definition, Analysis, Code, UAT.

In our simpler Architecture kanban we’re using cards that represent discrete assignments or deliverables that an architect is working on. Typical cards might be “Billpay ADD,” or “Universal Customer Profile Discovery,” or “Anti-Money Laundering RFP.” Note that architects get asked to participate in many different kinds of efforts, attend lots of calls, and provide opinions on many topics. Not every Architecture request goes onto a card. A card has to represent a significant chunk of discrete work, with a concrete deliverable at the end.

Because there are many different kinds of work represented by the cards in our system, we’ve adopted an extremely simple lifecycle. There are four states that any card can be in: In Queue, In Progress, Done, and suspended.

As we mature the practice I want to add other metadata to the cards: when the work was defined, when it was begun, when it was expected to be due, and when it was actually completed. This will allow us to calculate important metrics about the process, including Cycle Time and On Time Percentages.

Finally, to really “grow up” and be a mature kanban system we would evolve WIP limits, which would be a chokepoint beyond which we couldn’t accept more work into the system. Until we are truly limiting the amount of work in the system at any given time we aren’t really leveraging the power of a kanban approach. One of the key elements of a true kanban system is that work is “pulled” into the system as architects finish other items. In our case work is still pushed into the system, and we’re still spreading ourselves thinner and thinner in an attempt to cover it.

But we need more experience understanding how much load we can manage, the ideal “card size” (eg: amount of effort per card), and the capacity of each architect on the team.

The Board

We’re using a wall in the office as the “system of record” for our work tracking. Index cards are labeled with each of the steps of the lifecycle and arranged in large columns. Other (sometimes smaller) index cards are labeled with each work item, and placed in the appropriate column. If an architect has been assigned, his/her name is also added to the card.

We cluster the cards in horizontal rows based on the assigned solution architect, although you might choose to cluster based on class of service, or type of engagement, or some other factor.

Because many of our architects (and stakeholders) are not in the same office, we also maintain a virtual kanban board in visio.

Anyone on the floor can walk by at any point and see the current state of our workload. I send out a weekly version of the virtual visio kanban board.

The lifecycle stages
In Queue
Items are In Queue when they have been identified as upcoming pieces of work but they are not yet defined or funded, or have not had an architect assigned to them. Sometimes items sit In Queue for several weeks and then move directly to Suspended because they never get off the ground.

In Progress
Items are In Progress when they are being actively worked. They can move from this state if they are completed, or if they are suspended.

Suspended, Done
The terminal states for work items are Suspended or Done. Items accumulate in these states throughout the month, and then get cleaned out (and, when we get more mature, archived) on a monthly basis.

Status reports
Each week I get status report updates from the solution architects. These should reflect the major accomplishments or issues for each item in the In Progress column assigned to that architect. I consolidate these into a group status report that goes out with the weekly WIP chart email. If we go a few weeks without any updates on an In Process item, I know to start getting skeptical about whether it is still really active.

Benefits

Customers (especially BIO and senior staff) have a clear view of all that we are working on.

Each Solution Arch can easily look and see what his/her teammates are working on (so collaboration opportunities are easily identified)

We have a consistent story about what we’re working on, and keep our commitments to our customers clearly and concretely tracked in a shared model across the team.

Eventually we will start to get valuable metrics like Cycle Time, Defect Rates, and On Time Delivery Rates

Zero Inbox

Email has serious limitations as a communication tool (and even moreso as a collaboration tool). In addition to the ever expanding CC: list, the difficulty of re-reading the whole email chain, and the challenge of bringing multiple lengthy email chains to any closure, there is an issue of karmic debt in email. It is extremely easy for me, without thinking about it very much, to fire off an email to 20 people asking a few poorly formed questions. It could easily cost the company hundreds of man hours of effort if those people actually send me meaningful responses. The situation quickly degenerates into a sort of asymmetric information warfare: my thoughtful responses can just generate a new flood of casually fired off questions until we all just get tired of the topic.

But, in the words of Arlo Guthrie, that’s not what I came to tell you about.

I came to talk to you about your inbox. Or mine, anyway. Because the result of the process described above is a bloated, terrifying, out-of-control inbox.

The other day, I overheard someone on Twitter say that “Your inbox is a To Do list that other people write to.” But in fact it is much worse than that. Your inbox (if it is like mine) is a huge mishmash. Some of it is actions that people are trying to write to your To Do list. But the rest of it is general commentary, status reports, vague questions, notifications of corporate programmes or policies, feedback on things you’ve done, jokes, etc, etc.

You don’t want to just ignore it all. There are some things that require your attention. The question is, how do you separate the wheat from the chaff? So you spend your free minutes between meetings desperately paging through your inbox and hoping there are no time bombs ticking in there.

One of the GTD insights that really resonated for me is value of separating processing your inbox from actually acting on it. There are various flowcharts and diagrams for how this should work, but the basic principle is that the only things in your inbox should be things you haven’t looked at yet. At least once (but preferably more than that) you should process every item in your inbox, delete the stuff that’s not needed, sort the rest out into things you just need for reference, and things you need to actually act on. Then you’ve achieved Zero Inbox. No cherry picking allowed, you want to go top to bottom and sort them out based on the following process:

• Start at the top.
• Deal with one item at a time.
• Never put anything back into ‘in’.
• If an item requires action:
•             Do it (if it takes less than two minutes), OR
•             Delegate it, OR
•             Defer it – by moving it to a folder that specifically holds things you need to act on.
• If an item does not require action:
•             File it for reference, OR
•             Throw it away, OR
•             Incubate it for possible action later.

It sounds impossible, and the first time you do it is extremely intense. The key is being ruthless, not getting distracted, and not letting too many “woolly half-thought requests” stop your progress. If an item doesn’t have a clear concrete action, then file it immediately. Having looked at it and thought about it, your subconscious will continue to boil it down, and if there is a specific action it will crystallize for you later (and you’ll catch it in your daily or weekly review). You might even have to set aside ½ day or more for the first time. But once it is done you’ll find it incredibly addicting and energizing. Once you get ahead of it, you’ll never want to go back.

This practice doesn’t stand alone. It only works if you have a strong system for tracking/managing the actions your are delegating and deferring and filing reference material for later use, and it is much easier if you figure out how to best use Outlook and various other tools that make it easier. But those are topics for future posts!

“Bottom of my inbox!” (or BOMI) becomes a cry of liberation. You’ve cleared the decks, you know what people are asking of you, and now you’re ready to make decisions about what to act on.

Targeted advertising… am I missing something?

Ok, so targeted advertising, its the holy grail of how companies on the web are going to make their business cases work, right? There’s lots of cool technology out there, including APML <insert lots of relevant links here> that promise to do a fantastic job of capturing my interests so that I can easily move my “attention” from site to site, and not have to keep re-entering the books or subjects I am interested in, etc, etc.

One of the big supposed “selling points” of this kind of technology is that it would enable much more specific targeted advertising. “Wouldn’t it be nice,” the pundits say, “if advertisers could present relevant material that you would find interesting and compelling, rather than having to wade through ads that you’re not interested in.” Certainly from an advertiser’s perspective, this makes sense.

But from my perspective, I’m not so sure. Imagine if every web page you visited had an ad for some amazing, sophisticated (read: expensive and high margin) product that you just felt you absolutely had to have. And imagine that the marketers have enough insight into your interests, hopes, and dreams, that they can present you with a deliciously compelling pitch with every page.

Would that be a good thing?

I guess I kind of have a predator/prey model for advertising, where I’m the prey. The advertiser’s goal is to create a desire in me that I didn’t have before, and then meet that desire by selling me products or services. My goal (as prey) is to avoid those pitches so that I can conserve my cash for more important things — long term savings, important personal development/projects, educational opportunities for the kids, etc.

Maybe I just have some sort of unhealthy addiction around gadgetry and spending money. But when I get fixated on an electronic toy, musical instrument, etc, etc, it just creates the desire to buy one more damned thing that I really don’t need. What’s the line from Fight Club? “They’ve got us working at jobs we hate to earn money to buy things we don’t need.” It happens that I actually really like my job, but that’s not the point.

The holy grail of targeted advertising is the demonic ability to read my deepest subconscious desires and present me with temptations I can’t resist. I’m not sure I want to help that along. And I’m not sure I’d want to visit a site with the uncanny ability to make me want more every time I visited it. I might rather get presented with ads for rental car deals, credit recovery services, and dating agencies. That way I can ignore them at will, and get on with whatever the actual reason is for visiting the site.

But that’s just me. Maybe I’m weak.

Watching Fight Club… Again!

I’m in the Charlotte airport waiting on my flight back to London. I’m sitting in the US Airways lounge, watching Fight Club for I guess the fifth or sixth time. I’m amazed to still be noticing new things.

For one thing, I picked up a pair of the Bose in-ear headphones to feed my iPod addiction. Maybe it’s that this is the first flick I’ve watched with these, but the sound design in Fight Club is just amazing. I am noticing all kinds of interesting ambient sound, atmospheric clues to what’s coming. It’s amazing that in a movie this “over the top” there is such attention to the tiny little details.

Does anyone think that the fact that “Jack’s” power animal is a penguin is some sort of Linux reference? And what does it signify that the penguin says “Slide”?

Marla’s walking through traffic with stolen jeans, I’m ducking in my chair worried I’m going to get run over.

Ever notice how in the scene where Jack imagines the mid-air collision, the stewardess gets struck in the head and leaves a splatter of brains and blood across the blank whiteboard conveniently placed at the front of the aisle? It’s only there for a second, maybe less, but what an incredible addition to the scene!

Matrix exegesis

I followed a headline about the upcoming Kuzweil film about the Singularity, to his personal website, to this really interesting post exploring key questions/topics in the Matrix films.

After the (IMHO) disastrously disappointing 2nd and 3rd movies, it’s refreshing to see a reasoned, careful discussion of issues from the movies.

Community needs and goals

Thanks to the reference at Confused, I am reading Amy Jo Kim’s book Community Building on the Web, first published way back in 2000. It is currently out of print, but you can purchase a PDF download from Peach Pit Press. It is an analysis of what makes on-line communities tick, and how to design them successfully. I like her perspective that an online community is a living, breathing, organic entity, not something that can be mandated or regulated very effectively. She is writing from the point of view of Internet communities, where this is expressly true. I just so happen to believe that this is equally true for intranet communities. Certainly, we have a lot more control over who signs on to an internal platform, and we can threaten much more significant consequences for members who misbehave. But it doesn’t take very much overly strict authoritarian mandating to regulate the life right out of these communities. Instead of a vibrant, rich, collaborative community, we can all too easily end up with an empty, stiff, formal ghostland of corporate-approved content.

I have just been reading a section titled “Needs and Goals: A Three Step Planning Exercise.” Kim outlines a very pragmatic approach to listing out members’ needs, listing out owners’ goals, prioritizing them and analyzing for overlaps, synergies and conflicts. And then publicizing the specific set of needs and goals you are trying to meet with a specific release of the community platform.

It is ironic and sad when people building communities miss this point. Too often, large companies who “get the message” about the opportunities for collaborative content creation run massive projects to implement extensive collaboration platforms for employees but don’t ever stop to think about what employees will actually use the platform for. Or they treat the entire employee base as one giant undifferentiated community.

Certainly there can be communities that grow to the size of a large employee base, but they almost always start small and grow organically. And along the way, they probably change their focus and direction.

“Broad brush” community building efforts that try and address a huge group’s needs all at once are at risk if specific community needs aren’t considered. What will motivate community members to use the platform, and how can adoption be driven within specific communities?

What if you implement a collaboration platform and no one shows up? Usually the failure will be chalked up to “immature technology,” “lack of a culture of collaboration,” or “it was just a bunch of internet hype anyway.” The truth is that cultivating communities is an art, and it requires considering the individual members and their needs and goals.

Social Networks and the Monkeysphere

A few dots connected for me this morning. This time, the connections raised more questions than answers… but, hey, those are always the most interesting dots anyway, aren’t they?

I followed a link from SecondLifeInsider to an article in CNN about griefing, to a wikipedia article about Dunbar’s Number. Primatologists analyzing the size of social groups in primates noticed that the size of the troop is directly related to the size of the brain. They theorize that this limit represents the mazimum number of meaningful social connections that primate neurology can manage. Based on human neurology, the anthropologist Robin Dunbar extrapolated that for humans this limit is around 150.

That would suggest that an average human cannot maintain meaningful connections and relationships with more than 150 people, beyond that perimeter people stop being people and start being (at best) 2D stereotypes and eventually just statistics.

There is a hilarious (and totally irreverant) discussion of this topic Inside the Monkeysphere. “Inside” the 150-person limit we can create meaningful relationships. We’re fundamentally wired to treat people “outside” that limit dramatically differently.

Whether you agree with the science, or believe that 150 is the right number, it is conceptually sound that there is a limit to the number of rich social connections we can maintain.

Then when I read JP’s latest Facebook and the Enterprise post about online communities, it made me wonder about the relationship of the internet in general, and social networking tools like Facebook, LinkedIn, MySpace, Bebo, etc, etc, and our limited neurological capacity for meaningful relationships.

Do these tools provide some sort of scaffolding that helps our constrained monkey brains manage a larger number of “real” relationships? Or do they just help us keep track of connections that have little or no substance? Or do they help us continually “upgrade” the 150 active connections we maintain so that they’re very high quality? Or just so that they are highly aligned with our own views?

How do we keep the noise of hundreds or thousands of facebook or linkedin “friends” from swamping the signal of the connections that really matter to us, that really add value?

I wonder what research has already been posted in this area?

Role of the manager in an agile enterprise

JP at Confused of Calcutta has been making an interesting and entertaining run of posts about Facebook and the Enterprise. The latest is focused on the idea of using a social networking platform like Facebook to inform a role-driven induction process for bringing new hires up to speed. The idea is that it would be much more interesting and useful to know what a previous player actually DID in the role (assuming, of course, that the previous player was performing well) than any sort of formal academic description of what the role SHOULD be doing.

This argument resonates strongly with me, although I’m not convinced Facebook is the right model. There are social networking tools that specialize in forensically evaluating email and chat patterns and other artifacts of interaction that are more in line with this idea of documenting what a leader actually does. Who they interact with. What meetings they attend. Etc.

But I didn’t want to post about that tonight.

I very strongly connect with the almost throwaway reference JP makes to Max De Pree’s definition of leadership, namely that

• The first job of a leader is to articulate strategy and vision.
• The second and last is to say thank you.
• In between, a leader should be a servant and a debtor to the led.

It’s that third bullet that got my attention. Because I so wanted it to be elaborated on. Perhaps De Pree does exactly that in some of his work, will have to take a look.

My thinking on the subject is probably infected with too much exposure to Bionomics in the mid ’90′s, the idea of the economy (and the organization) as an ecosystem. The infection was exacerbated with some amazingly successful experience with eXtreme Programming later in the ’90′s, watching the incredible things that teams could get done, the almost synchronistic, catalyzed, emergent behavior that delivered outstanding results and created a fantastic work environment as a great side effect.

It used to be that the manager had to assign, monitor, and assure completion of specific tasks. The manager, in this “traditional” example, needed to be better in the execution domain than anyone else on the team.

The world that I was experiencing starting over a decade ago was an agile organization where the manager had a very different role:

• Craft a mission for the team that made it a viable actor in the organizational ecosystem
• Make sure to get “the right people on the bus” (in Good To Great speak)
• Act as a park ranger or steward rather than a manager, making sure the processes in the team were staying in balance
• Keep a weather eye on the rest of the organization to evaluate how the original mission was working and whether the ecosystem was changing
• Keep the corporate entropy and chaos (and bureaucracy) from getting in the way of amazing results (kind of like how the ozone layer keeps harmful solar radiation from destroying life on earth)

I used to describe this as “carving out a space in which the team could ACT LIKE it worked for a rational company.”

I wonder how this relates to De Pree’s work.

And although the word Agile is tired these days, this leadership style is still at the heart of the extremely effective organizations we’re encountering every day.