Archive for the ‘Management’ Category

Yoskovitz: Be a Data Hog, Make More Money!

May 9, 2008

Ben Yoskovitz is known for his company Standout Jobs. In the article “Yoskovitz: Be a Data Hog, Make More Money!” he makes a good and simple case for collating lots of data, analysing it regularly and repeatedly asking Why? The approach reminded me a lot of my colleague Doug Brown, the executive in charge of operations in our Search Engine Marketing reseller division. Doug is constantly driving his team to build up data, analyse and test it, and then make interesting and useful predictions and conclusions.

There is a link here with highly iterative development. It comes down to generating and understanding feedback from a working system as quickly as possible and then being able to adjust your course as quickly as possible with the new information. Making the feedback small, incremental and falsifiable (as in test-driven development) is important. Each of these contributes to being able to translate the tests into next actionable steps.

Technorati Tags: , , , ,

Just how importance intelligence is to getting a job

April 9, 2007

One of the twenty or so books that I am ploughing my way through right now is ‘Hard Facts, Dangerous Half-Truths & Total Nonsense‘. It is all about how evidence-based management can actually help you improve the way that you manage today. In there, I read the frankly gobsmacking news that IQ was the best predictor of job performance. Gobsmacking because I have had a long love-hate affair with IQ and finally turned myself over to the dark side by trying to understand and leverage Gardner’s theory of multiple intelligences.

When I was in my early teens, my idea of fun was doing taking self-tests for IQ (which only begins to tell you the kind of childhood I had). This is the bad old-fashioned IQ that everyone loves to hate these days focussing almost solely on linguistic and logico-mathematical intelligence. I learnt quickly what many found out before me: it is pretty simple to learn how to improve your scores on these types of test. Mine were high and only got higher. It only helped that my greatest strengths were reading, numbers & arithmetic patterns. Later, when I did training with a group of leaders from Razorfish, I found that there were plenty of other people who much more advanced in emotional intelligences. We learned there (and I read in subsequent books such as this or this) that these other intelligences were much more potent. So how come that linguistic and logico-mathematical intelligences win out in being good at your job?

The answer — and why Pfeffer and Sutton call it a ‘half’-truth — seems to be just how good a predictor IQ actually is. It typical correlates less than 40% with job performance, i.e. 84% of job performance is not caused by IQ. What is jaw dropping here is that this is the best predictor of job performance of which we know, i.e. it is very hard to predict job performance at all.

Technorati Tags: , , ,

Less formal, more rigorous

March 11, 2007

In conversation with our head of audit, I was explaining how our agile methodology is actually a lot more rigorous than old-school project management. We are also less formal. The two are hard to distinguish at first. Let me give a couple of examples.

We are more rigorous. If we start to move our timeboxes around, our whole paradigm falls apart. If we unexpectedly discover that a feature is going to take too long to test, we push it to the next iteration instead of moving the iteration end date out. If we don’t do this, we need to re-write the release plan, re-estimate tasks, re-do resource plans and (where I work at least) replan priorities for other projects, as well as generating the same set of documentation for these other projects. This is all waste work: work that does not bring us closer to client-valued features deployed and working in production. It’s also typically the thin end of the wedge: pretty soon our teams spend more time on documentation that on getting value-adding software working flawlessly in production.

We are less formal because all documents that we use are supportive not directive. I don’t demand people use a certain Excel template for a release plan. Thinking about certain attributes for each feature and for each iteration add value in our experience, and in teams that are starting up I strongly recommend (and yes, even enforce) this. But I don’t really care how our teams record this information. I have been down the path of only checking that everyone is using the same Word template or Excel sheet and mistaking that for real value — and I won’t be going down that path again.

Technorati Tags: , , , , ,

Is Earned Value Management valuable?

January 26, 2007

Eric Brown talks about Earned Value Management. I know that this is a respected practice recommended by the PMBOK amongst others. I have had more than my fair share of disagreements about the need to implement EVM.

I have one fundamental problem with EVM: it takes too long to track this information. I find that for the vast majority of projects that I or one of my PMs run, the team ends up tracking too much information for too little real benefit. I define benefit as the team delivering more working software features in production faster.

As Eric points out, one needs to track the following

1. Planned Work – What work is scheduled to be completed?
2. Cost Estimate for Planned Work – What is the cost estimate for the scheduled work?
3. Actual Work – What work has been completed?
4. Cost Estimate for Completed Work – What is the cost estimate for the work that has been completed?
5. Actual Costs – What costs have actually been incurred?
6. Variances – Cost difference, Schedule difference, Estimate Difference.

If you compare this to a Scrum burn-down chart, or a cumulative flow diagram, you’ll see there is a good deal of time that needs to be spent on overhead, instead of where management focus should be: identifying and removing constraints to the team delivering value. Also, I find this type of management information is too easily used (sometimes inadvertently) by the business to beat up IT on why variances between estimates and actuals are so large. What the business really cares about is seeing software features which they value working in production. Once you have a good idea of a team’s velocity, leave it at that. The velocity — or the number of features that you delivered last iteration — enables a good prediction of what will be delivered next iteration. Even if this does not work to plan, the business is generally very happy with getting a working set of features in production on time and within spec.

With the resources — be they money, manhours or a technical environment — you are using on implementing EVM, consider investing this in your team delivering software directly.

Technorati Tags: ,

How many Irish actually speak Irish?

January 5, 2007

(via LinkBlog) Cá Bhfuil Na Gaeilg eoirí? discusses how many of the 25% of Ireland who reckon they speak Irish fluently actually speak any at all. The author’s approach is very pragmatic and empirical: only speak Irish and find out how many respond. There seems to be a pretty big gap between that 25% and the real number.

When a search engine is operating in a country with multiple flavours, be they human languages, browser versions or mobile devices, choosing which to support is often a tricky choice. There are real commercial and often political consequences. A lot of people feel very strongly about what languages are spoken and supported in, e.g., Belgium, France or Ireland. Small vocal minorities can make a big difference. Similarly, which browser is used by most of the populace differs a lot from country to country. In Germany, Firefox is the norm. In the Netherlands, that’s still IE.

Supporting an extra language can add a lot of cost to the rollout of a search engine. Initially simple aspects like phonetic search, or exonyms, can add enormous complexity which takes you by surprise. For a best of breed enterprise or web search product, phonetic search comes out of the box. It will require configuring by a native speaker, but for many large languages this will already have been done. The complexity will hit when you least expect it: in testing, rather than in development.