Visit ManageWithoutThem.com Most recent blog entries Visit ManageWithoutThem.com

Saturday, August 27, 2005

 

Epic Advisers

Just found Steve Banhegyi's blog. He mentions a leadership model (well part of it, I presume) with the acronym EPIC ADVISERS:

Emotion
Power
Inspiration
Charisma

Authority
Drama
Vision
Intention
Storytelling & Journey making
Experience
Role Modelling
Self-Perception



The MWT Model basically says 'What's so special about Leadership?' in a quite sarcastic way indeed. But that isn't to belittle the concept. What I'm saying is that the important thing is to be able to tell the difference between Quality leadership and... well, rubbish.

I'm not sure EPIC ADVISERS is 'particularly African' as Steve describes it. But I mean that in a good way in that it seems more universal to me. Sure, it's just a bunch of words. But it appears to be the right words for a change. There is a certain balance to this list of attributes which to me seems like it would be difficult to fake this type of leadership.

UPDATE: More detail here (pdf).

Thursday, August 25, 2005

 

I'll comment after I read it... But it's gotta be good

Economic Development: An Individualist Methodology

Monday, August 22, 2005

 

Smalltalk Tidbits, Industry Rants: XP debate

http://www.cincomsmalltalk.com/blog/blog...

Traversing the spec without a spec?

[Matthew De George] August 22, 2005 10:31:00 EDT

I'd agree that XP is a response to an organisational problem; but that is not all it is. I think just because it only solves the software organisation's problem doesn't mean it isn't part of the solution for larger organisational problems.

I'm trying to solve the larger organisational problem (at http://www.managewithoutthem.com) by starting with market-based management within firms. I think Scrum can be an example of this because it provides the sort of 'market indicators' required through things like burndown charts.

My theory is that when you are looking at an architecture (read 'delineated shared understanding') of the *solution* you shouldn't suppose that the best way to build that solution is to follow the same structural elements with which the solution is broken up. That is, the structure of the final solution and the structure of the process to get to that solution (the 'delivery architecture') are not isomorphic.

Actually, I'd go one step further than that. I'd suggest that the delivery architecture is exactly the opposite of the solution architecture. This is partially just saying that process is more important than product. Or that process is more important than planning (which is certainly a market-focused approach). But I think there is more to it than that.

More importantly, if this is true - if you are trying to find a delivery architecture which is equally opposite to any possible solution architect – then why try to describe/specify the solution at all?

We have to change the way IT and clients interact certainly. IT systems are not just software programs. IT isn't just a shared service. IT is *structural*. An IT system is a part of your organisation just like a human resource or a partner or an org chart. There really needs to be a better understanding of this. I'm always confused when an ERP implementations biggest advantage appears to be that the finance department doesn't have to answer accounting questions anymore because the IT department is supporting the finance processes...

Wednesday, August 10, 2005

 

Seeing the big picture. Showing the little picture.

Some thoughts in the back of my mind as I develop estimates for a project I’m currently working on. All these numbers, contingencies, and risks. While I’m promoting market-based management and should be against ‘planning’ what I’m really all about are the mechanisms for separating good planning from bad planning (sort of). I'm also concerned with exposing what limited information, what limited controls and enablers, are actually defined by a schedule and a resource plan.

But as limited as a schedule and resource plan are, they are many orders of magnitude more interesting than an estimate. With all the effort to reduce (or at least record) ‘Assumptions’ an estimate is still, by definition, filled with assumptions. An estimate IS an assumption. I’m fortunate enough to be able to use some baseline productivity metrics which allows me to ignore huge chunks of the dynamics within the project for the purpose of my estimate. But one assumption I shouldn’t make is that people will in some way ‘follow’ the estimate.

When the estimate is complete it should be locked up in a box. Nobody needs to see this estimate. There should be 3 degrees of separation between this estimate and anything that 90% of the people on the project are doing at any particular time. If the project takes more resources than the estimate suggests the estimate is wrong - and yet, the estimate doesn’t manage the project at all. Nor does it offer any hints at all on how to manage the project. This breaks The New MWT Hierarchy but I’ll leave the risk analysis to the reader.

Some may ask “Shouldn’t you show people the estimate so that they can ‘see the big picture?’”. Certainly not. The estimate doesn’t show the big picture. Like I said it actually contains very little information. If you have a ‘big picture’ of your business model, or your project’s delivery architect, or a well crafted contract then these things should be published. In fact you are obliged to publish them to your employees. But an estimate is simply an assumption.

Management needs to show people the small picture. I’ve decided that this wonderful technology we call management is failing if people have nothing more than an estimate or a deadline at their disposal when they sit down to focus on their work. It’s also failing when they have a thousand contradictions in their head all relating to the same task. Like I always say “it’s easier to tell 10 people what to do than to be told what to do by 10 people”.

I’m all for big picture thinking and I really do think that an overall view is a vital component of management (these are the delivery and collaboration architectures I’m always going on about after all). But what I’m saying is that management is failing if that is all it has to offer.

I guess this is just another example of ‘the riddle of the stones’; where management thinking has become so muddled that it craves generalists such that the structure of the organisation doesn’t really matter. Preferably, mythical generalists who can apparently do just about anything with equal efectiveness but for some strange reason stay where they are put – and do what they are told. Much like a stone.

There is a contradiction here if I don’t add one other point. How can I be advocating market-based management and then suggest that the management system of an organisation needs to be responsible for the muddled thoughts of an individual sitting down to do work alone? But there is not contradiction. I’m just repeating, as always, that we are all a part of this management process. While that unavoidable hierarchy of responsibility always flows up, we are all integrated.

Too often I see layers upon layers of management and months of planning reduced to asking a strange little man in the corner who only got the task this morning why he isn’t finished yet.