Empower your team, build a Responsibility Matrix

A group becomes a team when each member is sure enough of himself and his contribution to praise the skills of the others.

A group becomes a team when each member is sure enough of himself and his contribution to praise the skills of the others.

Have you ever faced a situation where in your absence, or that of a critical person, other team members are in a quandary regarding taking decisions, executing tasks or plans or sending reports?

Have you found yourself in a position where team members are calling you, as the key decision-making rests with you?

This is typically a problem faced by people who are managing multiple projects and are key to specific projects. Their team members normally have issues when they are unavailable.  This problem is compounded in the case of geographically distributed teams, or those working in different time zones.

If you have faced such a situation, this blog may be useful for you.

I believe the solution to this challenge lies in engaging with all your team members to create a ‘Responsibilities Matrix’. The idea here is to identify and list all the important tasks to be performed by the team.  Following this, the team needs to identify the primary and secondary owners of these tasks.  These responsibilities must be rotated, wherever possible, among other team members. This will help create backups and reduce dependencies on a few individuals.

I am using this responsibility matrix in all of my projects and a sample of it is attached to this blog.

The idea behind the matrix is bigger than simply adding tasks and the names of the engineers in charge. The aim is to develop a sense of ownership and team spirit. It is to empower the team, improve transparency and communication and lower the dependency on specific people.

How we did it was we sat together and identified the various tasks and grouped them under a ‘Major task’.  The teams then picked the owners of each Major task and recorded them in the Matrix.

The Primary owners were assigned the job of ensuring that the tasks were completed as planned. The secondary owners were directed to play the role of the primary owners in their absence. The individual contributors—the team members—were asked to complete the tasks. In case of a rotation, we advised them to make sure that the primary and secondary owners of Major tasks were not be moved at the same time.

I hope this gives you an idea about the ‘Responsibility Matrix’ and its benefits. I look forward to hearing your views on it.

responsibility matrix

Compressed workweeks: A new strategy for workforce retention

Compressed Workweek

Increase Productivity – Reduce working days

How wonderful it would be if you had to work for only four days and get three days off—starting from Friday and ending on Sunday. Interesting? Keep reading.

I read a few articles recently which talked about how a few organizations were experimenting with the idea of giving people Fridays off, in case they had completed their weekly quota of hours!

They referred to this as ‘Compressed Workweeks’. Some other companies called it Alternative workweek schedules.  What this really means is that if the weekly quota of people is 42 hours, they can work 10.5 hours for four days and avail of the Compressed Workweeks benefit.

Another option is for people to work nine hours for four days and then work three hours each on Friday and Sunday.

I recently heard that companies such as IBM, Qualcomm, PwC India, Dell and some others were experimenting with the Compressed Workweeks concept.

It is my belief that flexibility in working hours can help employee manage their hectic schedules as well as balance their professional and person lives.

The concept, can for instance, work for professionals who want to enjoy long weekends.   Naturally, they will have had to put in extra effort on weekdays and deliver their assignments on time.

While on the face of it, the model appears interesting, I am not sure whether it can work in the software industry. For one, it requires better visibility of the work to be done in every week/month and a clear division between the fixed working days and the optional working weekdays.

Another bottleneck can be that the software industry is driven by output rather than the hours spent in the office. Even Agile practices suggest that if a person is unable to deliver user stories assigned to him, then his velocity reaches zero!  Also, after working for 6-7 hours, the productivity of people typically recedes and produces rework.

Though, I am sure that the compressed workweek idea will help engage employees, keep their morale high and retain them, them, there are several logistical issues to consider. Keeping track of the projects, monitoring their progress and managing them will need additional effort.

The Compressed workweeks model can be truly successful where the work volume per hour is defined, as with call centers and software maintenance projects.

This is of course my view. I am keen to know what you think about the emerging trend. Do you think it will be a hit with the software industry, especially outsourcing service providers?

Do write in and share your views.