Do unto others...

Ron Jeffries enigmatically once said of the XP practices, "they're only rules". What I think he meant was that the practices are a social contract within the team - everyone is expected to abide by the contract, but the team is also free to change the contract when that's appropriate. What we don't want on an XP team is someone unilaterally deciding that the rules don't apply to them. Instead, we want them to raise an issue in a retrospective so the team can hear why some rule isn't working for that person, so that the team can provide advice, support, suggestions, or possibly change the rule.

Developers understand this in the development team context, and also with regard to the rules covering the interactions of the customer management teams with the developers, but I find that they are rather more tolerant of the rules covering the interactions going the other way. In particular, I regularly hear people suggesting that although the customer/project man ager wants to do things a certain way, the developers have decided to do something else "in the interests of the project". What's worse, I feel the urge to do this sort of thing myself!

This pattern appears mainly in two contexts - priorities, and quality. When developers know better, the choose to implement features in an order different to the order requested by the customer, usually because it will be "more efficient". This is fine when everything gets done but if there are some hiccups the customer may be left with features they didn't really need while also missing features they think are more important. While one order may truly be more efficient, that may not be the most important thing from the business perspective and if there's disagreement the final decision on priority rests with the customer.

The equivalent behaviour regarding quality is harder to detect. Sometimes the developers decide to implement lower quality than the customer requested, but more often I see the developers decide to implement higher quality. The context is usually that the developers have two approaches - one can be implemented quickly but hard to change/maintain, and the other is slower to implement but easier to maintain - and the customer prefers the "quick and dirty" approach. In spite of this, the developers decide to implement the "nice" approach. Once again, this is fine if the developers can somehow do it in the same timeframe (overtime perhaps?), but not if it's done at the cost of other features.

Developers need to recognise (intellectually and emotionally) that they are in a service industry, and when push comes to shove they take direction from the business, represented by the customers and management. Developers have a responsibility to present their views and recommendations, with all the supporting information, and then let the business make the business decisions, which include how to spend time/money. When business and development don't agree there are two main reasons - development haven't presented their position in a way that the business understands, in which case the developers need to improve their presentation and influence skills, or business understands the development position quite well but it isn't the most critical factor in the outcome. Sometimes developers don't have the big picture! In neither case the problem that "the business is stupid" or "the business made the wrong decision", though they certainly may make decisions that the developers don't agree with (it undoubtedly happens the other way around as well!).

Of course, none of this applies when people are trying to make decisions that they aren't actually responsible for - in that situation everyone needs to say "thanks very much for your input, but I don't think you're responsible for the final decision". It's common for this to happen with estimation, when the business tells the developers what needs to be done (their responsibility) and how long it's going to take (the developer's responsibility). Sometimes the lines are blurred though - the business is making "draft" decisions, fully expecting them to be reviewed by developers, rather than final decisions - and the situation needs to be clarified.

So if you're a developer who interacts with the business then you have a responsibility to respect the decisions of others, and you'll probably benefit from honing your influence skills as well as your technical skills.

Easy Access Training

In 2007 I'd like to try a few different things, and the first of these is what I'm calling Easy Access Training. Many developers have trouble getting budget and/or time off for training, so I hope to offer one day of training per month on a weekend, and have the price float depending on demand. I expect the rate to come out lower than a commercial course, which seems to be about $600/day (+GST), but I honestly don't know how much lower; probably it will depend on the courses that I offer. There seems to be a lot of interest in test driven development, so I'm starting there, but I'm keen to hear what other courses people woule be interested in on this basis.

What do people think of this idea?

Shu Ha Ri

I'm fascinated to read various posts (mostly blogs) about how "Agile" is bad, sometimes accompanied by a caveat that "agile" is ok. To me any distinction between the two is artificial - from its inception agile development has encouraged adaptation of the method. I see the distinction arising for two reasons - (i) simple misunderstanding, since adaptation isn't included in every description of agile development; and (ii) a mismatch between the question and the answer in shu-ha-ri terms.

In these discussions "Agile" is characterised as a fixed set of practices that must be adhered to, regardless of context or experience. While some people may approach there use of agile this way, I feel this is a misinterpretation of agile development - false doctrine, or if you want to be extreme, heresy!

Adaptation is certainly part of extreme programming, even if this word isn't used. In the second edition Kent and Cindee talk about reflection as on of the XP principles, and using root cause analysis as one of the corollary practices. These are both part of adpating XP to the local context. When the agile manifesto said that "...we have come to value...responding to change over following a plan" I took that to include the process itself! During a recent panel discussion I was asked which agile practice I would introduce first, if I could only introduce one, and my eventual answer was "retrospectives". If you introduce regular, open, honest retrospectives then given enough time and some knowledge of alternatives you'll eventually get the process that you need. And I think that I'd classify that you'd probably get an agile process. Diana Larsen speculated on the same lines.

So if adaptation is an intregral part of agile development, why doesn't everyone understand that. I think the answer is embedded in how we teach and talk about agile. In "Agile Software Development" Alistair Cockburn talks about Shu, Ha, and Ri as three stages in learning. In the Shu stage, the student needs a clear set of instructions or rules, and the faith that these rules will give them the results they need. In the Ha stage, the student can automatically apply the rules, but has begun to understand that the rules don't always give the best results. They start to look for these exceptional cases and apply different rules in these contexts. They gain flexibility but, and this is the important part, they need to be fluent in the basic rules first. Kent had something similar in mind when he suggested renaming the XP practices etudes - things that you practiced for fluency, but that you didn't necessarily apply rigorously every single day. In the Ri stage the student has moved beyond rules, but that's beyond the context of this discussion!

Most people, and I don't think this is restricted to software development, want to skip the Shu stage and move straight to Ha. They want to hear that the rules don't apply all the time and then decide when and when not to apply them. I hear this all the time - we want to do risk driven pairing, we'll only write tests for the complex parts of the code, things like that. The inconvenient truth is that this approach doesn't work. Until you've personally applied the practices in both appropriate and inappropriate situation you're just not in a position to make those decisions. You'll apply the practice where you want to apply the practice, but that won't be the same as where you should apply the practice.

So when I'm introducing people to agile practices, I'll say that you pair all the time, that you write unit tests for every method, that you should have 100% code coverage from your unit tests. I know these things aren't true, and it's not what I would say to someone who already had some experience with the practices, but they are very useful first approximations. They are Shu statements. People experienced with software development, but not with agile practices, can sense that these aren't complete answers - if they think that this is all there is to agile, that there isn't more sophistication futher down the track, then they are liable to reject agile as snake oil. It's easy for them to get this impression from introductory presentations, since it's hard to come up with material suitable for everyone in the audience, and it's even easier if the presenter hasn't moved past Shu themselves. We teach students in groups of similar ability for a reason!

In an ideal world this distinction between "Agile" and "agile" would disappear, but I'm not hopeful. Instead I thiink we'll see two things happen - some people will create branded, proprietary agile methods that aren't subject to community reinterpretation, and other people will stop talking about 'agile' altogether and just 'do stuff that works for them'. Time will tell.

Photos from Bangalore

I know that before I went to Bangalore I was really interested in what the physical environment would be like, so I want to share these photos from the business side of things (the more general side will need to wait until more photos get uploaded). If you'd like to hear more about our personal life in India, have a look at Amanda's blog.

The office building that I was working in was part of an IT campus, right next door to the golf course, that also included IBM and Microsoft (Microsoft is down where the bridge is in the photo). You might think from these pictures that it was a very western environment, and it certainly was inside the buildings , but outside, where building was still in progress, the contrasts became more apparent. The roads were kept clean by people with horsehair brooms who came out at night (the brooms looked just like the one that our maid used, with short handles that meant that you needed to bend over to use them), and when you look at the picture of the building site (right next to our office), note how many people and few machines you see. Construction here is very labour intensive.

 
 

Bangalore was a study in contrasts. The house next door to our apartment was palatial (and apparently occupied by late teen boys who wouldn't have been out of place cruising Chapel St, doof doof music blaring), but two doors further up the street the garbage pile was being browsed by cows and goats, and the ironing was being done by the side of the road, with charcoal powered irons. My office had a very pleasant cafeteria, but less than a kilometre away this is where breakfast was being served (sorry for the blurring, but the car was moving!).

 


 
 

Traffic was roughly equivalent to peak hour on Hoddle St in Melbourne, but a lot more chaotic. Horns are used to indicate "I'm here", since lanes, indicators and overtaking are all rather free form. Auto rickshaws fill the gaps between the cars, motorcycles fill the gaps between the autos, and there are usually some bicycles thrown in just for good measure. Rapid construction leaves the footpaths a bit of a mess, so there are frequently pedestrians on the roads, though it doesn't making crossing the road any easier.

Agile assignment in Bangalore

As some of you will already know, I've just finished a three month engagement for a Wall St bank, helping them refine their use of agile development practices. I'm going to refrain from comment on the specifics of the engagement, and instead focus on the things that I learned myself.

1) Indian programmers are just the same as western programmers - same strengths, same weaknesses. Some are good, some are not so good, some are quiet, some are extroverted. I've know this intellectually, but now I know it emotionally as well.

2) Recruitment in Bangalore is just as difficult as it is anywhere else. It might even be harder, since in Bangalore you're competing directly against Microsoft and IBM (who were on the same campus I was on), as well as Google. Most of us don't face that level of competition in our local regions. And sure there are lots more graduates in India, but if you want people with 5 or 10 years experience the ratios are less favourable. Plus Infosys wants thirty thousand new programmers in 2007 (anecdotally), and that might include just a few of the good ones ;-)

3) There are cultural differences, but they are swamped by the twin tyrannies of distance and time zones. Remote offices are dealing with comparative strangers, and between the USA and India there are only a few hours of effective overlap in a day (it's a bit better between India and Australia). Communication over email and phone just isn't the same - you need lots of face to face experience to overcome this.

4) For distributed development you need people who are willing and able to travel. Include that in your profiles.

5) You can't effect rapid change in a distributed group, especially if there isn't a strong consensus to begin with. And forming that consensus takes a long time. The Forming-Storming-Norming-Performing cycle takes a lot longer for a distributed team - there are plenty of opportunities for miscommunication, and it takes a lot longer to sort the miscommunications out.

6) Everyone's ability to influence is diminished by distance. This was certainly a personal challenge, and I don't feel that I really rose to the occassion.

That's enough to get the things that are distracting me out of my head so that I can focus on some pressing work, but I'm sure that more things will occur to me later. When I get a chance to right a blog while I'm online I'll include some photos so people can get a better sense of the work environment here in Bangalore.

Personal Declaration of Independence

I can't say it any better than this, though I wish I could.

Data Agility Survey

Claire Lubienski, who has very graciously given her time for agile conferences and user groups in the past, is coordinating a survey of agile method adoption in Australia. Her request for participants is below - please help out if you can.

---

Data Agility is surveying Australian organisations' adoption of agile methods for software development. We are looking for survey participants from organisations that have tried—successfully or otherwise—to undertake some agile software development. Target organisations are one of:

• public or private sector organisations that have a significant IT function


• organisations that develop software for commercial gain.

We would like to interview people close to the agile project or software development team that also have a perspective across their organisation beyond the project or development team. This is most likely to be the project manager or development manager. Depending on the organisation, access to a chief architect, business owner or project sponsor may be appropriate. The survey is focussed on subject matter such as methods and tools used, project management, team and culture impacts rather than technical details associated with the solution delivery.

Participants will be able to learn from other organisations' experiences with implementing agile and will be given pre-release versions of the survey findings. Survey interviews will be conducted by Claire Lubienski, a senior consultant who has 20 years' business and IT project management experience including with organisations implementing agile methods.

Participation in the survey can be anonymous: client and commercial confidentiality will be respected.

Please contact Claire on claire_lubienski@dataagility.com or her mobile +61 (412) 205 418 if you would like to participate or know of a suitable candidate participant that she can get in touch with.

Why not be a consultant?

I realise that I left a few things out of last week's post on being a consultant - the main reasons why you wouldn't want to be a consultant!

The obvious one is that there's no assurance you can find the amount of work that you want, at the rate that you want. This was certainly an issue for me back in 2001-2003, just after I'd come back to Australia. I'd promised myself that I would only work with agile development teams, and back then that really meant either training or consulting, since there were few (if any) agile teams on the ground in Australia. Thoughtworks was about the only option, but it was a small business and Derek rtgacould only afford to hire one more person. Forced to choose between a sales person and me, he (rightly) chose the salesperson. Quite a contrast to today!

At the moment I don't think there is any shortage of work, but even I have my moments of doubt. I think that reflects my lack of confidence, even though that doesn't really stand up to rational analysis very well - your own psychology is an important part of whether to be a consultant or not! You should also bear in mind that it's never true that "there's no work" - the worst that statement means is that "there's no work at the rate I want to charge", since you can do as much open source development as you like *s*. Being the mathematician part of me to the surface for a few minutes, it's clear that there are two extreme points where you don't earn any money - 100% employment at $0 per hour, and 0% employment at $10,000 per hour (if your reading this blog, the upper limit probably applies to you as well). In between there's a function with non-zero values and your job, from an economic perspective, is to find the rate per hour that maximises your total income. If we knew what the function was, it would be a simple optimisation exercise. I think that I tend to set my rates too low, since I don't like people saying "no" to me - that's another weakness. If you're a potential client reading this, know that I'm trying to get better at that!

The other reason you might not want to be a consultant is that in principle employees should be getting the best work ahead of you - that should be one of the benefits of the employer-employee relationship. You'll be brought in when you have a particular skill set, usually not when the client already has someone who could do the job. Sometimes you're brought in to meet a temporary need for more staff, in which case you'll almost certainly get the less attractive work, but for me that's less common.

Although I'm trying to blog at least once a week, there probably won't be anything from me for a few weeks, as I need to take some leave.

Why be a consultant?

In the last week a few different people have asked me about the pros and cons of being a consultant, so I thought I'd start the conversation by posting some thoughts here.

First, the pros. The most important thing for me is increased freedom to choose what I work on. I keep in touch with quite a few people in IT, particuarly in Melbourne, and I frequently hear about interesting projects. As a consultant, I get the chance to be involved in them, while as an employee I'm restricted to what my current employer is working on. I intentionally said "chance to be involved", because of course some of those aren't using consultants, and some are using consultants, but for some reason I'm not suitable. Even so, right now there are plenty of opportunities. When you're working inside a company, not only are there fewer choices, but most companies only present you with one - the one they'd think you should or would most like to work on. You rarely get given choices at all.

I can also increase the choices available to me by changing by rates. At the extremes, it would be easy to set my rate high enough to not get any work at all, and if I said that I was willing to work for free I'd have lots of choices. There's a happy medium somewhere in between, and it's up to me to find it, taking into account how interesting the work is, how much I need or want to earn, and anything else that seems appropriate. Some people say that you should always charge the same amount, and I do have a standard basic rate, but I think it would be self defeating to let something I really wanted to work on slide by because we couldn't find an agreeable rate (on the other hand, there's always a bottom line below which I'll just walk away and write some articles or work on my own software). In principle an employee can "change their rate" as well, by changing their salary, but it's a little more complicated for an employee!

Another pro is the treatment of intellectual property. To be clear upfront, I've got no interest in intellectual property that I'm not entitled to, or that I created for a client while I was under contract. However, when you're an employee the common law on intellectual property is quite broad, and covers anything related to your employment, even if it's something that you do outside of working hours on your own equipment. Many companies don't seek to enforce their rights, but some companies do, and you can easily end up in a grey area where a previous employer might seek to enforce their rights to something successful. It's not an issue to me right now, but I can see how it could be, and it was one of the drivers that lead me to consulting in the first place, many years ago.

Flexibility of working hours is another pro. Not so much on a day to day basis, but over the course of a year I can to some extent choose how long my contracts are, how long between contracts, and whether they're part time or full time. In the next 12 months I hope to spend more than the standard four weeks with my family. This needs to be balanced against how much I want to earn - it can be hard to say no when there's work available.

Because one of the downsides, probably the major one, is less predictability. When my current contract ends, I can't be sure that there will be more work available - particularly interesting work - starting at the right time. In some sense, there's more flexibility in this area when you're an employee, since your employer may choose to take you off one project early to start you on another one. That's not really acceptable behaviour for a consultant, at least not in my view.

Another con is that you need to be looking for work more often, almost continually. You need to pay more attention to keeping in touch with your network, broadening it, and establishing and maintaining a reputation. I think this is called marketing :-) None of this is paid work, and it can be time consuming. I view writing articles, presenting at user groups and conferences, and even writing this blog, all as parts of my marketing efforts. I need to approach them with more discipline than if I was an employee.

A logistical concern is that, at least initially, the timing of your pay can be less predictable as well. As an employee, you got paid a fixed amount each month, probably on a fixed day. As a consultant, you do some work, you invoice for it, then you wait for payment on the invoice, then you can pay yourself. The invoice may be for a small piece of work, but it might also be for a larger piece of work. The client may pay promptly, or they may drag their feet a little. Many companies quite reasonably don't pay until 30 days after invoice, which even on a monthly invoice can be 60 days after you first started the work. I handle this by paying myself a fixed monthly wage, leaving money in the bank when there's an excess, but the transition from employment to consulting can be awkward.

When you're a consultant, you also need to do everything yourself. I've already mentioned marketing, but you also do sales, accounting, web site construction, email configuration, do your backups, pay bills, produce invoices, create your own business cards, and anything else that needs to be done. To do your accounting, you probably need to understand a little more of the tax lawy than you do right now - for example, about alienation of personal services income. Doing all these things yourself can be a huge change from working in a large company with lots of support staff. The corresponding plus is that you get a lot more insight into how business works, and when every dollar comes out of your own pocket, you become more conscious of costs and you get a better insight into why your managers were so concerned with restraining expenditure.

There is probably a lot more, but I need to head off and do some other business now. The last thing I want to bring up is that I'll try to remember all these things as more people get involved with Cogent. People need to be able to choose their work, change their rates, be flexible with their time. I don't want people working with Cogent to leave because they're not satisified in these areas. It will be a different kind of company *s*.

When Agile Doesn't Work

When I first started talking about agile development, way back in the last century, I was inclined to present agile solutions to every problem that was presented to me. I think this said more about me than about agile - that I was actually insecure about my ideas and understanding, so I felt I needed to look authoritative by solving every problem. As I became more secure, I was happier to say "agile doesn't solve that problem - nothing solves that particular problem". I think this is a very important transition, and with the benefit of hindsight I think it makes people sound more authoritative, or at least more trustworthy, when they readily admit limits to whatever they're advocating (I think politicians would benefit from the same approach).

The secret that zealous attackers of agile, and its zealous defenders as well, don't want you to know is this - nothing works all the time. Every approach you have needs to be modified to take your context into account, particularly your people (see Alistair Cockburn on this). I can be confident that my assertion is true because it contains a very subjective term used repeatedly in software development discussions - "works". When you have a discussion about sofware development, be very careful to check that everyone is using the same definition. There is one cheap defense of agile that would suggest that it can always "work" - agile methodologies are adaptive, so if your methodology isn't working right now, then change it until it does work. Technically that's true, but I don't think it's particularly helpful (nor is it helpful for people to ignore the principle of adaptability so they can dogmatically dump on agile, but I've already written about that).

One are of agile that might not work for you is design. I teach a course on TDD, and one of the things that I emphasise in the course is that TDD and BDUF are end points of a continuum, and that very few people (if any) really work at the end points of the continuum. In the most zealous TDD shop, some thought is being given to the future requirements and overall shape of the application, and in the most zealous BDUF shops some design is being done in response to problems detected during development (or even later). There are lots of factors that influence where you should be on the continuum, but they include design experience, technical experience, and domain experience.

One way in which agile can go wrong is by being too close to the TDD end of the continuum (it's less likely to go wrong by being too close to the BDUF end of the continuum, because of the inherent biases in adopting agility). Things go wrong when the design is moving in a bad direction, often in small increments, and the development team can't detect the problem and respond to it. I used to think that all developers with more than a few years of experience could tell when the design was heading in the wrong direction, but experience is teaching me otherwise. It makes me more sympathetic to the "architecture" groups of large companies, who want to somehow check everything that's going on in their organisation.

If you've got people who can't tell when a design is going wrong I think your choices are:

1. Don't hire them in the first place, or get them off the team in some other way


2. Educate them so that they can see what's going wrong


3. Change your process so that there's more oversight or review, to try to stop designs going wrong in the first place

In principle, XP "out of the box" uses (2), with pairing as a major mechanism for education. This works provided you have enough people with the appropriate design skills. My preference is for (1), but it's hard to find good people - that's one of the motivations for eliminating growth from my company objectives. Most companies go for a combination, with an emphasis on (3). Personally, I think that (2) can be very difficult, and that one of our weaknesses as an industry is how to demonstrate skill shortcomings and then correct them.

If you feel that agile approaches to design "don't work", I encourage you to think about whether they don't work globally, or they don't work for your team right now.

Don't abandon agile

Reading blogs last week I came across Agile People Still Don't Get It along with people responding to the post, including links to the Pliant Alliance, and what appeared to be plenty of posts concerning "large 'A' agilists", who remain nameless. I don't want to single out any specific writer, since it was a common thread, but it appears to me that the agile approach to development is being politicised, fractured, and misrepresented. While I'm willing to believe there are plenty of well intended authors, I also suspect manipulation and hidden agendas.

A classic approach to attacking an idea, often used in politics, is to redefine it then attack the new definition. This is often referred to as attacking a "straw man". A variant on the approach is to take to characterise an individual's views as representative of a much larger group of people, then use an attack on the individual's approach/ideas as a de facto attack on the more general group. A third is the ad hominem attack - questioning a person's motives rather than their position. These can all be applied consciously and maliciously, or in a simply sloppy way through careless construction. I think we're seeing a little of each, though it's impossible to tell. Plus we're seeing the impact of the internet level-playing field, where all voices are potentially equal and if enough people are saying something then it gradually aquires the weight of truth.

For example, while I was reading, I found some interesting questions asked on the Pliant Alliance site:

Just so we don’t get accused of being complete snotty Agile bashers, I wanted to point out this page on the XP website. It basically says what PSD says, which is to fix the process when it is broken and improve the way software is being developed.

So this is a bit of a conundrum. If the XP website itself has some pliant leanings, why has XP, along with the other Agile processes gotten so many people frustrated? Has agile become the victim of book sellers and process consultants? Is it the monetization of the process(es) that has led “agile” to mean something completely different than what was originally intended? And if so, how could we have let this happen?

Adaptation has been part of agile processes from the beginning - I don't understand why it is so often ignored. Is it ignored willfully, deliberately, or through ignorance? The answer is inherently both - I think there are people who ignore it willfully, and their version of agile, san adaptability, is repeated enough that for many people it's the only version of agile that they hear about. The same can be true of any agile practice. Of course it would be easy to go too far the other way and use "then just change it" to address any and all shortcomings, but it is core to agile development that if some practice isn't working, then the team should consciously and deliberately change it. To pick one agile practice, probably an XP practice), say that doesn't work in my context, and then generalise to "agile doesn't work" is a big leap at best, and deceptive at worst.

Another thing that distresses me is that many critics want to write off agile completely, not just in any particular context. It distresses me because I don't want to go back to the situation I was in two years ago, where I frequently had to justify agile development to a hostile crowd, rather than an agnostic one. I'm very happy for people to say that agile doesn't work in their environment (though it would be even better for them to be even more specific, and possibly say which practices didn't work), or with their team, or with their customers, but I wish people would retract the blanket statements. I suspect it's a reaction to the zealous undercurrent within the XP community, who frequently (when I was watching the XP discussion group) would say that "if XP isn't working for you, you're not doing it properly", but those people never spoke for the people who wrote the agile manifesto.

It's possible that "agile" is impossible to defend, because you can pick any from any author and tag it "agile" without too much risk of contradiction. In the last five years, lots of thinking about agile development has matured. Certainly there are things that I said five years ago that I wouldn't say now. And certainly, especially early in agile development's history, provocative things were said to move the debate. This seems to have been lost on many people - if agile hadn't taken an extreme position early on (pun intended), it would have been very easy to ignore. Instead it provoked a response. Even if we only consider TDD, "agility" has changed the way that we develop software.

Hi, I'm Steve Hayes, and I do agile development. It's an inclusive, people-centred approach to doing iterative, incremental software development. It uses a combination of technical and social practices to increase collaboration and reduce feedback cycles. Agile development works best with an experienced team, as do most development methodologies. For the best results, agile practices should be customised to suit the strengths and weaknesses of your team, and the peculiarities of your domain. Agile development is not suitable for every project, or even every team. It has strengths, and it has weaknesses. There is no silver bullet.

Return to Consulting

I've been putting off blogging because I wanted my first post to be "non-trivial" - not just a book review, or a short comment about something that happened at the office. Then I realised there was an easier approach - to start at the beginning. So I'm going to talk about why I quit my permanent position and returned to consulting.

One person said it's because I need to be in control, and that's part of the answer but not really enough. More complete is that I don't like the models of control that are inherent in traditional business structures, where decisions are made at the top and rolled out to the employees. The models actually make sense from one perspective, because most people in the company don't have all the information they need to make balanced decisions. If I'm going to make decisions on how to spend money, then I really need to know how much money we have to spend (how I spend my next dollar does depend on whether it's my last one or there are a thousand more to follow) and what impact my decision will have on revenue. So to be a full participant in decision making I need to know about the company financials. But if the employees knew all the financials, then they'd be privy to a whole load of things that most owners want to keep secret - including how much money the company is making, how much the average salary is (or even relative salaries, especially if I'm going to make hiring decisions). The employees would start to ask questions about who decisions were benefitting.

Now don't get me too wrong - I believe that many corporate decisions are made in the interests of the employees, and could be explained in the context of the full financial context. And I think that lots of people wouldn't object to owners getting rich if it was clear that they were adding a lot of value to the company in some way. But I also believe that explaining these decisions would take a lot of time and education, and would require articulating things that are currently only understood in an intuitive way, so it's certainly a difficult path. Far easier to say "trust me". But once you rely on "trust me", it's really really tempting to slip in a couple of self-serving decisions as well.

So the first reason I'm consulting again is that I don't like the "trust me" environment. I also have some apparently weird ideas about structuring a company to maximise participation and satisfaction, and I've discovered that I can't implement them unless I have something "at risk" - unless I'm the one (or one of the ones) who suffers if the ideas are wrong. If I'm an employee, I get told that "we can't sell that to the customer", or something else about the revenue stream. As an employee I'm an expense, not responsible for "paying the bills". So when I say that I wouldn't work with a particular customer I'm told "we have to", or something along those lines. I've discovered that if I want to implement my ideas then I need to be in control of the revenue (or at least there can't be some "other" who is control of it).

And lastly, I have a weird attitude about what I can and can't do when I'm an employee - I certainly feel that I need to do the work that I'm told to do, that I can't just so "no, I won't do that", even if the worst thing that can happen is response is to be fired. As a consultant I don't have the same reservation. I say it's weird because in principle there's no difference - I refuse to do something, I'm told not to come back and I stop getting paid. I'm ok with the consequences in both cases, but as an employee I won't actually do it. That's my problem *s*.

I've been a bit of tease about my "weird ideas", but this is enough for one post, and I need to hold back something to write about next.

Return to Consulting

I've been putting off blogging because I wanted my first post to be "non-trivial" - not just a book review, or a short comment about something that happened at the office. Then I realised there was an easier approach - to start at the beginning. So I'm going to talk about why I quit my permanent position and returned to consulting.

One person said it's because I need to be in control, and that's part of the answer but not really enough. More complete is that I don't like the models of control that are inherent in traditional business structures, where decisions are made at the top and rolled out to the employees. The models actually make sense from one perspective, because most people in the company don't have all the information they need to make balanced decisions. If I'm going to make decisions on how to spend money, then I really need to know how much money we have to spend (how I spend my next dollar does depend on whether it's my last one or there are a thousand more to follow) and what impact my decision will have on revenue. So to be a full participant in decision making I need to know about the company financials. But if the employees knew all the financials, then they'd be privy to a whole load of things that most owners want to keep secret - including how much money the company is making, how much the average salary is (or even relative salaries, especially if I'm going to make hiring decisions). The employees would start to ask questions about who decisions were benefitting.

Now don't get me too wrong - I believe that many corporate decisions are made in the interests of the employees, and could be explained in the context of the full financial context. And I think that lots of people wouldn't object to owners getting rich if it was clear that they were adding a lot of value to the company in some way. But I also believe that explaining these decisions would take a lot of time and education, and would require articulating things that are currently only understood in an intuitive way, so it's certainly a difficult path. Far easier to say "trust me". But once you rely on "trust me", it's really really tempting to slip in a couple of self-serving decisions as well.

So the first reason I'm consulting again is that I don't like the "trust me" environment. I also have some apparently weird ideas about structuring a company to maximise participation and satisfaction, and I've discovered that I can't implement them unless I have something "at risk" - unless I'm the one (or one of the ones) who suffers if the ideas are wrong. If I'm an employee, I get told that "we can't sell that to the customer", or something else about the revenue stream. As an employee I'm an expense, not responsible for "paying the bills". So when I say that I wouldn't work with a particular customer I'm told "we have to", or something along those lines. I've discovered that if I want to implement my ideas then I need to be in control of the revenue (or at least there can't be some "other" who is control of it).

And lastly, I have a weird attitude about what I can and can't do when I'm an employee - I certainly feel that I need to do the work that I'm told to do, that I can't just so "no, I won't do that", even if the worst thing that can happen is response is to be fired. As a consultant I don't have the same reservation. I say it's weird because in principle there's no difference - I refuse to do something, I'm told not to come back and I stop getting paid. I'm ok with the consequences in both cases, but as an employee I won't actually do it. That's my problem *s*.

I've been a bit of tease about my "weird ideas", but this is enough for one post, and I need to hold back something to write about next.

Welcome!

After a few weeks of working with CSS and templates, and then trying to figure out why I wasn't getting email delivered (still not quite resolved, but working in at least some cases), I'm happy enough with the blog configuration to start posting. Nothing serious, but at least it's not empty now. There will be more in the next few days and weeks.

Welcome!

After a few weeks of working with CSS and templates, and then trying to figure out why I wasn't getting email delivered (still not quite resolved, but working in at least some cases), I'm happy enough with the blog configuration to start posting. Nothing serious, but at least it's not empty now. There will be more in the next few days and weeks.