For years I’ve questioned the stubbornness with which companies cling to the Industrial Age’s workplace environment and management strategies. In an age of new technology, new work skills, and a new desire by employees for an opportunity to go beyond being simple workers, to creative influences with input and ownership of their projects, so many companies and managers continue to treat their employees like expendable resources that can be burned down to ash and simply replaced with a new job posting. As well, work environments are stale, don’t inspire creativity, and fail to treat the workers as responsible adults (which, by the way, inspires them to trust you and perform at a higher level).

Two articles were published this week on these topics. First, from Robert Dempsey of Rails for All and Atlantic Dominion Solutions, with his article The Changing Role of Managers, in which he discusses how his role as Project Manager has evolved through trial and error, and describes his main role as PM with these words:

The main role of the scrum master [project manager] is to remove impediments that hold back the development team from being productive. Impediments might be lack of tools or clients taking a long time to respond. The scrum master also ensures that there is as little outside interference as possible.

He goes on to say that the manager’s role is that of leader, and that trust is a major element in team success. He provides a list of books he read as well on the topic.

In the second article, from Jason at 37signals, titled, Workplace Experiments, he discusses some of the new benefits they are experimenting with to keep their team fresh and happy, and thus in the end, far more productive than the teams that work away their lives (not to mention cutting down on the high hidden cost of employee turnover). 37signals is experimenting with:

• four day work weeks
• helping pay for their employees to learn new things and expand themselves; everything from learning to fly to learning to cook
• credit cards for discretionary spending (books, conferences, software)

Not all experiments may work, nor be affordable forever, but I loudly applaud the effort to shake things up, treat the employees like you really value, respect and trust them, and make an effort to look for new ways to enrich their lives and help them fulfill their passions.

Remember:

How we spend our days is, of course, how we spend our lives.
~ Annie Dillard

My favorite web development company, 37 Signals, recently added a post by one of their team members, Jason. He discussed some of the decisions and process that went into a recent functionality addition to their product Highrise. They set out to provide import functionality that their customers were asking for, but in their pursuit of a solution they got off track due to thinking too large.

Sometimes development and design teams can think too small, and not see the forest through the trees, but at other times, and I see this a lot in the IT industry, development teams think way too big. They see a problem and instead of focusing on the important issue, they attempt to provide functionality just in case they might need it some time down the road. But just in case development is very costly, and from my experience, most times that “case” never actually occurs.

The point of Jason’s post is that in this instance, not only did they waste time, but they also didn’t even provide the needed functionality, because they lost focus on the particular problem that really needed the must urgent solution.

In Jason’s words:

…don’t lump a bunch of related small problems together—it just makes one big problem. One big problem requires one big solution, and big solutions take a long time (and often don’t go right). You’re better off chopping big lumps of problems into smaller chunks until you’re able to knock them off one at a time.

Read the entire post, “Design Decisions: Highrise import“.

Recently, Matt at 37signals wrote a post about taking a break from your programming task after four hours.

The comments of the post took a detour from the main point, which was to stop and take a look at the task and your direction with it. However, most of the comments seemed to focus on taking a break when you are stuck. It’s true if you hit a wall, you should take a walk and try to get some distance from the problem. You’ll often then be able to see over or around the wall, or realize the wall is actually only a figment of your imagination.

But I think the point to this post was to take a break from your task, after you’ve spent about four hours on it (though the time should be in relation to the size of the task), and reassess your current status and direction, and most importantly, if the task should even continue to be done.

Sometimes we think of a solution, but while working on it we hit road blocks; things that we weren’t aware would be a problem. An example might be using a new technology we thought would solve the problem, but in doing so we introduced new problems. As programmers, as thus problem solvers, we get so focused on solving the problem at hand, we need to take a step back and realize that the direction we are going is more work than our nifty solution was worth. Adding this new technology, for example, might turn out to add far too much complexity, and require too many other solutions to get it to work.

There may be times where, after taking a break and re-evaluating, we have to go back to the Project Manager, Team Leader, or whomever you report to, and let them know the task is not nearly as simple as you thought, and more time needs to be allotted. After reporting this, you may find that the task you are assigned to is no longer quite so important to management, knowing it will cost them more.

I’d like to add, that taking breaks from tasks, and taking time to clear the mind, and step away, is such a vital part of being a problem solver, and yet it is discouraged by the very nature of the 8 hour work day modern IT management stubbornly continues to conform to. My personal belief, is that some days should be 5 hour work days, and others might be 10. Or, you may work four hours in the morning, and four in the evening. We need to be free to stop what we are doing when it becomes clear that we are no longer making progress for whatever reason. We could be tired, we could have hit an unexpected wall, we could have a personal issue that is distracting us. In many of these cases, its much more efficient to stop, and do something entirely different and come back to your work later, than to attempt to press through, and possibly waste countless hours making absolutely no progress.

This requires management to assess your effectiveness by what you accomplish on the project and with the team, as opposed to what hours you are sitting in front of your computer monitor. For some reason that shift in people management has been very slow in coming. I know some companies, teams, and managers that understand it, but I think the majority are still far behind; still stuck in the industrial age of management styles.

Read the entire 37signals article, “Four hours upfront and then reevaluate“.