Proposals/dev meeting

From Riley Consulting Wiki
Jump to: navigation, search

Proposal to modify company-wide developer meetings

    The policy under review is the weekly, company-wide developer meeting.
Current Situation:
    Each week, on Wednesday, all the developers and the CEO participate in a developer meeting. The primary purpose of the meeting is to give our CEO a way to assess the status of each development team. There is also a little bit of time given for anyone to bring problems before the team that the other developers might be able to assist with.
The Problem:
    The biggest problem with the weekly dev meeting is that two-thirds of it is a complete waste of time for any given team. While the Vortex team is reporting, the Storm team is left twiddling their thumbs. The meeting generally lasts around 2 hours, and at least an hour of that is a waste of time for any given developer. There are eight developers at The RedX, so a full day's worth of hours are wasted. This is compounded by the fact that not every developer needs to be there to report on status. For those developers the whole meeting is a waste of time. It is even worse than two hours wasted, since the meeting occurs in the early morning. Anyone who gets to work before the meeting has just enough time to sink into flow before they are ripped out to go to this meeting. Add in the time necessary to get back into flow after the meeting, and the fact that lunch breaks are quickly approaching, and it is not unreasonable the assume that the entire morning has been unproductive, solely because of the meeting. Another issue that I have seen arise is that the public reporting of status can influence negatively the honesty and frankness of the report. No good developer wants to say that they are struggling, but they really don't want to have to say that in a large group. The final issue is one brought up in Peopleware, that these status meetings are not about the status of the projects, but about the status of the manager. This is a chance for him to prove that he is in charge, that he has control and he can call meetings that are convenient for himself rather than optimal for the developers. Not only is that kind of pride dangerous, it can subtly erode the developers confidence and respect for the manager.
Proposed Change:
    This situation can be remedied by simply removing the developer meetings. This is not to say that management does not need to know about the project's status. The managers just shouldn't get that information in a large group setting. The manager should schedule regular, one-on-one meetings with each project lead. Those meetings are the prefect opportunity to asses the status of a project. Bad news can be, and for most people, is easier to deliver to a single person where you can explain yourself and try to help that one person understand, rather than standing at the mercy of all of your peers. These one-on-one meetings would also ensure that as many people as possible remained uninterrupted. Of course others could be called into the meeting as needed, but rather than that being the status quo, it would only be done when that other person truly needed to be there. This meeting also presents the chance for any project lead to bring up any help that they need from the other teams. When that happens, then a developer meeting between the teams can be scheduled. That meeting has a specific purpose, one team needs help help and the other team can give it. When the issue has been resolved, the meeting is over. This change in process would ensure that everything that is being accomplished by the current developer meetings is still done, but it is a far better use of the developer's time.
Outcomes:
    As have been already discussed, the projected outcomes of this change are increased developer productivity and more accurate status reports from teams.