Let it go and buy in time

An additional intention will be to write an article on average twice a month. Since I wrote 3 articles in May, that target puts me in the comfort zone for a few more weeks.

A question to all architects out there: how large a proportion of your time do you spend on communicating with people in development projects, IT management, business management and business application owners (in my definition of the term usually not managers) ?

My rough estimate is: about one third. Not all of this is architecture related. Other subjects are IT governance, development process, operations & support process, project management and perhaps even more important, the emotional state of people connected to the projects. Somehow these subjects are hard to separate. Not that I mind, ignoring these subjects would lead to failure in architecture and vice versa. And I like to think I'm a warm-hearted person.

Over the last month, we performed a self-assessment of the ICT department. I asked everyone in the ICT management to self-assess the department on all of these subjects, positive sides as well as sides up for improvement. The result are organized by topic, and then discussed. The exercise can be considered a success for these reasons:

• It lets go some of the tension present in the department by giving everyone the opportunity to speak out. In a somewhat secured environment.
  
• It informs me about the subjects on which opinions meet, and the subjects on which there is difference of opinion. This is an important factor to verify the buy in.
• It helps to set priorities for the evolution and improvement program. The other dimension to consider is maturity levels.
  

This is not a bragging article. I was, in fact, unsure whether I could pull this off. Although I've seen some great examples from other people over my career so far, getting the best out of other people isn't my greatest strength. Some of the factors that contributed to the success certainly were:

• Persistent communication, ensuring response every step of the way and encouraging continually the participants that needed it.
• Framing the exercise really well. I explained the process we would follow in great detail, so everyone knew what to expect. Everyone knew how personally traceable their contributions would be. I explained the attitudes I expected in great detail as well, stressing them each step of the way. Fortunately, almost everybody respected them and there was no need to intervene. I also improved my templates once more (anyone interested ?). Still, categorizing the remarks correctly was a difficult task for me. There were 102 remarks in total.
• I could count on the contribution of some experienced and friendly colleagues to guide the discussions.
  
• And last but not least, I took the time to get to know the working of the department, verified some of my perceptions by the numbers, and got to know the people in the department personally before I undertook the exercise.

This is perhaps a personal factor, but I'm not that good at immediately responding when someone does not abide the essential rules of the game for this type of exercise. I'm more of a thinker, and I'm usually simply amazed and left without response for the first minute when for example someone says something rude on a personal level "if you're so smart, why can't you think of the answers yourself ?", or is negative without providing alternatives such as "we've already tried this 5 times and it doesn't work". Both of these examples actually happened to me on other occasions.

Personal relationships help me prevent people breaking the rules and help me respond correctly when people do break the rules nevertheless. Some managers or architects can enter a situation with personal relationships that have grown hostile over the years without prior knowledge of this, do this exercise within the first two weeks, release almost all of the tension, and cause very little personal damnage. I've seen some of them do it, but I'm not one of them. Maybe one needs to know his own limits as an architect or as a manager before embarking on this kind of dangerous boat trip over rough and unpredictable seas.

Nevertheless, although it takes much energy diverted from other tasks, I felt it was worth it. I'm surrounded by some very technically focused and results driven people in the department who may beg to differ on this, but the teacher of the lean-six-sigma course I'm following framed it like this:

• Result = Quality (of the work) x Acceptance (by the stakeholders)
• Effort spent on acceptance + Effort spent on quality work = A limited constant

The lesson being: If you spend all your time working towards results, the result will be zero. If you spend all your time on acceptance, the result will be zero as well. Hence, there is an optimal balance, which depends on how much acceptance and quality you can get for your effort. Spending one third on communication may seem like a lot, but actually may be close to optimal as well.
I've seen this in other simpler formulations as well, but here's what seems essential to me. And things should be made as simple as possible, but not simpler. Who thought of that, again ?