Managers, meetings and their available time

I see often that managers spend a significant time in meetings and hardly have any time to respond to questions or have time for a discussion. Their calendar is full and they have to decline many meeting invites. In many cases I fully understand it considering the work that comes to them and having seen their calendar. But still I think there is something not right. The problem is that others don’t get answers to their questions, decisions are delayed and there is much stagnation within activities. Some managers hardly ever see their team members outside formal meetings.

I belief that as a manager you should have sufficient time to float around your team and freely mingle with your stakeholders outside formalised meetings. So why is there this over-allocation of managers (in meetings)? There could be many reasons. However I belief that there are ways to reduce this.

If you have constantly back to back meetings, you should ask yourself how this is possible. Could you delegate some of these to your team members and would they have the authority to make the decisions? Has the organisation embarked on too many initiatives? Can meetings be shorter and quicker? I won’t go into how to run meetings because that is a subject by itself and I think already much is said about that.

But there must be options to respond to questions and assure you can communicate your decisions to your team members and stakeholders timely.
I once worked with a CIO who, being a busy man, consistently would answer at least the next day any questions you had sent by email. He was an early riser and used his morning time to respond to all his email. Very effective. As a project sponsor, he organised also the steering committee meetings meaning that they would always be held regularly and project progress was assured. Most project sponsors would leave it to the project manager to organise the steering committee. This means that then project manager will need to struggle to find the time in the full agenda of the sponsor with the constant risk that they would be delayed or cancelled.

I also always respond to emails and questions immediately unless I purposely delay it to obtain more information. The issue is that if A asks B who asks C and each person takes 5 days to respond, the whole process is delayed by 10 days. If each person responds within a day, there is only 2 days delay. Delay simply costs money and specifically if A or B are whole teams who also need to produce something following the answer, you can easily see the impact.

Responding immediately will introduce a temporary feeling of being rushed. But these are short bursts. If you wait, you will have a larger backlog while in the mean time you have the constant stress of all this work piling up. Once you then start working on the responses, you might not be able to complete it all. This will further increase stress and rushed feelings. The risk is then that people will make decisions on their own with the risk that work has to be redone.

Much time of managers is spent on fighting fire. This can be reduced by implementing best practices. Once you have improved your processes and practices, I have found that a team can rather well run on its own. As a manager you have done a great job if you can go away for a while and this does not cause any issues. Just like a parent who raises a child, your objective is to make your team stand on its own. Don't make your team depend on you. Effectively it will reduce the number of questions being asked to you, it makes it easier to delegate and it will increase the time you have available to work with your team. This is what I found out by experience.

So if you are an early riser and your calendar is booked out because your are involved in a change program to implement best practices, I predict in any (near) future you will have more time available.

How much user documentation do we need?

Today I was asked by a colleague to explain how to book a meeting room in Outlook. I was a bit surprised with the question but was able to help. It is one of those computer tasks you tend to expect that people would know this.

It reminded me of a case long ago where one of my team members said we needed to train users on the defect tracking tool Adminitrack that we used. My response was that it would not be necessary since the tool is so simple that if they wouldn't be able to figure it out themselves, they wouldn't be suitable for testing the much more complex business system that was to be tested.

It makes you wonder again how much user documentation is required.

When running a project for a new system, the user community might feel uncertain and demand comprehensive user manuals to be written even though you know that they will hardly be used.

If you buy a piece of technology these days, how big is the manual they ship with it?

We bought the other day a new mobile phone for my daughter and I instructed her to read the user guide. She looked at me as if I asked her the strangest thing. The guide was smaller than the phone and was no bigger than a few pages. She was finished quickly and would continue to rely on dad if she wouldn't know something.

But that is the way it goes. I do the same. First ask somebody nearby and only the look for written assistance in second instance.

So we should keep documentation concise, provided that we build our technology to be intuitive and in alignment with the processes and tasks at hand. Train the users and let them rely on asking the more experienced ones first. Also provide assistance through the IT super users, relation managers or whatever name you have for them. This way you grow a knowledge ecosystem that is much more effective and efficient than the large and expensive volumes of documentation.