The ACCU is a technical organization – people join because it has a technical focus. But actually the secret of the ACCU is that it is really about developing people.

We help those technical people develop their technical skills – but on the quiet we help them develop their less technical skills, we challenge them to think about less technical issues. So, while you see Scott Meyers, Herb Sutter, Guido Van Rossum and Michael Feathers headlining the conference you also find people like Helen Sharp challenging them to think about development as a social activity.

One of the ways we help people develop themselves is by giving them opportunities. As I told many people at the ACCU conference last week there are three kinds of people giving presentations.

First we have the established players, the ‘A’ list if you like: people like Scott Meyers and Herb Sutter – they don’t need an introduction, people will come to hear them alone.

Second we have the ‘B’ list: I’ll put myself on this list if you don’t mind, I’ll also add people like Klaus Marquardt. We are people who have been around a bit, published some papers, done some presentations, we’re the conference filler if you like. Some of the ‘B’ list are challenging for the ‘A’ list, so people like Kevlin Henney might still be on the ‘B’ list but likely he has already moved to the ‘A’ list.

And then we have the ‘C’ list. These are the most important speakers. These are the people the conference is really about. These folks may never have spoken before, or they may have done the odd presentation. These are the people the ACCU is developing, the future talent.

Not long ago I was ‘C’ list, I’d never done a presentation, I’d written a little. By doing presentations, by writing more and by thinking I’m now ‘B’ list. Will I ever make ‘A’ list? I don’t know, I’d like to but there are other things in life too.

Actually, I usually prefer the content of the ‘B’ and ‘C’ list presentations. There are more war stories, there is more discussion and more experimentation – both in presentation style and material.

I want to say a couple of words about two speakers who stood out. These guys are making the transition from ‘C’ to ‘B’ list in my book.

Jez Higgins (who is also the new ACCU chair) did a great presentation about XSLT2, XPath2 and XQuery. He was in a difficult slot – first session of the first day but for me he set the quality bar for the rest of the conference.

I thought I knew a lot of this stuff before the presentation but Jez had plenty of surprises for me. A Suduko solver in XSTL2? – the idea really makes me think again. Things have changed with the XML support technologies and Jez did a great job of bringing me up to date. I guess I knew these technologies were capable of a lot more than transforming XML but it was a while since I’d checked them out.

Day 2 brought Thomas Witt and “Shared Libraries in C++”. Watching Thomas I saw a younger version of myself. Five years ago this was my subject, I knew far too much about shared libraries in C++ – .dll’s in Windows, .so’s on Unix, dynamic linking, static linking, memory models, etc. etc. (Check out my pieces on porting if you don’t believe me.)

Well, things haven’t changed that much in the shared library world over the last five years but Thomas has gone further and deeper than I ever went. He is truly an expert on this subject: Windows, Unix(s), Macs, object models, you name it he knows it.

So I’m looking forward to next year. We’ll have our ‘A’ list speakers to pull in the crowds and make the conference economic but the real action will be with the ‘B’ and ‘C’ list speakers, these are experts every bit as much as the ‘A’ names.

Best of all, this is the ACCU developing talent, this is ACCU giving people space and time to stretch themselves and its why I’ll stick by the organization as I move further and further away from programming.

I’m at the ACCU conference in Oxford this week. As always the conference is lively and giving me a lot to think about. I’ll blog some more about this next week.

But, before then: Monday’s FT had an interview with Larry Ellison of Oracle. He discussed the possibility of Oracle producing its own distribution of Linux. One of the drivers for this is to allow Oracle to compete with Microsoft in the OS market but it wasn’t the only one.

According to Ellison some of Oracle’s customers want a single supplier. They want one company to take responsibility for a systems performance. In other words, they don’t want the ERP vendor saying it is a database problem and the database vendor saying it is an OS problem.

So, if Oracle had its own distribution of Linux they would test that the OS worked with the database and the database worked with the ERP. What I find interesting here is that Oracle would be selling “piece of mind”, “proven software”, or simple “tested applications”.

The value add would not be in the products themselves but in the fact that they all worked together and were shown to work together. In other words, producing the software isn’t the difficult bit, testing it works together is. Hence it is the testing that adds the value not the development.

To my mind this is either a great step forward or a sign of a truly crazy world. I’ve not worked out which yet.

I’ve been wanting to write about Path Dependency for a while. Its a subject that fascinates me but I’m not quite sure I understand what is means and how it affects us.

The idea comes from economics and at its simplest path dependency says “History matters” – or, how we got here effects the way things are. Things are the way they are because of all the decisions that have been made up to this point. Sometimes this can explain why our theories don’t explain the real world – yes, this does touch on chaos theory too.

There is an interesting paper by Margolis and Liebowitz entitled “Look, I understand too little too late” that makes for a good starting point. One of the classic examples of path dependency is supposed to be the Qwerty keyboard. But the authors demonstrate that this isn’t really the case. They go on to question the whole idea of path dependency as an economic force.

So, maybe in economics the theory doesn’t apply. But I think it does apply to software.

All too often when you look at a piece of software it just doesn’t work as you might expect it too. It is programmed in C++ when Python would be a better language, or it is procedural based when OO would be better, maybe it just implements its own data structures when it should use a library. It seems every programmer when confronted with code he didn’t write says “this is awful… maybe we should rewrite?”

It doesn’t just happen at the code level, look at the whole product: are all the features still needed? Perhaps our product is difficult to use because we needed so many features two years ago but now they get in the way.

And the same thing goes at the process level: we write requirements documents because that’s the way we’ve always done it, we throw code over the wall to tester because that’s what we did at the last place. We are slaves to the past and ignore better ways of doing things.

I think a large part of this is path dependency at work. Not entirely, sometime it is because we now understand what we are trying to do better, and partly it is because we have more options available now, but largely it is because of how we got here.

Every individual decision made sense at the time. However, the cumulative set of decisions isn’t the optimal one now. Yet it is difficult to justify changing it now.

So often our theories, whether in Economics, Software Development or Business assume that should be just are: theory says that supply equals demand so it will, theory says code should be unit tested so it is, theory says that Business should concentrate on core competencies so they do. But, unlike Physics these things don’t happen instantaneously. We might need time to let the system adjust, or we might need to give it a helping hand or remove some blockages.

Path dependency may be a grandiose term but is makes an important point: often how we got here is a better explanation of the current situation than how it should be is.

I think much of what we call “design” is about breaking path dependency. Rather than accepting how things are, rather than doing things the way they always have been done, design is about finding a better way and encouraging people to do it that way instead.

That goes at the code level, the product level, the process level and at the business strategy level. We should respect the ways things are, they are that way for good reason (even if we don’t understand them all) but that doesn’t mean we can’t change and improve.

I’m still working out what path dependency means to me and my world view. I think its important and can explain a lot. As I work it out I’ll update you.

For a few years now I’ve been interested in the application of Patterns and Pattern-thinking to the area of business and business strategy. Just to be clear, when I talk of Patterns I’m specifically thinking of the type of Patterns that originated with Christopher Alexander’s work on architecture – see PatternLanguage.com.

Alexander explained his theories in The Timeless Way of Building and A Pattern Language.

During the early 1990’s his work was picked up by a bunch of people in the software engineering community and this led to many books – the most famous being Design patterns – plus an dedicated software patterns organization (Hillside and Hillside Europe) and a series of conferences known as PLoP’s.

When I was studying for my MBA I regularly found myself saying “This could be better explained as a pattern.” Subsequently I did some searching and yes some people had done some work in this field already but often the patterns were kind of “We have this problem that IT people describe as a ‘business issue’ so lets write it as a pattern.” This kind of thinking leads you to stuff like IBM’s patterns for e-business.

Then there are Patterns written about the IT environment that can be applied more generally to business and organizations. Jim Coplien and Neil Harrison’s Organizational Patterns of Agile Software Development is one such book. Its a really good book, I might not agree with every pattern in it but I would recommend it to anyone trying to organize a software development group or indeed, anyone concerned with organizational structure.

But I was actually thinking was: forget the IT, apply pattern thinking to business in general.

This has lead me to produce a number of papers that I have taken to pattern conferences to validate my ideas – you can find them on my website. One of the fundamental tenants of pattern writing is that you should write from experience. Patterns are about what you know not what you can learn or discover. This places a limit on my pattern writing because my experience is in IT so I’ve had to do a little pattern mining.

Still, I’m not alone with business patterns. Linda Rising, Daniel May and others produced Patterns for Building a Beautiful Company. Others have worked in specific business domains, for example, Cecilia Haskins has produce a set of patterns for conference production.

Sometimes people don’t get it, or they ignore Pattern thinking and just look for “simple” patterns. That’s why I don’t consider Adrian Slywotzky book Profit Patterns to have anything to do with Patterns. (A fuller discussion of this book is on my website.)

From time to time I find others who have had the same thoughts as me, namely, Business Strategy is crying out for Patterns. Richard Veryard has had some thoughts online for a while – although I don’t think he has updated this recently.

Just recently I discovered Julian Elve’s blog on the same subject.

I don’t know if Business Patterns will ever break through to the mainstream – the mainstream in Patterns or the mainstream in Business and Strategy. But I do think they have a role to play, I also think a growing number of people are realising this and attempting to do something.

I’d like to think that one day the business community will have our own version of Design Patterns but I don’t see it happening for a while. When it does happen I expect to see business consultants at the fore. These are the natural people to be writing such patterns, they see lots of companies and have great opportunities to spot and analyse patterns at work.

According to a piece on Knowledge @ Wharton the adoption of ISO 9000, Six Sigma, TQM and other similar initiatives can lead to a decline the innovation (subscription required). Basically, as you get better at your process (i.e. you go deeper into one thing) you don’t experiment as much around the edges (i.e. you don’t go wide.)

Actually, according to this piece its not just ISO 9000 and 6 Sigma, it is broader, any process improvement initiatives. And its partly to do with people’s approach, those who are happiest in innovative environments aren’t so happy in structured environments and vice versa.

For someone like me, who is keen on both process improvement (specifically Lean processes) and innovation this poses a dilemma. Am I, by advocating process improvement and the adoption of Lean techniques actually hindering innovation?

Could be.

I like to think the answer is No. Let me explain why.

I don’t advocate blanket adoption of a process. I don’t believe that a process that works for Team X will work for Team Y – even if they are in the same company. I believe different teams have different people and since no two people are alike, no two teams are alike and therefore no two processes can be alike.

Neither do I believe in Best Practice – at least not in the usual sense. The idea that Team X can document all their best practice and hand it over to Team Y, and then Team Y will be just as good (or bad) as Team X is bunk. Again, there are different people and different experiences in each team. Neither can you actually write this stuff down because so much is tacit.

And finally, I don’t believe management can set out a process and mandate its adoption.

What I do believe is: it all has to be bottom up. The teams need to do their own process improvement, they need to find what works for them, they need to work with the people and experience they have in the team. Teams need to innovate their own process.

Teams can tell other people what they do, they can give them ideas, inspire them, and even coach them but they can not throw it over the wall and expect it to work.

While teams can use books, journals, consultants, outside experience to get ideas and inspiration there comes a point when they need to move beyond other people’s ideas and start creating their own. Force-feeding will only get you so far; sooner or later the teams have to be self-sustaining. After all, your competitors can read the same books and hire the same consultants.

The important thing is, this is about bottom up innovation for improved process. I believe that once people get the hang of innovating then the skills and experience will transfer from process innovation to product innovation.

And thus, I don’t believe the kind of process improvement I advocate is incompatible with innovation.

Am I trying to have my cake and eat it? You tell me.

I spent the best part of two hours this morning doing a very un-middle class thing. I put about 200 A4 newsletters through peoples doors. Its not the first, or the last time I’ve done this. In fact, I used to do it a lot more. And as usual I thought: why am I doing this?

It was for the benefit of the local Labour party. I’ve been a member since I was 19 and although I don’t agree with everything the party says and does I do broadly agree. But, that doesn’t mean I must spend two hours on a cold Sunday morning wrestling with letter boxes.

In truth there are a whole bunch of things I don’t do for money and aren’t necessarily fun. I’m on the organizing committees of two conferences (ACCU and EuroPLoP), I shepherd paper for EuroPLoP and I’ve organized a new ACCU website. None of these things pays money and while I may claim they are furthering my professional experience I think its unlikely I’m ever going to get a job because of it.

(Indeed the reverse seems more true, interviewers wonder why you do all this and I usually don’t mention my Labour party affiliations in case people get the wrong idea.)

Actually we could add in blogging.

So, just why do I spend my spare time doing this stuff? And in particular why walk the streets on a cold Sunday morning?

Certainly I’m not in the Labour party for power. I spent 5 years as a branch secretary. That was lots of work. Setting up meetings, writing members newsletter, getting them delivered and writing minutes. No real power there!

Neither do I get influence. Most of the local politicians I know don’t have any real power by themselves. And the one time did ring my friendly MP with a problem looking for help he quickly told me he couldn’t do much.

Oddly I will get a reward. When I see people I know elected as councillors, members of parliament or elsewhere I’ll know I helped. Equally, I’ll feel really down if the other side win.

So, why do I do this?

I do all these things because I want to belong to these organizations. I do them because I think these things are important. And I do them because I have benefited from others so I want to give something back.

I wouldn’t do these things if I didn’t share the values and objectives of the organizations. Even if at the moment I don’t agree completely with wants happening I know I’ve signed on for the long run. Things will change again.

Actually, and this is the reason for blogging about this, I don’t think any of this is very much different to work. I’m not the first to point this out – for example Peter Drucker said it often – but many of the same things that make me volunteer are what make us work.

I think this subject has been at the back of my mind for a couple of weeks. My office book group are currently working through Lean Software Development (Poppendieck & Poppenieck) and in the last session we considered the topic “Empower the team.” This lead us into discussions about: who should be on a team? how should a team be made up? and just why do people work?

Sure I need to earn money, I need to pay my mortgage and I like foreign holidays but there is more to it than that. Like with my volunteering I’m looking to belong and I want to contribute. I want to be part of some success.

Work is different; it takes up 8-9 hours a day – far more than anything else. And it is more of a commitment. I’m expected to be there everyday, I’m expected to be there next week, next month and even next year. But I could walk away from any of my voluntary commitments tomorrow. I could just say “sorry to busy” and people would understand.

Perhaps ironically, I’ve been doing voluntary work for the Labour party for far longer than I have held any job – over 15 years. Even when I disagree with the party (and I do, like over the Iraq war) I still stay involved one way or another. How many employers can get that kind of loyalty?

I think its important that we recognise that people have a choice in where they work, and when they actively choose to work for your company, or work on your team then its quite a complement. We need to recognise that and respect it.

We start by giving people a choice of a job. Once they work for a firm we can give them the choice of teams – in my experience self-selecting teams are the best. We should reward them – not just with money, with feedback on their work and show them what their work has accomplished.

And we can let them pursue their interests and passions. We shouldn’t stop them from taking an interest in a project just because they work in the wrong department, if they think they can add something them they will add their passion at least.

The challenge for managers today is to get people to choose their company, their team and their products. You’ve got to make people want to work for you.

I first heard about Naked Objects (the Naked Objects website is here) in a presentation at the SPA 2005 conference and have been intrigued since. I finally managed to find time to read the book (Naked Objects by Richard Pawson & Robert Matthews) and I can recommend it. Naked Objects brings a different approach to software architecture.

The book itself is different. Like Tom Peters Re-imagine! it is printed so it looks almost like a children’s book with lots of pictures and glossy pages. In particular I like the use of case studies – I think we in the software professions don’t make enough of case studies.

Both the Naked Objects philosophy and the Naked Objects framework are described. I’ve only skimmed the stuff on the framework, this takes the form of a tutorial section on the Java framework and seems to make extensive use of reflection so it might be difficult to port to some languages.

Still, the Naked Objects philosophy should be applicable in other languages. The approach won’t work for all domains: it won’t work where the application is of a highly scripted nature, where customers must use the software directly (e.g. a ATM/cash machine) or where there is a lot of data entry. Still, that leaves an awful lot of applications where it could work.

Naked Objects makes one very important assumption up front: it assumes the software user is not a dumb automaton but actually an engaged problem solver. This also implies you trust your staff (and if you don’t then why do you employ them?) and that they know the problem domain at least as well as the software – probably better. This allows developers to concentrate on functionality rather than interface or interaction design.

Basically, the idea is to expose objects directly. The objects have user meaningful methods with which the user interacts directly. So, if you want to book a Taxi in New York you put the New York object together with the Taxi object. In some ways it is taking Object Orientation to the extreme.

I’m not sure how this all fits with good software interaction design as described by Alan Cooper (The Inmates Are Running the Asylum) – I think in a domain where interaction design was key you probably won’t use this approach. However, where you can position your users as problem solvers the consistent interface pays off.

Once you start treating your users as problem solvers you assume that: they know best how to solve the problems, rather than try and think of everything that could happen and provide a way of dealing with it you provide the raw objects and let the users work out how to do something. And with that a large part of your work goes away, making you more productive; and because you are treating you users as intelligent beings they get more satisfaction from work and do a better job.

Overall I think the Naked Objects approach is very promising. It seems a particularly productive way of working. Everything I heard at SPA and in the book persuades me that this deserves more attention than it is getting.

A friend comes to visit me and tells me he is considering doing PhD research on the gap between corporations stated policy on corporate social responsibility and their actions.

Tony Blair looses a vote in the House of Commons by one vote.

And in Northern Ireland the Independent Monitoring Commission suggests that while IRA leadership is committed to peace and politics the members on the ground are still holding weapons and engaged in suspect activities. (Report in the Economists)

What have these things in common?

They show what happens when the top of an organization – the leaders and managers – gets separated from the bottom – the workers.

Such a situation isn’t automatically bad, it can be a good environment for innovation and risk taking. Neither do we want a situation were managers are standing over workers compelling them to do something

But at the same time it does show what happens when strategy and operations become devoiced. Strategy may be the “helicopter view” but often it is the “expected helicopter view” – how do we know what is happening rather than what we want to be happening?

It is very easy for leaders to say “We will do X” but for the workers on the ground to ignore the message. Perhaps they’ve heard X, Y and Z in recent years and have started filtering our management messages.

How can we expect our leaders to lead if they don’t know and understand what the issues people on the ground are up against? Nor do they know the solutions the people on the ground are implementing, or whether they are compatible with the espoused strategy.

Nowhere is this truer than in the realm of knowledge workers – and in the knowledge workers I know best, software developers. It is said that a developer makes a decision every 15 minutes. But is this decision compatible with the strategy? Does it move us towards our goal?

Of course the developer can’t stop and ask the managers view every time, they need to make a decision – they probably don’t realise they are making the decision a lot of time. To ensure the right decisions are made the two need to have a close dialogue.

This dialogue can only happen if both sides make space and time for it. All too often software developers don’t know they need it, or avoid it because they would rather be coding. And managers frequently fail to make the time for it – perhaps because they are busy making strategy. There need to be occasions were both sides can talk and explore these issues.

The need to bridge the gap between the two groups in an organization is never more acute than when change is happening. My examples above discussed companies trying to take their social responsibilities more seriously, politicians trying to change the law and society and a terrorist group changing its mode of operation.

I once worked for a company that decided it should be CMM level 2. They hired some consultants to write the process. They appointed some “change champions” who then rolled out the process, and they audited the whole thing to make sure it was what they wanted.

Trouble was, the processes didn’t fit the work people did. For starters it was a “one process fits all” approach. Someone once likened it to “pouring quick drying cement on the rails of progress.” It wasn’t too long before the company saw software development as a problem, people were to be cut and work offshored. And they quietly dropped CMM along the way.

I think its also fair to ask if this is simply a break down in communication with the top of the company failing to communicate to the bottom, or whether, it is actually possible for those at the top to impose their strategy and vision on others by merely repeating the message. Perhaps, in order to be part of a vision one must play a role in formulating it.

It all reminds me Harold MacMillan, British Prime Minister 1957-1963. Once asked why his Government hadn’t achieved everything he set out to achieve he said

“Events dear boy, events”

Do you ever find your living out the examples in the books you read? I think I am…

Arie De Gues says:

“The fact is that the word strategy has tends to be misused. It should not be a noun; you should not ‘have’ a strategy, in the sense of a document which the organization follows. Rather, strategy should be a verb: strategy is something you do, rather than something you have.” The Living Company

(Now there is a lot I could say here about how this discussion of nouns and verb links up with Patterns but I’ll leave that for another day.)

Another strategy thinker, Henry Mintzberg, also rejects the idea that strategy is a plan. In the The Rise and Fall of Strategic Planning he made the case that strategy is not a plan you draw up and execute. He cited the case of the Canadian military, one study showed that they produced plans when they had nothing else to do. When they had something to do, like fight a war, they just got on and did it.

“the organization either planned or it acted; otherwise the two seemed unrelated. When the milirary has nothing to do, it planned, almost as an end in itself. …
But when the Canadian military did have something to do (such as fight in Korea), it threw its plans aside and acted.” The Rise and Fall of Strategic Planning

To my mind much of software design is like strategy. (And by design I’m talking about the internal architecture stuff). Having an architectural design is a something you might want to do when you have time but your design will always evolve. Who was it that said

“No plan survives contact with the enemy”

(A quick Google search offers von Moltke or Heinz Guderian.)

What is important for both business strategy and software architecture is that the whole team know the direction, the objective and are fully on board. The planning, the designing, only serves as a learning exercise, what is important is what you actually do.

In the “plan as noun” world you can’t really get this. So often a few chosen ones – maybe just one – devises a plan/architecture and presents it to the others and say “Here it is, all we have to do now is make it”.

Everyone can have their own copy, they may even get to “sign off” on it so they can be help accountable for building it but this method has a number of faults

• Arie De Geus points out: those who aren’t involved in creating the plan will take longer over actioning the plan
• Mintzberg points out that way doesn’t instil motivation, after all, your building someone else’s grand design not your own
• Mintzberg also points out there may be errors in the execution of the plan, of course, if your designers are good enough they will have anticipated these and allowed for them, they plan will be fool proof, or at least allow enough time to fix it
• Most of all the environment and requirements made on the plan change

So for me, I believe strategy and architecture are much more about discussion, I want to hear debate when I am planning. I want to use the whiteboard, I want everyone to join in at the whiteboard. When we produce something I want it to be shared by all. And I want everyone involved, those who will produce the product and those who will authorise it and allocate resources.

Maybe I’m sounding like a broken record, I’ve said much of this before in my essay “An alternative view of planning” but I’m drawn to these ideas again because of where I am right now.

As I said a couple of weeks ago my project is currently “stood down” – I won’t go into detail, enough to say I still have a job and a role but not a lot is happening on the project.

One of the things I’ve been asked to do is to “set a vision” and “create a strategy”. Thing is I’m a team of one, there is nobody to discuss this with, only myself. And instead of white boarding with many I’m going to PowerPoint the whole thing.

This is lonely and depressing. I end up running over the same old ground. In a couple of weeks I’m supposed to present (PowerPoint) something to some folks who’ll decide if we get to move the project forward.

The thing is: I’m like the Canadian army, I have nothing to do so I’m planning.

Are software architectures copies of the organizations that create them?

Often this is true but is it always true? And more importantly is it a good thing?

In 1968 Melvin Conway wrote a paper that discussed this topic. It has since been passed down as developer folk law that.

“If you have 4 developers writing a compiler you will get a 4 pass compiler”

Or,

“If you have 4 developers writing a GUI based system you will have 3 ways of doing anything (mouse, menu and shortcut key) – only 3 because someone has to manage the others.”

There is even a pattern by Coplien and Harrison (Organizational Patterns of Agile Software Development) of this name that describes the situation in more detail.

Trouble is, things are just more complicated than that.

What if your company is bought? What is the relationship between architecture and organization then? Or, if your development is outsourced? What if you are geographically separate? What if you adopt Extreme Programming?

And, have things changed since 1968?

In an attempt to understand the “law” and answer some of these questions Lise Hvatum and myself facilitated a focus group discussion at EuroPLoP 2005. The resulting write up from both of us is now online at on my website.

So what do I think about Conway’s Law?

Well, I don’t think Conway’s Law is a law, in that much I agree with Kevlin Henney, it really describes a force. And the name of the force is Homomorphism.

I believe Homomorphism is a strong force, I believe it is always present, I believe it was stronger in the 1960’s but it is still strong and most importantly it is self-reinforcing. I also think its the default architecture for most organizations.

I agree with Neil Harrison, in the ABC case study the organization changed from one structure to another and the architecture followed, they stayed within “Conways Law.”

The big question for me is:

• Which comes first: Organizational structure or Architecture?

Conway was right when he said that the design that occurs first is seldom the best. Question is: how do you create a better one when the existing one is self-reinforcing?

More than ever I believe that someone who claims to be an Architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than pure technology – they need to have a say in organizational structures and personnel issues, i.e. they need to be a manager too.

All too often technology companies respect those with technical skills and ignore the need for management skills, they reward those who are technical more than those with good management ability.

When I think of the really good technical people I know, myself included, sooner or later they all come to the point where they realise that to solve technical problems requires them to work outside of the technical domain.