Saturday, November 29, 2003

The Zen of Agile Management

The first Coad Letter in my official Agile Management column, The Zen of Agile Management, has been published at the Borland Developer Network. Here is a brief extract…

Agile management is about management science applied to software engineering. Agile management is a minimal, lightweight approach to management. It uses a hands-off style. Agile management is highly delegated and provides empowerment at all levels. An agile manager should be empowered, his team leads should be empowered but above all developers and testers doing the real work should be empowered.

[Download in PDF…]

Thursday, November 27, 2003

Personal Hedgehog Concept

I’ve been thinking a lot about the material in Good to Great by Jim Collins. I’m wondering if his theory of a Hedgehog Concept, as he calls it, can be used for personal decisions as well as corporate strategy.

First let me explain the Hedgehog Concept. Borrowing a graphic from the book, a hedgehog concept is the intersection of three ideas - what you are passionate about, what you can be best in the world at, and what drives your economic engine.

I’m not in a position yet to say how I’m using this idea of a Personal Hedgehog Concept for my own career development. I may be able to say something more towards the end of the first quarter of 2004. However, I’d like to use another example - the recent career of blogerati cognoscenti - Cameron Barrett.

I’ve met Cam on a few occasions and had the pleasure of dining with him twice while I lived in Kansas City. Recently, he took a job with the Wesley Clark presidential campaign in Arkansas. A far cry from his web developer contracts in New York City. This has led to criticism on his Camworld site, such as this,...

Sorry Cam, but Clark won’t win AND web-based campaigns are overrated. Yes, the build buzz, but it’s miniscule and really has no impact on the real vote. Show me real data that disagrees with me. We can get all excited about this stuff, but it’s mostly insignificant besides ego building.

Let’s consider this criticism using Collins’ Hedgehog Concept.

Those who know Cam or have followed his weblog for many years, will know that he is passionate about web standards, UI design and web development but they will also know that he is deeply passionate about politics - particularly traditionally democratic liberal issues. What drives Cam’s economic engine? For years he has been paid to build state-of-the-art websites with a focus on open standards, good UI design and high performance to cost ratios. That leaves “What you can be best in the world at?” It seems to me that the market niche for building a winning online political presence is wide open.

Therefore I feel that it’s irrelevant whether Clark wins or loses. Cam can only be a winner. He will come out of the experience with a Hedgehog Concept which positions him as the world’s leading developer of political campaign websites. Now that is something which he could make a career out of for the rest of his working life. The web can only get more and more important as a political tool over the next 20 years.

What’s your Personal Hedgehog Concept?

Tuesday, November 25, 2003

Concorde and some other followup

Just a few links this evening…

Concorde Deux?

These boffins at EADS, as reported on the BBC, clearly didn’t read my earlier post about why Concorde (and supersonic travel) just doesn’t make sense when you think about the constraints in the problem. Is there a market for Paris to Tokyo in 2 hours? What does it do to the door-to-door journey time? Can it be filled with 300 people every day? and will that represent sufficient business to repay the investment? The critical question to ask in EADS marketing department is, “are we taking a holistic view of this problem?” Customer value is delivered by solving the end-to-end problem - my journey starts when I leave my mother-in-law’s house in Shiki (near Tokyo). It ends when I get to the hotel on the left bank in time to shower before dinner and catch some jazz in a local club. Who am I? Someone other than the agile manager Maybe a dealer in fine art work ourcing a piece for a rich client back in Japan. But are there 300 of me every day who absolutely must arrive before I departed?

Bangalore Texas

“The Indians are coming” - some nice insight from The Economist on how Indian outsource firms are having to create a presence in the USA in order to make their services more politically attractive.

Instant Companies - just add re-use and stir

Om Malik, a favorite journalist of my friend Martin, has a piece, “The Rise of the Instant Company”, in Business 2.0, about the rise of new low dollar startups which are thriving quickly through re-use of COTS (commercial off-the-shelf) components. These companies are in Internet switching, security, and more consumer oriented areas such as home entertainment. The essence is re-use of cheap off-the-shelf hardware such as Intel processors, standard disk drives and other bits, then add some open source software - particularly the Linux OS - which leaves all the R&D effort for new software, i.e. the recipe is a couple of large dollops of reusable hardware components, some knowledge worker brain power, a few all nighters, then leave to cook for 18 months to 2 years, and voilà a nice $200 million dollar company to flip to a slower lumbering goliath with brand recognition and an established sales channel.

I wonder what Om would think of my ideas to take the re-use and value chain the whole way through to the software.

Monday, November 24, 2003

HR Myths #2 - Divide and Conquer

HR Myth #2 - “Divide and Conquer” or “You Get What You Negotiate”. Many HR managers see it as their job to squeeze new hires on their pay and package. They see this as reducing costs and directly helping the bottom line of business. In some cases, they are incentivized to get good deals from new hires. This can be counter-productive. Once again, it is a cost accounting driven focus on cost.

In almost all companies it is directly against company rules to discuss what you - the knowledge worker - are paid with your colleagues. Why? Simply put, it is a divide and conquer strategy by Human Resources. They believe that by enforcing silence with a threat of summary dismissal, they will save the company money and reduce complaints from disgruntled employees. In a few companies, it is also illegal to discuss your pay scale grade with other employees. This is the ultimate in Big Brother style control because it theoretically prevents employees from learning that someone doing the same work is on a higher grade than them. HR believes that this enforced silence reduces complaints, saves the business money and makes employees happier.

Both Steve McConnell and Paul Glen (and I) would disgree with this. HR is thinking about a purely local optima - reduced complaints to HR. They aren’t seeing the system as a whole.

Steve McConnell believes in total transparency in pay scales. We’ve heard a lot about transparency on this site recently. Well this is how Steve’s company, Construx of Bellevue, WA, provides transparency in their pay process.

Salary Structure. We’ve found that an organization’s traditional reward system must be structured to support [personal] professional development goals; otherwise, project goals will supercede [personal] development goals. ...

Our ladder levels have exactly one salary level at each level. The salary for each level and each employee’s ladder level is public information within Construx. Employees have a tangible incentive to reach the next ladder level because they know the salary adjustment that will occur with that promotion. [McConnell, Steve, Professional Software Development, Addison Wesley, 2003, page 158]

Note that there is only one pay amount per level - no sliding scale. There is total transparency in the system, and as Steve describes elsewhere in the book, there is a publicly defined definition of qualifications for each level on their pay ladder. Every employee is able to judge whether another employee is fairly graded because they know them, they work with them and they will know their skills.

Paul Glen explains in Leading Geeks why Steve’s approach is best. In the chapter, “The Essential Geek”, Paul explains the elements of what he refers to as the geek psyche. One of those elements is “a sense of fairness”. Geeks love and expect meritocracy.

Geeks are generally not captivated by money. ....

Their attitudes to money are much more tied up in their strong sense of fairness and justice. No one wants to be taken advantage of; everyone wants to feel fairly compensated for their value. The passion for reason combines with a strong belief in meritocracy to create an atmosphere where money is a primary measure of the value that one delivers to the organization. [Glen, Paul, Leading Geeks - How to Manage and Lead People Who Deliver Technology, Jossey-Bass, 2003, pages 40-41]

As a manager, I spend a lot of time balancing equity amongst team members. I make adjustments in pay to recognize contribution and to reflect the merit of the individuals. I often get into heated arguments with HR people. Why? Because I’m often trying to clean up the mess they make.

Software development IS a people business. The best way to exploit the people constraint is to keep them happy and well motivated. That is best achieved through a transparent, merit based pay scale.

Sunday, November 23, 2003

HR Myths #1 - Merit Based Pay

“Merit Based Pay” or “We don’t care about productivity look at our cost control” is the first in a series of blog entries which seek to blast away the human resources myths which exist in the software industry.

It’s traditional in the knowledge worker world for companies to have pay scales and levels e.g. Level 56 = $24,677 to $33,103. Any employee who is a Level 56 grade will receive a base salary between the two amounts. In some companies, these scales are lies. Often there is a mid-point or median. In my example above it might be $28,500. Companies’ executives decide what kind of performance they’d like to achieve for stockholders. Then then decide whether they need upper quartile, 2nd quartile, 3rd quartile or lowest quartile employees to achieve those goals. In many large companies today, they don’t pay more than the 3rd quartile. So in my example the pay scale is truly $24,677 to $28,500. In this respect, most pay scales are lies.

This is the classic cost accounting mistake of focusing on cost. There are numerous examples of programmer productivity being upwards of 10 or 20 fold better between a good software engineer and a bad one. In fact, some studies say the worst to best can be 50 fold [1]. However, a good manager knows that they only need to pay a modest amount more for good people - perhaps the upper quartile for a pay grade. So why not hire only upper quartile candidates? Pay 50% more and get 1000% better productivity. Hire less people and control costs that way. Isn’t that the best solution?

My feeling about why this doesn’t work in large companies relates to relative standards. It is assumed that hiring managers will not have good metrics for providing balanced equity across the organization. It is further assumed that hiring managers may not be good at screening candidates. It is further thought that hiring upper quartile people sets a dangerous “elitist” example for engineers when other jobs in the company are not hired this way. In other words, mediocrity is both assumed, desired and controlled. Specific grades are generally awarded based on length of service, experience or age as this is assumed to be the most reliable indicator of someone’s contribution and their value to the organization.

So companies which claim to be meritocracies, in fact, are not. They pay people in a very narrow band. In my example, you can be sure that everyone on that Level 56 grade is being paid between $27,000 and $28,500 despite the fact that some of them will be 10 times more productive than others.

The way to break HR Myth #1 is to refocus the business using the Throughput Accounting focus of productivity first, investment second and cost last. Cost first generates mediocrity and mediocrity results in very poor performance from a software engineering organization.

[1] Reference: Sackman, H. W.J. Erikson, and E.E. Grant, Exploratory experimental studies comparing online and offline programming performance”, Communications of the ACM, 1968, 11(1)