I've always held the opinion that happy programmers are a true reflection of how well your project is going, how much adaption it will get and eventually how much money it will make. After all, it is the happiest programmers within your organization that often, show you the money.
If your programmers do not believe in what they are building and want to quit a project, your only chance of survival or getting that project close to any form of success is letting the unhappy individuals move to projects where they might be happier and getting people who might be more connected to the project, into the project.
If none of the programmers in your organization want to associate themselves with a project, it is high time you rethink what you are building. Maybe even consider closing down the project all together. Chances are, that a team working half heartedly on a project is just going to produce strong or mild variants of f@#k-you code and your project is not going to go anywhere anyways.
Having said that, citing 'Programmer Happiness' as a measure of how successful a project or an organization will be, often causes people to knit their brows and look at you like you just dropped a dead rat on the table.
People in general and organizations in particular that I have talked to, often tend to ask for slightly more objective measures and signs they can use to see if everything is fine at an organizational or a project level.
It is in the interest of a young and budding startups or relatively newer organizations that I present to you, dear reader, my very own personal guidelines on when you should be nudging your team members to raise a red flag, stop working like programmed robots and bring the issue up, even if it involves indulging in what I call a skip.
At an Organizational Or Team Level It Is Time To Raise RED flag If:
- Your daily meetings or daily project calls are consistently crossing thirty minutes and your team is getting addicted to meetings.
- Your team is consistently staying late without being particularly excited, happy or passionately connected to the project.
- Your team is consistently doing regular grunt work, like pushing a build or fixing bugs, even on weekends.
- Your team is not taking any happy hours.
- Your team is being constantly asked to build features which are not really needed.
- Your team or you are confused about where your role stops and where the role of your manager begins.
- Your team is facing constant intimidation from a client or a manager.
- Your team is allocated tasks with concrete timelines without having any involvement or say in those timelines.
At a Development Level It Is Time To Raise A RED flag if:
- Your team has parts of the project or the database which are not being checked into the source control system.
- Your team crosses more than a month and a half without shipping any new sprint or any new features.
- Your team works on and ships more than three sprints without any real feedback from a real beta user.
- Your team consistently writes functions that do not fit a screen.
- Your list of 'Active Critical Bugs' consistently shows a scroll bar and does not fit in a screen.
- Your project requires a developer to carry out more than ten manual steps to get the source control system, set it up and fire a build.
- Your team tends to have an alpha-geek who often decides all critical design decisions with very little scope for discussion or argument.
The list of course is very basic and will grow over time. In fact, this is where I expect you, dear reader, to throw in some comments. If you, are a manager running multiple projects or an entrepreneur running an organization which RED flags would you want your team members to bring to your notice as soon as they happen? If you are a developer which RED flags would you like to raise as soon as they happen?
Go ahead, drop in your comments. Discuss.
Comments are closed.