Leading the way Dimitri Aguero Systems Architect Unisys France

Abstract Leadership is usually associated with management. However, mentoring is another kind of leadership, this time without formal managing duties involved. A mentor is like a mountaineering guide. He’s not the expedition manager, but everybody follows him because there is a tacit and temporary delegation of authority based on the trust in his skills. This paper examines a real-life mentoring case which took place in July 2003, and I will explain how to enter (and exit from) these projects.

Introduction The beautiful lagoon near Perpignan (Southern France) was as yet not full of tourists; since the season had not really got under way. The buildings were white, like houses on a Greek island, and the sky and the sea where my son and I had been windsurfing that very same morning were as blue as in the advertisements. Sailing boats were dreaming of storms and winds, moored to the docks, a few metres from the houses. Dozens of white wind turbines were slowly turning on the horizon, fiercely defying the ghost of Don Quixote. An idyllic place for family holidays… Suddenly, my mobile phone rang. After a few minutes talking, I realised it was pretty serious. A red project… yes, yes, of course I will help your team. Please, tell the colleagues, I am neither auditor, nor judge or even a member of the Spanish Holy Inquisition, just a colleague joining them for a few days, to give helping hand. -

OK, I’ll pass it on.

A good start. My interlocutor understood the spirit of my visit. In fact, this was essential when helping colleagues requiring my skills for a few days, to be open with me. I could not help people if they felt that conveying information might jeopardise them. “Help me to help you” is my way of letting them understand the reason for my questions. After hanging up, I remembered all my past interaction with these colleagues. Last January they had requested some help with the Informix database engine. Informix databases are like a jumpy horse participating in the Olympic games: beautiful, powerful, nervous, but only to be put in skilled hands. At that time I had given them some casual advice on the database, which they thanked me for, and then we went on to exchange comments about Informix. But this time I realised it was more serious than before. Nobody asks you to travel five thousands miles just for another opinion. I was thinking about this when my wife arrived. Still with the phone in my hands, I told her: -

I know where I am going after my holidays.

She asked me silently “where?” with her cold eyes. -

South America.

Taking contact with reality I contacted friends from that country living in France and asked them for advice. Past missions in Hong-Kong and Bangkok taught me that it was very important to adapt to their communication codes, and avoid trying to impose mine. Local people are very formal, well-dressed, dark suit and tie for men and elegant dressing for women. In the ever-lasting local spring, it would not be difficult to adapt to their dress codes. To my dismay I discovered that there are many types of locals. In any case, being a foreigner on a multi-cultural team would definitely be an advantage, because you cannot be accused of being partial. Fortunately, my friends told me that it was a rather folkloric competition between regions, much like the one in France between Parisians and Marseillais.

After a twelve hour flight, I arrived at the capital. A colleague was waiting for me. On our way to Unisys offices, I asked my interlocutor how would I know whether I had been successful in my mission. Just analyse the system and give us advice on how to solve the problems. We will have a clearer picture tomorrow, at a meeting with the customer. The same day, I insisted on holding a meeting with Local managers. Two hours were enough to summarise the situation as follows: due to technical problems, the customer had lost confidence in Unisys. And the project status was code red

Understanding the problem I did not meet the colleagues immediately. The day after I met my fellow Architect, a charming young lady with whom I redrew the System Architecture, adding some useful details for me. While drawing, she conveyed her deep knowledge of the project to me. The Project Manager, another lady, was also deeply involved in transmitting me her knowledge of the project. I very soon identified some architectural points worthy of mention. I paid a lot of attention to understanding the architecture, in order to associate customer complaints with architecture building blocks. The meeting would be that same evening. Both ladies helped me to understand they were aware of what was going wrong. So, the question was, why did they call me if they already knew what was going wrong? -

Because they will listen to you as you are not a member of the team.

This was not the first time I had heard these words. In my past professional life, sometimes employees of big companies like DHL (transport) or UAP (insurance) to name just two, requested my external advice to solve a problem for which they had the solution but not the voice. Moreover, they warned me that the external audit firm was a negative influence. Unfortunately, the ladies were right. This external audit firm was hired to help the customer to control the Unisys progress while developing the project. Instead, they focused their attention on finding formal problems in Unisys deliverables, rather than focusing on punctual delivery and quality. The project was already late, and it was going to be delivered even later. I agreed with their opinion. That evening, we went to the Radisson hotel for the meeting with the customer. I was a bit intimidated by the security measures, but inside the hotel everything was like any other Radisson hotel in London or Lisbon, live piano performance included. The customer discussed a lot of complaints with me. But all of them were variations on the same: “because of performance problems, we cannot deliver”. We said goodbye to each other and I came back to my hotel. It was clear that the customer was asking me to solve the problems which nobody had solved so far, and all that to be done in two weeks… it was a request far beyond my capacity. The project would need everybody’s help.

Meeting the colleagues The day after, I arrived at the site where the project members were. We all had to be in the trenches together. I was introduced to the colleagues. We spoke in Spanish, a language I master (I am pursuing a Spanish degree at the Universite de Paris X-Nanterre). Being able to read, write and speak in their language was essential for the success of my mission. Less than 24 hours after my arrival, I was already impressed by the welcome from local colleagues. They have a sense of hospitality that makes you feel at home. From the very beginning, they made me feel like one of them. In return, I was sincerely interested in their culture: literature, history (a visit to the National Museum gave me an insight into their brilliant colonial past), and even in their food. One of my best souvenirs is an evening in a bar, where two of our colleagues demonstrated their musical skills as singers. I loved their performance, and of course, I would definitely come back to hear them again. I like these missions, which combine duty with pleasure.

First results From the very first day I knew that I could not do everything alone. Even if my experience shows that 70% of performance problems come from software development, I focused my attention first on system and architecture,

because no software development can do a good job on top of a flawed architecture. The foundations must be solid. After a week working with the customer, I presented our results. It was clear that some architectural work had to be done, but it could be delayed until after the delivery date. I gave some technical advice, but I preferred to focus on conveying two messages to both the Unisys and the customer management teams: - “First: stop fighting… you are not going to deliver if you waste time arguing who’s right. Second: Stop introducing modifications. It’s too late. Focus on delivery.” Both parties received the concise crude message favourably. It was time to end hostilities. Once again, the author of The mythical man-month was right again… But it was clear that a review of software was necessary. We decided that I should stay one week more…

Seeding ideas Back to the trenches, I explained to my colleagues the conversation we had had with the customer. It was time for some “commando” action. Some priorities had to be rearranged. In the next two weeks, I focused on getting better performance figures. I borrowed some time from developers, who kindly agreed to all my requests. I requested they carry out some technical changes, always explaining why… and very seldom how, because they were highly skilled. In fact, any Local engineer can do a job as well as any other equally qualified in the world. Both technical and project skills were needed to carry out this mission. In one case, I explained communication techniques on how to structure instructions transmitted to a colleague, to ensure correct responsibility transfer. On another occasion, I explained how the indexes are stored inside Informix memory, and how to calculate index average space consumption. In fact, I spent more time explaining right behaviours than doing actual technical work. I call this technique of mentoring “seeding”, because you don’t teach people how to do things (otherwise this would be called a training), but you implant the criteria they should adopt when taking a decision. I often used examples, which helped people to get the idea I wanted to convey, since they had to make a mental effort to find similarities in a completely different situation. This is an actual dialogue: “During World War II, the logistics managers who had to send material from the US to the UK, had two strategies to choose from. Strategy one minimized sunk ship losses, but was abandoned. Can you imagine why ? -

“Tell me”.

“Because winning the war, was not a question of minimizing losses but to keep the British alive and fighting. Strategy two, which maximised the tons transported across the Atlantic Ocean, was the right one. A smile appeared on my interlocutor’s face. “I see what you mean, Dimitri… What we have to do is to maximize punctuality in delivering our software, to keep our project going. It is worthless to minimize missing functionality, if the project is late - and dead-. “ You guessed it, it was another way of saying “Deliver or die”… Many times I repeated: “Local engineers are second to none. You are neither better nor worse than anybody else. You can do it.” And they did. At the end of the second week, performance figures were much better. The second meeting with the customer announced impressive improvements, condensed in the PowerPoint presentation. I felt that stress levels in both management teams, Unisys and the customer one, began to remit. And as a courtesy towards these people who had worked hard even at weekends, I repeated the PowerPoint presentation I had shown to management, to the team in the trenches. They were very happy, too. By proving that they could deliver the required quality, they regained their customer’s confidence in them. The good news was that 90% of the techniques the team applied came from their own suggestions, not from me. Even in the hypothetical case I could supply them with 100% of the solutions (I could not), I would avoid doing so. One of the requirements in the art of mentoring, is not invading the space of the people you’ve helped to the point of sterilising normal team functioning. In fact, you should change the dynamics of the team, not become a part of it. A mentor should be able to leave a group tiptoeing away down the stairs, without anybody realising.

The prototype

The third week was crucial. I agreed with the developers to prepare an untested version, which we called “the prototype”, and which focused only on solving some performance problems. As a safety measure, I requested the colleagues try it out on the biggest database they could find, a huge database which I christened using the name of a very well-known local painter. While developing the prototype, I encouraged them to take enough time in discussing before writing a single line of code. The architect and one or two developers were always involved, and I encouraged an exhaustive discussion, while preventing the discussion from going round in circles. I always requested the usual behaviour, this means, an evaluation of impact, cost, and expected profit, a conclusion, and an action. The colleagues played the game, and we later realised that by spending one hour more in planning, we had saved many days of rewriting code due to misunderstandings. Doing the important was done before doing the urgent. To avoid opening bug reports against the prototype, I warned everybody at least three times that this prototype was only intended as a proof of concept of the code optimisations we intended to introduce, and that it was untested beyond the feature we wanted to show. The prototype fulfilled everybody’s hopes, and I felt that the team was back on line again. Time to leave.

Leaving the project As a mentor you are not expected to stay for the whole duration of the project. Once the main ideas and behaviours have been sown, you have to be sure the team has adopted them and that they don’t need your advice anymore. Pyrrhic victory? Definitely not. Don’t mistake your goal for the team’s goal. Like the mountaineering guide, you tie (literally) your body and your soul to the other expedition members, you show them the way, and once everybody arrives safely back at the base camp, you take a photo with the group and you leave. The fact that nobody was missing in the picture was your goal – and you fulfilled it. Theirs was climbing that mountain.

Conclusion The day I left, two people came to say good-bye to me at the airport. As a symbol of the better relationship between teams, a member of each team greeted me and wished me a good journey back to France. I sincerely wished them the best. An Air France airhostess whose blue eyes remind me of the sky of that beautiful country greeted me in French. Time to return home… In memoriam Alec Scheuer, Ph.D. Physics, a great comrade, and outstanding mountaineering guide, fallen in the Cordillera Real (Bolivia) in 1994.