Skip to content

Organizational Self Discovery

January 28, 2010

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?

January 24, 2010


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

January 21, 2010

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.


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

January 28, 2009

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?

December 21, 2007

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!

December 3, 2007

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

November 14, 2007

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.