Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...
Blogs as Conversation, and Wikis as Diaries - Not Exactly
Blogs as Conversation, and Wikis as Diaries - Not Exactly Interesting post from Gharan (via Jack) on Blogs as conversations. I wrote about a topic a few months ago, and it sparked a spirited series of emails within my working group. The notes began to lose consistency and flow of thought, as we ended up semi-debating tangential ideas. So, the best way to drive right to the heart of the matter - out to the local hot-dog stand for lunch and some good, face to face discussion. It was interesting / amazing to note how much of our ideas and common ground got lost via the medium.
<aside>I always like to think ...
- Don't eMail if you can Instant Message
- Don't IM if you can phone
- Don't phone if you can walk down and chat
... always best to get face to face.</aside>
I prefer to think of a blog as a form of diary, or possibly my personal/professional bulletin board or op-ed page. In the internal / corporate / professional setting, I see the opportunity to replace the dreaded Status Report - the summary by week/month, or by project/system, of all the Stuff that I just did, plus what's "on the radar" for the next few days.
<aside>Why blog internally? There is definitely value in sharing the information, but the typical method - circulating emails or Word documents - generally suffers from a lack of "sustainability", or permanence. It's usually just too difficult to implement format standards and history retention / search functionalty, so an awful lot of "situational knowledge capture" is wasted as the information's life span ends when the readers review for the first (and typically last) time. Blogs, on the other hand, facilitate a standard look/feel, delivery via multiple efficient, time-shifting, on-demand methods, and a permanence and searchability that is lightweight (ie. no expensive document management software required) and easier to integrate with other document capture methods.</aside>
Externally or internally, however, I find feedback (comments and trackbacks) are valuable, but reasonably limited. There are other types of collaboration / communications tools that incorporate threaded conversations (such as issue tracking systems and forums) that are better suited to the whole "conversational" aspect of blogging, and a complete environment will incorporate those as well.
The Wiki concept is making its way into the group as well, but again we're going through some experiential learning about what type of knowledge capture each is suited for. Some are having fun with the "funny names", but unfortunately we are talking about using Wikis as a replacement for the Status Report (Wiki as Diary). I'm fairly confident that most folks don't really "get" what a Wiki is (think "live" collaboration and shared authoring of a reference book) until they actually create and/or work with one. I am actively looking for that "first case" where we can identify something relevant and value-adding - and then toss the organization into the mosh pit, and see what happens.
Labels: blog, Web 2.0, wiki
Misapplying the Pareto principle
Misapplying the Pareto principle Here's an interesting phenomenon I've encountered before ...
When analyzing a specific section of a business, people seem to naturally focus attention and conversation on the top two or three customers/products/vendors that together represent (say) 20% of the revenues/costs/contracts. Our objective is to look at the data and identify opportunities (increase revenues, cut COGS, aggregate contracts); unfortunately, processing the data for these customers/products/vendors is currently a 100% manual task.
Of course; this is why there is apparently so much "opportunity" in the first place.
Unfortunately, it seems (at times) that folks are missing 80% of the revenue / savings opportunities out there, opportunities that are fundamentally easier to "close" on by working data that is available automatically / electronically. It's like the Pareto / 80-20 rule in reverse, which might seem counterintuitive - going for a million singles instead of a few home runs. The mistake we're making is focusing on the wrong 80/20.
The wrong tactic is going after the top two or three customers/products/vendors that represent the most benefit.
The correct tactic is going after the top two or three (or more!) customers/products/vendors that represent the best cost/benefit - ie. the low hanging fruit, the easy wins.
Try throwing out the "low hanging fruit" idea to break thru thinking that wants to go for the "big hits". You're probably going to have to rework some basic process issues (renegotiating contracts with customers / vendors, or reconfiguring production for products); might as well work the bugs out before you mess with your top customers/products/vendors.
The "Army Rangers" model for IT Professionals
The "Army Rangers" model for IT Professionals I got a chance to read over some Gartner predictions for 2006 (available $ online). One that struck me said that the job market for IT specialists will shrink 40 percent by 2010. Hey, that's only a few years away! The article makes the point that "... IT people ... must have the capacity to move fluidly and effortlessly into multiple projects, disciplines, and processes."
I like to cite, as an excellent illustration of this idea, the movie Black Hawk Down. There are two military groups represented (Army Rangers and Delta Force), each with highly trained, independent thinkers under separate chains of command. In the heat of battle, any one of the group can pick up a number of different types of weapons, know how to "get productive", and move the group forward, even with their limited understanding of the mission and current status. There are no pure "managers" - everyone gets their hands dirty.
Also, there are no pure "staff" / infantry. I love the intergroup squabbles where a "manager" / team lead (Ranger) and a member of a separate team (Delta) share short, harsh words about some decisions made a few moments ago. The Delta guy is pointedly questioning the Ranger captain's tactics, and the Ranger captain letting the Delta know he is "combat ineffective". And then, quite suddenly, the discussion is over. The Ranger now asks the Delta for input on the next best move, the Delta makes a good, solid suggestion, and the Ranger carves up both teams and assigns them over. Leadership is situation-specific, there is just enough chain of command "structure" to keep the admin details in place, and business is moved forward at the local level.
There's a similar point made in Gladwell's Blink, in the story of Paul Van Riper and his victory in the Millenium Challenge. The commanders in the field are given freedom and responsibility to make the calls as they see fit, without having to check with the brass above, or wait for a bunch of detailed analyses.
Although not a big fan of using armored conflict in my business analogies, I still like the kind of IT organization described by these stories - populated with hands-on, knowledgeable, savvy, engaged people with technical skills and business experience, who can get in the coding / wire pulling / data modeling / process analysis trenches, as well as stand back and make some strategic and tactical decisions.
These are the skills we must expect of ourselves (and encourage & develop in our teams) if we want to "make the cut" described by Gartner.
