Transparency and secretiveness

I had this discussion in a professional manager gathering couple of years ago. The importance of keeping transparency in an organisation is vital to its success. On the contrary to this seemingly chorused agreement, the reality shows us there are more than enough managers who love secretiveness, to maintain a secure position within the organisation, in essence. However, you would find yourself being blamed as making sweeping comments - 100% transparency is dangerous. Is it really? For me, with sound justifications, a group of people is generally capable of identifying the boundary of usage of certain information. Consequently, you have your domain-of-transparency.

How transparency would jeopardise some managers' position in an organisation? It is not difficult to see that transparency will certainly remove the requirement of the existence of message passengers as a start; secondly, as plan and information flowing openly throughout, there is a much shorter hence efficient bi-directional path for communications, especially those need buy-in or general support; in the meantime, the variety of information interpretation will be minimised which leads accurate decisions; transparency also helps to build trust relationships among team members; ultimately, transparency makes life simpler as you will save all your time from thinking and remembering all the different stories and persons, trying to keep them consistent with all possibilities for combination and permutation.

So why do we still love the secretiveness?

Feeling special is nice. One of best way for normal people to feel special is to exclusively hold certain information, especially when these information carry great deal of gravity to make things happen or fail. Unfortunately, importance of information has been now very much appreciated by this generation. To take advantage of the holding privilege, it is not entirely surprising to see some managers decide to utilise the selection of coterie to build up connections upon which they would consider as special bond or empowering. The safe assumption made was that the chosen ones have the similar standard of feeling special and important. Till this point, it is not too hard to see how this would start a vicious loop effect on the organisation culture. One of the key evidence you would easily identify in an empire building exercise is nothing else, but the secretiveness.

You have got to ask yourself, "do I love being secretive, or just I have to rely on it to survive?" As I have said in the beginning of this post, it is not even about being honest or not, keeping transparency is simple, easy and good for those who want to have a life :-). We do not have to bury us in the middle of all sorts versions of the same story.

Handson or handsoff

This comes up from a conversation with Jonanthan. Although it is possibly one of the first questions I have to consider when first transition from engineer to technical management. Bottom line is I don't believe effective management could be achieved without solid understanding of technical difficulties and product itself. Sounds like an easy call?

PMI tells us, 90% of project management is about communication. What PMI or most of the management books did not tell us is, both management and engineering are certain types of data processing. Engineers process data via either physical transformation (mechanical gear transmission design, servo control, encoder sensor feedback analysis), electronic signal process (signal generation, data sampling, signal analysis and feature extraction, spectrum analysis and estimation) or logic interpretation (logic circuit design, time-based state machine, bus-based data propagation and transmission, protocol interfacing, optimisation algorithm, pattern extraction and construction, data re-organisation, logic mapping and pattern classification).
What managers do? Not being funny, unfortunately, this question gets asked often by engineers! Many managers choose to hide behind of their roles to 'follow the process, do the job' rather than really thinking about what should be the management responsibility, focus, and what gets things done.
In my opinion, management is also about processing data - processing data collected from 'sensors', data analysis from systems (could be bad data, or even to extract useful information from noisy data samples), data feature extraction and inference, data propagation and transmission, protocol interfacing, pattern recognition and estimation, most importantly data generation. I will break these down:

• Data collection - Managers are responsible to put the right and sufficient information together, either product issues, engineering design constraints, requirement specification, cost etc. The method to collect the data has to be scientific. Unsound approach will invalidate the data you sampled, pretty much the same way Jury will look at your case.
• Data analysis - Managers are also responsible to analyse the data collected. To know what we are looking for, and what we can look for, what pre-processing is needed before data really makes sense to us, do NOT jump to conclusion before data is actually understandable. Gut feeling is irrelevant.
• Feature extraction and inference - Now managers with cozy office will need to do some homework. To extract the features embedded in pre-processed data is not an easy job. You have to be sharp enough to not be buried by trillions of bytes flushing in front of your eyes every milli-second (slightly exaggeration here...).
• Pattern recognition and estimation - To recognise patterns certainly needs experience, although in lots of movies directors trying to convince us it is all about gift.
• Data propagation and transmission - Interestingly, this part is what most manager do well, exceptionally well, to the point in many organisations, there are many managers they believe, or at least it appears to be, that the sole purpose to have management role is to be an information passenger. In fact, to make sure the data is propagated to the right receiver and that only needs a lot of skills. You can't use broadcast everytime without getting in danger of damaging enviroment; multicasting needs policy support; unicast incur transmission overhead.
• Protocol interfacing - Almost every product, to be a piece of usable item in real world, it has to interface with other parties, like it or not. Data transmission, or in a more explicit term - communication, must follow certain protocol to be able to achieve efficiency, security, stability and robustness, extendibility and integratability (oops, sorry, too many abilities...).
• Data generation - Most importantly, as much as a general rule, to produce data, is what really matters. Without this, there is no need for processing, and bluntly, no need for management. Management is about decision, is about getting through all the steps and being able to, and willing to, make the decision about whatever it is about.

Without too much efforts (actually, a bit, admittedly), I am convinced that whether you are doing engineering work or management work, you are processing the data either way. The point is the real difference in handson and handsoff is not what work you do, is about how you do it. Handson is about you get into the details about what you do, being realistic and objective about the true identity of the data, do not randomly or arbitrately interpret the data samples, being scientific about the embedded patterns and using which to make prediction or logic inference. Being handson is about choosing right methods and attitude to process the data, to confront with real world issues without unsound assumptions, being honest about situation and problems, and a little bit of faith in problem solving (this is in fact belief in finding resonance with the underneath patterns embedded in the universe, I am a great believer that we donot create patterns, we find and learn them).

Although in reality, handsoff engineering might sound a pretty crapy idea and one would get caught easily if he keeps his handsoff while he was supposed to deliver 5000 lines of code a week - let's just say being a manager, keeping handsoff will be less vulnerable in the short term compared with engineering work. However, to an organisation, handsoff management will have much more detrimental long term effects.