Advocacy

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Note: this page is under development.

Haskell Advocacy

At Work

Many people wonder why a language offering between 4 and 10 times better productivity hasn't swept the software industry yet. If you are working in the industry then you may already have had some conversations with managers about the possibility of introducing Haskell, and found that they always have some reason why this is not the right time or place. Maybe in a few months, or on another project. But not this one.

This page is intended to help programmers understand what the real obstacles are and how to overcome them.

Management Structure

Any large technical organisation can be divided into three groups. At the top you have senior management, who are there to set the overall strategy of the organisation and make sure that the big things happen to keep the organisation doing what it does as the world changes around it. In the middle are the middle management who take the big strategic plans and turn them into discrete projects and work packages, and at the bottom are the engineers who actually do the work. The work of the middle managers is often described as "tactical" management in contrast to the strategic work of the senior management.

Thats the theory. In fact things are not actually this simple. The middle managers are generally fully occupied with the "day job" of keeping the organisation ticking over, serving customers, meeting deadlines and generally making sure that the organisation does tomorrow what it is doing today. Any large organisation can only survive if these people are really good at this job and pay close attention to it, to the exclusion of almost anything else. And so large organisations have evolved a set of mechanisms to ensure this. Whole books have been written about how the senior management can motivate these people to do their jobs as well as humanly possible. So whenever you talk to one of these people about change, their first thought is how it is going to affect their primary job, because their whole environment is designed to focus their minds on that question. If it makes that job harder in the short term, they won't want to know. And this is in fact a good thing, because if middle managers didn't keep a laser-like focus on doing their jobs well the organisation would not survive.

Senior Management

Talking to middle managers about change is generally an exercise in frustration. So lets cut out the middle men and go straight to the top. Typically you don't want to talk to the chief executive: strategic technology decisions belong to the Chief Technology Officer (CTO) or someone with a similar title. However even if you manage to speak to this person and persuade them that you are on to something, the first thing they will do is talk to their immediate subordinates. These are often the same middle managers who were not interested in your idea in the first place, and they will tell the CTO exactly the same things. Even if the CTO overrides his staff, these are also the people who will actually execute the strategy. They will systematically deprive this initiative of resources, not because they directly object to the idea, but because there is always something more urgent. Its that focus on the day job again.

A Plan of Campaign

By now it should be obvious that simply walking into someone's office and telling them about a new technology is not going to result in immediate and radical change. You need to plan and execute a sales and marketing campaign designed to convince people at several levels of the organisation that they need to support this change. This requires a lot of hard work, a lot of talking to people about people things, and almost no technology at all. If you are not up for this then forget it.

Who to Talk To

The first thing to do is find out who the important technology people are in the organisation. Most senior managers seriously over-worked and do not have time to know about technology, so they delegate the job of knowing about technology to someone else. You need to find this person (or sometimes, people). They are probably not evident on the organisational chart. The easiest way is probably to email the CTO himself asking who you should talk to about ways to improve software productivity. With luck they will point you at someone who looks junior on the organisation chart but who's judgement they have learned to trust.

If on the other hand the CTO points you at an immediate subordinate.