It has been nearly 7 weeks since I started my new role as an Improvement Engineer, and almost as long to settle into the role (if indeed, I am to settle)! I get the impression this role is to be more about identifying the problems; rather than being told to solve the problems (this was confirmed as such by my line manager).
I have been dropped into a pilot project, where asset management processes are applied to an existing facility. Asset management is something new to the organisation, and to myself. Much of my time so far has been to try and understand what asset management is, while trying to support the project team with what they are trying to achieve. This has included spending some time trying to find the problem definition – and realising that perhaps this is why I have been brought in…
I have ended up drafting much of the recommendations report, with a great deal of information gathering and lessons learned from the project team. Outside of the immediate project, there are two key lessons I have realised for communicating with the wider audience:
Keep it Simple
Detail is important. Engineering solutions need accurate data input, and detailed analysis. Enforcing new change and new policies needs to be delivered simply. The why and how of a solution needs to be communicated clearly at the beginning (and often the end), while the details can be contained separately.
My past experience from writing college assignments has meant I had taken this to heart (although my assignments were probably still too long I at least aimed to get my point across at the summary and conclusion). General communicating (at least via) email has taught me to try and keep it short (and if it is getting too long then a chat is probably needed!) I find this balance a lot harder verbally (I can be either too much to the point, or too descriptive!)
I have seen a lot of complication in this pilot. I have found myself re-reading documents or responses several times, and only getting to the point when I contacted members to get the short version – or re-worded responses and confirmed if this is what they were trying to say.
(It should be noted that conducting change, especially one which requires intense communication, is challenging during this pandemic and working from home).
Something my mentor said to me at the very beginning. “Be positive” in this instance does not mean the “positive thinking” trope used to mean sunshine and rainbows! Positive is used to mean being sure about yourself. From this teaching, I tried to avoid communications (at least in email) saying “I think” and other adjectives which showed uncertainty (unless I truly was uncertain). (Think of Master Yoda in Star Wars – “Do or Do Not, there is no try”)
I felt my mentor was trying to instil confidence in me; but now I see from talks and emails from some members in the project team that it is an important way of communicating certainty. Several experiences were peppered with uncertainty – which was unfounded as others had expressed similar areas for improvement, and I had witnessed them myself. Along with simplifying, I had amended these lessons to be more “positive”. (p.s I find it interesting that the definition of positive is itself not certain!)
I have much to learn about my new role, about asset management, and reliability-centred maintenance. I hope that my approaches have been of benefit to the programme (so far they have been met with appreciation from members). I hope the lessons above can go on to support the organisation’s asset management strategy, and reduce me saying “it can’t be this complicated?!”