by Pavel Cheshmedjiev
Let’s define reporting skill as a set of similar reporting skills from regular daily reporting, through providing status information, to detailed descriptions of the tasks or just proactive communication to show presence. Reporting skill is one of the most valuable soft skills that a typical software engineer could ever acquire. How important they are will be a topic in some of the next papers, for now we can assume that they are surely in the top 3. We all know what are the claimed corporate benefits, especially in the fashionable agile project management practices. We also know what are the benefits for the engineer – comprehensive daily reporting makes good impression before the management and is one of the main factors for measuring one’s progress. In general we should state clearly – in corporate envioronment proper reporting is much more important for someone’s professional growth than knowing and using latest Java frameworks, design patterns and best coding practices.
It is not that I never tried this skill – I really tried to report and be proactive in the soft skills sense. I tried many times, in many different environments, every time more and more motivated. Unfortunately – without noticeable success. Nevertheless each time satisfied and happy with the progress itself, not the way this progress was acknowledged.
My first reporting failure was in the outsourcing company where I started real software development and continued happily about 7 years. In the very beginnig we reported directly on demand and had some weekly reports where we could explain with a few words what we did. After some years we were acquired by a bigger company, where more dynamic reporting was needed. A few months later while I had many serious development tasks in a very delicate moment I was escalated to my lead engineer that the management had no idea of my progress. They missed mainly proactive mails and stuff like this. In fact I really prefered to concentrate on my work and have it done in the best possible way. This time for the first time I learned one of the most important principles – It doesn’t matter what you do, it does matter what others think you do. In fact I’m very thankfuk to my lead engineer that fully understood my hard skills nature and helped me a lot.
Next reporting failure was a sound one because of the strict discipline and corporate culture in my next company – one of world software leaders. I had to do daily reports, we had different reminders, guides how to do it, automated mails and even human email warnings as last phase. In the beginning I reported kind of regularly, then a bit more rarely and finally I found myself with the human email warning, alerting that is it is the very deadline to prepare my daily reportings for the last two months. What I was doing at that moment – I had digged into some deep source and been doing some irritating reverse engineering activities, due to absolutely undocumented project. I really wanted to skip the reporting part and in the same time to have the last task there – so I put “Code Inspections” for 40 days. I’ll skip the details but it appeared that the normal code inspection time for such period was exactly 4 hours ! Epic fail, resulting with many jokes, respect in the hard skills society and a new signing title “Code Inspector”.
The text is getting bigger, resembling a soft skilled one, so I will only mention about the other big failures and try to summarize briefly. Next time I beated the department “no report” record in one of the telecom leaders in Eastern Europe. My manager entered into the room and tried to make sure that I’ll try to report, at least because of the other colleagues. He also showed respect of my record, because only he had achieved similar results.
Finally I had a recent report summary of 3.5 hours in my current company, where about 500 hours were expected. I was too smart to mention the CTO that we shouldn’t expect that the project burndown chart is absolutely correct because we must assume that not all developers had resolved their numoreous SCRUM tasks. He thought for a while and checked my report summary … a moment of discomfort, disgrace and dis*.
The good thing is that without any exceptions I’ve worked with and reported to very knowledgeable people, hard skillers by nature and never had real problems with my reporting skill and unwillingness for fake proactive behaviour. Nevertheless I always claim that reporting is really needed, but a suitable approach can solve serious issues. What are these issues and what causes them will be one of the next no-soft-skills topics.
Thanks for your time.