Our first challenges are to think about the code we write, and to participate in working relationships required for the job. The second challenges are to think about how we write the code, and to participate in redesigning relationships that aren't going well. This isn't an easy transition to make. Doing a review can be an opportunity to gain deeper levels of reflection.

After we had reported to the other team, we discussed the experience. I said that it was a shame we hadn't done it a year earlier. One person replied that we couldn't have done it then, and we have matured over the last year. This was a third level of reflection: he was discussing how we think about how others code.

I'm reading "Effective Teaching and Mentoring" by Laurent Daloz. Although written in an educational setting, it is very helpful for thinking about how people make these transitions at work too, and how to help them.

I spent a lot of effort in the first two years on what could be called social architecture: establishing relationships and feedback mechanisms that were capable of delivering the product.

These were tense months. The UK army's officer training advises that before any engagement, write an appreciation of the situation from the point of view of the enemy. Three times I took a piece of A4 paper and wrote out "how the project looks to X". Then I met with X, and said "I'd like to be sure I understand how you look at the project. I'd like to say what I think you see. Please correct me when I get it wrong."

Then I would follow up by asking "How do you think the project looks to me?". From all three people, I got the response that they have no idea. I'm not reticent - the problem was not lack of information.

Robert Kegan describes "levels of consciousness". An infant has sensations, and by age three can name them; a child recognises objects, natural kinds, cause and effect, knows that other people have sensations, and can agree to and keep a deal; a teenager recognises natural laws, knows that other people may classify the world differently, and can be loyal to a relationship; an adult faces some more challenges, to consider rival theories or world views, and to set terms for relationships.

Developers often said in those first two years "I'm not interested in politics". That seems like a good expression of a desire to participate in relationships, not design them.

I've noticed that developers at an early stage of their career aren't ready to learn project management - it is the answer to questions they aren't asking yet. This seems to align with the suggestion that they are working at the third order of consciousness.

Has anyone else found Kegan and Fahey's work useful?

This has been great, to get direct contact with users, and face to face time with other team members. But it isn't family friendly, so I absented myself from the third one.

I have to do less and less managing of the project, so I'd actually making more of a technical contribution now than earlier. And mostly the code camp went fine without me, but the after action review pointed to one problem.

They say they failed to focus on the tasks that were deliverable in a week. This seems credible: one contribution I still make is to focus the discussion: "These are important issues but they aren't for the next release. What should we do next?"

The developers prioritise their individual work well. How can I transfer the skill of focussing a team effort?

I've just started reading "In Over our Heads: the mental demands of modern life" by Robert Kegan. He discusses personal development as repeatedly attaining a meta-level, in which elements of your subjectivity become objects you can think about. So far, it seems like it might contain some answers about acheiving maturity at work.

After that meeting, one person wrote to me to ask if I could promise that in future we would take the necessary discussions and avoid local solutions. I wrote back saying no. I said that I could imagine a species in which, if today everyone agrees that whenever A happens they will do B, and tomorrow A happens, it reliably follows that everyone does B. However, that species is not Homo Sapiens.

There are real pressures on us that mean that the outcome we want will have to be fought for case by case.

I'm reading "Inventing Accuracy: A historical sociology of nuclear missile guidance" by Donald Mackenzie. He says "Policy is not 'decision', with that term's connotation of an anthropomorphic decision maker, but 'outcome'."

That seems like a crucial insight for leading a team. He also uses the term "heterogeneous engineering" for "the engineering of the social as well as the physical world", combining technical development of the product with developing the institutions and social processes that will create demand and support for it, and develop it in the desired direction.

Our current customers are academics, who will get the software for free. We have now been approached by a company who also want to use it. This opens up new options for the continuation of the project.

Since our code will be open source, the background knowledge of the team will be the main exploitable asset created. I'm not sure our managers will realise this and take action to preserve it.

The team members will want continuing challenge and opportunities for growth, not a dead end role.

So the next six months will contain delicate discussions. When managers discover people who they thought of as chess pieces are actually players, who they must negotiate with, then their first reaction is usually anger.

These changes may create an attractive long term role for me ... perhaps I shouldn't be rushing to another job.

One person reported that we had found that the javascript validation did not work just hours before a release. "When I saw the panic ... I swore I'd make tests from now on."

One said that by personal experience, he "spent half his time on defect fixing before, but now" that he uses Test Driven Development "it is only 20% of the time".

One reported a time when I had deferred a fix until the next release, and said that this did not correspond to the users' priorities.

So there were a few gems in it. But it was also significant that their presentations were overwhelmingly on details of the tools, not of how using them changes the development process.

We are half way through a five year project. It's time to think about preparing them for their next roles. How can I encourage them to abstract from the day to day work and become conscious pilots of the project?

It seems to me that I have led my project to succeed in a way that others in the same milieu have not; that this is not a fluke; and that success was obtained by methods which I could teach to others.

My supervisor explained that this is a scientific organisation, and so to get promotion I need to publish half a dozen papers. He explained, frankly and with good will, that the things I have achieved would not be highly regarded by a promotion panel.

Underlying this, I don't think he really got it himself. I think that once again I am doing good work of a sort that my employer does not reward - in fact, does not even notice.

So it seems to be time to move on again. The good aspect of this employer is it took four years to get to this point. The bad luck is that my previous department is contracting, and my previous supervisor retired. They would have been much more likely to get it.

The hardest part of the project is over. It can now proceed to completion without me. So I can look around with a good conscience.

The discussion was nearly derailed by the head of the project, Len, repeatedly making the same detail point over and over again. The chair of the meeting started reading his email. The person presenting that item switched the screen to the cricket scores.

I said loudly "we only have 15 minutes left, and without decisions on this item I don't know what assignments to give the developers from the start of May". The meeting resumed. Most of the work packages were labeled A, but there were enough Bs and Cs to give me something to work with.

After the meeting Len said to me "I resent you putting pressure on me to take those decisions."

I find that truly bizarre as a way of speaking to someone who works for you. I reminded him that I had been asking for these decisions since July last year.

The meeting showed some other progress too. We used to be divided between people who think we are doing great and people who think everything is terrible. Now we seem to be agreed on a balanced assessment of the project.

For the current release there was a beta test. I wrote a form with tick boxes, and one user returned it, ticked to say that after some specified fixes, the release is fit for use.

Bert was outraged, and the developers took his side and sent a protest to the board, objecting to them getting involved in technical decisions. Len is Bert's supervisor. I can only guess why he wants to wash his department's dirty washing in public. Bert has been badly treated, but the bottom line here is that any of us can learn when our work is reviewed. I told the board that one possible outcome is that Bert takes the lessons on board, and leads the process of improving this component.

Bert has sent a copy of the internal report to the external supplier. They sent a "reply" which actually contained enough admissions to make it clear that a review is needed. Bert sent a reply to the board which was at a level of technical detail that could not interest them.

I gave him an assignment to work on site with a customer that gives him a chance to shine, and takes him away from this controversy. After he went there, the customer sent an email to a wide distribution list, saying that the project was being mismanaged. It said, in defiance of the facts, that there were some other serious problems, and the review of this component should be deferred while they were considered.

He is the only one in his workplace working for our project. For each person in this situation, I have tried to find a local mentor, someone they can discuss things with, especially at moments when their trust for me is on a low. I was pleased to find someone in his office who he likes, and whose advice will be good. He never discussed over this challenge with him. That's something I better think about.

Ironically, Bert says that he's not interested in politics. I think this is sincere, but I'm sure it's not accurate. For the last few years, weak management by Len has rewarded this sort of behaviour from him, but I'm not so green as I'm cabbage looking, as my Grandma used to say.

That which does not kill us makes us stronger. He will face up to the bad news, and grow from it. Or not. At this point, I can't help him by being nice.

(Editor's note: my deepest apologies to the author for missing this post in the moderation queue for more than a week! --Dan)

A year ago, one developer was saying loudly that we must use MVC, because this is industry best practice, and coded a part of the application using Struts. This code was convoluted, with among other things dreadful exception handling.

In response, the project board said we must take a discussion on architecture, and so we solemnly sat down and opted for Presentation Model and JSF with MyFaces. Nine months later, it seems that MyFaces is still not really mature, and some of those who have read Martin Fowler's article on Presentation Model say they don't understand it.

The oddest thing is a recent discussion with one of the more experienced developers. Some updates need to call logic, but most don't. For them, we have a servlet that updates the DB, then refreshes the referring page, so the view reflects the update. To do this, each getXxxx() in the bean must be paired with a getXxxxLocation(), which returns a string that represents the table, primary key, and column.

He was opposed to using this, on the grounds that it is bad architecture. Instead he wants to write a doPost method for every editable view page, and a Writer class for every bean the view uses.

It seems to me that discussion on architecture has done nothing to improve the quality of the product. By contrast, some developers now write test cases. That has done much more for us. I'd much rather fix poor code that is under test, than elegant code that is not.
At a recent team meeting, there was agreement to put no more logic in doGet/doPost methods, nor in JSPs.

I should add that we are a scattered project, in five cities, and we are in academia, so concensus is expected. I'm project manager, but the role of chief architect was not allocated.

How can discussions on architecture benefit a project?

This isn't easy news to announce. The review is in an area of work where one developer, Bert, has done most of the work, and holds most of the reponsibility. Bert's line manager agreed to tell him, then a week later I would announce the decision at the developer meeting. (Names have been changed.)

Unfortunately at the first meeting only half the news was told. The LM tried to make it sound better than it was, and also was persuaded by some counterarguments the developer raised.

As soon as I found this out I took steps to get an agreed record of what had been decided, and got some board members to participate in telling the developer. Then I announced it to the developer meeting, who decided to formally object to the board.

When the first report came to the board, I answered that there are some details that I wanted to discuss on a technical level, but it was broadly accurate. The head of the project, Len, criticised me for not reporting the weaknesses earlier.

The truth is a bit different. Eighteen months ago I wrote a report on this. One reply from a board member described my report as grossly offensive to Bert, and said I should be sacked.

At that time I agreed to a plan which has since been carried out, to retire some second hand code in this area, and thereby solve one set of problems. This left the other problems in place, that we will now address.

Bert probably thought that this plan solved all the important issues. I always thought there would be a second round. I was able to agree to the first plan partly because it reduced Bert's power of veto in the project.

Now Bert has a test, one which most of us face a few times in a career: whether to accept correction and grow with it, or whether to decline to learn. He could become a developer of great stature if he takes the first road, which is why I consider the LM's conduct so appalling.

I'm glad that these issues are being addressed, but for choice I would have delayed twelve months. Some more evidence would probably have come in that would have made the issues clearer and the discussion less tense. The weaknesses don't have much customer impact at present.

When is the right time to take a decision? Before the product is needed by the customer of course. But preferably not so early that the discussion will be in terms of opinion and individual experience: preferably after all evidence that will be available has been collected. And not so early that there will be time to reconsider before putting it into practice.

Developers vary a lot in their tolerance for uncertainty. Some don't like deferred decisions, and will be keen to discuss them now. When you have the responsibility to lead (in your job description or de facto) you have to be careful before expressing opinions, because they may have more weight than you intend.

But on the other hand, Bert could feel that I have haboured a secret plan for two years. That is another way of feeling about the same set of facts. I don't feel sure what is the right conduct here.

We had a day of rehearsals before hand. Even before that each developer drafted a handout, which I reviewed. I had to leave during the event for a management meeting, so I thought that it was more important that the developers become confident than that every detail is right. The actual results were excellent.

The head of the project, Len, didn't see it that way. He sent an email about an early draft of the handouts saying "this looks like shit". He expected me to get everyting right before the rehearsal. His email was copied to the developers' email list. Fortunately he is not a member, so they did not see it.

I think he replied to me without checking the distribution list, but I used this as a pretext for a fight. I really didn't want him to come to the rehearsals with a potty mouth. It isn't email Tourette's, it is a theory of management which he defends. He says that a number of projects have been saved by him kicking butt.

I wrote back asking to meet with him privately, and asking for a response the next morning or else "our discussion will not be private". His next response was even more obscene, in capitals forsooth. The result was he did not come to the rehearsal, and we did have an exchange of views, moderated by someone even more senior.

During the rehearsals, I realised that I need not have been so worried. The team is now so strong that if he swears at any of them, we can wipe the floor with him. (Unfortunately, I'll have to put up with his language. Some mocking responses should help my feelings.)

Note to self: trust the team.

We were already fully committed for the next six weeks, to work that had high visibility to the funding source. So I couldn't promise to do this work quick.

Also in the meeting was a coder employed by the customer organisation, who has contributed a lot of code to the project. He said that the features requested could be delivered in six weeks.

I kept silent. I wanted this to be true; in the past his estimates were high rather than low; I promised no one anything. But I didn't think this was possible.

A few weeks later he announced that the features would be late, because of lack of support from my team.

It is accurate that I let him down and the customers down. A project manager's job consists in large part in telling the truth that no one wants to hear. And on this occasion I did not do my job.

At the time of writing we have delivered the other stuff we were working on, and can now join in with the developments he is doing. Reestablishing the previous level of trust will take longer.

One of these organisations, let's call it TG, is in two neighbouring universities. Their developer is based at one of them, and regularly travels to the other. He created a prototype, which they used, and then with our help integrated its facilities into our product.This is widely recognised as the most usable part of the product.

The other customer organisation, let's call in NJ, is scattered among five locations. Their developer is not at any of these, but is based in the same office as me and two other members of my team. He has contributed lots of code to our product.His users regard the product as difficult to use.

This situation has now become obvious to all. It has become the major challenge facing us (partly because some even bigger ones have been resolved).

Within NJ the biggest location is Maidstone, and the second biggest Halifax.(Names have been changed throughout.) The users at Maidstone speak to us as if we want to impose awkward and unusable software on them. Perhaps their real fear is that the head of their collaboration, who is based at Halifax, will do that. The reason that their developer is based with us, and at neither of these locations, is the distrust between them.

Before I joined the project 18 months effort was put into analysis, giving us a model of the domain. I began by developing an UI that uses the metadata, so rapidly exposing the model, and providing prototype facilities. We now need to work through it, creating more usable features, like the TG developer did.

The NJ developer is critical of details of the domain model, and very critical of delays in updating it, but also advocates continuing to ship the UI generated from the metadata, and educating the users in how to work with it.

He is now in a very difficult situation. He has developed all the features he has been asked for. It is now clear that these were the wrong features, and that the killer app for NJ still has not been identified. He needs to raise his sights from developing features to solving business problems (actually, in our case, scientific problems).

Unfortunately his background is in an autocratic culture. He expects recognition for doing what he is told, not invention. He is ambitious, and works hard to extend his Java certification. His personal development plan is driven by accreditation rather than learning.So he is not well equipped to deal with a management vacuum.

I have some very competent help to deal with the relations with NJ, so I think this will work itself out. But how do I support this guy to help him raise his game?

This ordeal had at least one positive result, leaving the steering board members with a real sense of solidarity. Better than playing paintball. For the first time, I got a sense that they are confident in me as project manager.

There were several probing questions about how well we listen to users. One particularly good one was "Name a feature of the current release that was specifically requested by a user". By 5pm they were satisfied with the answers.

The next day was a conference with the developers and users present. There was a session on the software product, and over my objections this had a demo not by the developers but by the a user. It turned out that the theme of the demo was how hard it is to use.

All very useful feedback, but the administrator from the funders was in the room, and still writing up his report from the previous day. So I had to take steps to make clear that we have two user communities. One has communicated well with us and is happy with the product. The other has not communicated so well, and does not like what it has.

One thing that made it worse was that the project plan had a punishing schedule of feature milestones, that did not match either user need or technical feasibility. I kept some conformance with this by defering work on usability.

The end result seems to have been OK, and we now seem to have won the time to make up our usability debt. And I have had a good night's sleep, for the first time in some while.