Proposals/flow

From Riley Consulting Wiki
Jump to: navigation, search

Proposal to institute policies to increase a developer's time in flow

    The concept of flow is one that has been heavily considered already by the management of The RedX. However, there are a few things I have noticed that could be changed to further increase developer productivity.
Current Situation:
    The RedX does developer work-spaces right. Each developer has their own office with a door. The managerial reasoning behind this is that developers need private space to get into the zone and really be productive. There are separate conference rooms where groups can congregate to code or meet.
Proposed Changes:
    There are a few, small things that could be done to help developer time spent in flow to increase. The first is to implement a hierarchy of ways to get a hold of a developer. An issue that is of low importance should be brought to a developer's attention through email. More important but not critical issues can be transmitted via instant messaging. Calling a developer on the phone should only be done on time-sensitive, important issues, and actually walking into their office to talk with them should be reserved only for critically important items. There is no need to try to codify what makes a critical issue or not. If an informal process like this is insufficient, or perceived to be insufficient, then it is a case of training or getting rid of the person abusing the freedom given. No one's time is more valuable than anyone else's, and if the respect and trust between people is so lacking that the levels of importance of a task have to be codified, there are some much worse, systemic problems in the corporation. That is not the case at The RedX, if everyone were informed of the new policy, that would be enough. Finally, a developer needs to have to power to unplug there phone or hang a sign on their door to discourage interruptions. Again, this could be abused, but everyone involved is a smart and considerate person, so that abuse is unlikely at worst.
Outcomes:
    There would not be a huge change if these policies were implemented, but the developers would become a little more productive and a little more happy. When the effectiveness of a developer can vary by a measurement of ten times, that little extra bump in efficiency and moral could make a large difference in the long run.