Wednesday, February 24, 2010
I predicted this
I predicted this would occur last year.
OK, it wasn't a really tough prediction. Americans love the underdog. They hate the big guy. We're funny that way. When Google was an up and comer, everyone loved them. The more successful they get, the more people want them to loose. Strange. The same stuff that makes you a hero will ultimately damn you if you get too good at it.
For the record, I think this is crazy. Google is doing the right thing. Just like it was crazy to criticize Microsoft for being successful, it's crazy to do the same thing to Google.
ITA
Tuesday, February 23, 2010
Change is a Value Precursor
OK? Ready?
From gold made into jewelry to a consultant putting words on a page, the act of creative construction or destruction requires change. Therefore, change is by definition a value precursor. If you do not change something, you cannot add value.
This statement is not true in the reverse. Change does not imply value. Not all change is good.
"So what?" you say.
So, as an architect our job is to be a change agent. By definition we change things in order to create value. The value we create is by creating new objects, processes or artifacts. These changes can result in value to the business if we do our job very well. They can also become shelfware and provide zero value. This is the choice we make as architects.
As you view your architectural domain, think about the broad array of changes you COULD make. Then construct a system that allows you to make good choices by evaluating the impacts of those changes to the business. In most cases, the choices are not simple. Otherwise, the positive change would have already been made long ago. There are usually pros and cons for each choice. The cons are usually painful and sometime involve sacred cows within the organization that everyone is afraid of touching.
In a recent strategy review meeting, a broad array of choices were presented to the team. The problem space was very large so there were many things we could invest in and it was fairly unclear how to proceed. Many of the choices were interelated and it was unclear where we should start. I really needed to create some sort of structure to the problem because all the unknowns were making it impossible to make any sort of decision.
Step 1: Put things into buckets.
In this case, I needed to gather things up into smaller buckets so I could look at the buckets individually. Most large problem spaces can be bucketed up. Don't allow the team to wallow in deciding what the buckets should be. You can adjust later. This is just a framework for making the problem simpler. Sample buckets that I've used before:
- Operations, Sales, Marketing (For a consulting company)
- People, Business, Process, Technology (for an IT shop)
You get the idea.
Step 2: Sort into the buckets
Take all the random junk that you're talking about and put them into the buckets. If things are really out of control, I make people put their ideas down on sticky notes and group them on a wall or whiteboard. Then we argue about the groupings. Sounds dorky, but it gets people to think and DO SOMETHING instead of navel gazing.
Step 3: Sort within the buckets
Inside each bucket, you'll probably wind up with similar things. Group them by affinity then stack rank them. The things with the most positive benefit on the top. Again, as we have discussed you may not ascribe value to something that cannot be measured. Budget, headcount, morale scores are all valid criteria. "That's a cool feature" isn't.
Step 4: Assign priority
This is the hard one. If you have fifteen buckets, you can't go do them all. If you have four, you may be able to assign one to each team member. This is really a judgement call. I cannot tell you how to do this (sorry). I can say it gets easier with time. If you get stuck and the team cannot decide, fall back and punt. You can ether do an affinity matching exercise (where the team simply votes) or you can use metrics to decide (revenue breakdown, budget, etc.). Either way, making a decision is important and this step can't be rushed.
Step 5: Assign Owners
This is the point where the meeting usually ends. Everyone congratulates themselves on having a good meeting and NOTHING AT ALL HAPPENS. I've seen this hundreds of times. Unless you have specific action items with assigned owners nothing good will happen as a result of your hard work. Don't let your architectural heavy lifting come to naught. If you don't have the pull in the organization to get things done, be sure your sponsor is on board with the process and get them to make assignments and follow up.
My friends in the UK call this exercise the "bun fight" because of all the back and forth arguments that happen. I call it "making the sausage" because it ain't pretty but the result tastes pretty good if you know what you're doing.
Good luck!!
ITA