Units of Men

This isn’t a sexist topic. It could be “units of people” for all I care, but that doesn’t fit into the reference material as well. For over 40 years we’ve known about the idea of the Mythical Man Month presented by Frederick P. Brooks. He wrote this collection of essays in 1975. There is no excuse that every software development company should provide every manager a copy of this book and that every manager should encourage every employee to read it as well.

The “Man-hour”, “Man-day”, “Man-month”, “Man-year”. These are all great units of cost — it may very well have taken 10 men (people) 12 months (days, fortnights, whatever) to build your product.

This thinking goes wrong when people begin to attribute the idea of the “man-unit” as a unit of effort. Progress does not linearly decrease based on the number of people assigned to a project, unless everyone can work, in parallel, with no comunication between them. Using the “man-month” as a unit of measure for the size and scope of a project is a lie. It’s a myth, Mr. Brooks would say. It implies that men and months are interchangeable.

Because of the serial and sequential nature of software development, it’s inherently impossible for more people to equal less time on a linear scale.

Often, it’s faster for fewer people to produce an end product as well — if the size of the team is drastically too large, the cost of training in technology, goals, overall strategy, and work plan is immense!

Since software development in inherently complex and communication is essential to success, adding more people to the project will quickly lengthen, not shorten, the schedule.

The bearing of a child takes nine months, no matter how many women are assigned. — Frederick P. Brooks

Meetings

This topic is a red-herring. I just wanted you to read at least one section. People want to circle-jerk the idea that satisfies the fight AND flight response that everyone has towards boring meetings. Any management self-help book in the bargain section of Barnes & Noble will tell you that Meetings are Toxic.

This is a blatant lie and a dangerous one.

With offices all over the world, a single face-to-face meeting often accomplishes more than a dozen e-mail strings, phone calls, video conferences and instant message ever could, if only because every invested party is in the same room. When it gets down to crunch time on a project, regular, even daily meetings really help avoid miscommunications that can make you miss a deadline. Daily Stand-ups/SCRUMS are exceedingly useful if executed correctly. Nobody doubts the effectiveness of meeting in these cases, because the meetings are obviously productive, that’s not to say always pleasant, but that’s a separate issue.

So where does this “meetings are toxic” waste originate? It comes from people trying to use a process to avoid having to actually lead, take a stance, or take responsibility.

The example that springs to mind is the “Weekly Update Meeting”. This meeting exists because the idea that people should know, vaguely, what each other are doing is a good idea. It probably started out as simply an email thread every week, or a Word Document that everyone updated. Trouble started when people stopped reading what other people did or even stopped contributing. Someone, instead of taking a stand and dealing with the situation personally with the infringing members, decided it was a better idea to institute a weekly meeting in which everyone verbally gives an update of what they did during the previous week and what they plan to do during the current week.

This is an example of someone using a process (meeting) to substitute for when they should be leading (disciplining). Almost every organization and every sub-organization inside it now has these weekly update meetings and 90% of the content can be taken offline and consumed at the employee’s leisure.

Process is not a substitute for leadership. — Jay Garmon

Many useful meeting exist. Many useful meetings that don’t have action items also exist. Although, these meetings are called “training”. Just because a dog bites you doesn’t mean you should kill all dogs. The same goes for meetings. Meetings aren’t necessarily toxic. Lack of leadership is toxic. Killing all meetings because your leadership is bad is just converting one form of bad leadership into another.

Aside: On the topic of status update meetings and yearly reviews, I had a friend present this idea to me: in addition to having your employee tell you what they accomplished, have them tell you how they failed. Failure is part of the process of learning, and if you don’t fail, that means you aren’t trying new things, and if you aren’t trying new things, I don’t want you working for me.

Rotation

First off, I need to say that if someone feels they’re not in the right position, then they should move and find something they enjoy doing — hopefully their manager(s) will help them do that, be it inside or outside of the company.

Now, with that out of the way, forceful rotation or movement of teams/products is a TERRIBLE idea! Sometimes there are ounces of business sense, such as a product being phased out, so we’re moving people off that project onto others. Not much you can do about that. But the childish power-trip of a single person in executive level management, for a hypothetical, should never be allowed to reassign entire divisions at their leisure.

We may assume, by intuition, that stable teams perform better. In fact, there is research from Rally on Agile methodology performance metrics that upholds this (sorry, paywall).

Keeping a team intact for the long term resulted in 60% more productivity; teams were more predictable and responsive.

This metric furthers along the point of the four-part team lifecycle: Forming, Storming, Norming, Performing. It’s extremely obvious that a team is the most productive in the “Performing” stage, and if you’re rotating team members, you’re breaking the team and repeating all these stages again and again. It’s possible that the Norming and Performing stages would never be hit if the rotations are too rapid; the team would be in a constant state of Storming.

Overtime

Overtime should be reserved for the sprint to the end (which, in reality, shouldn’t exist if proper Software Development Lifecycle practices are followed) or when something like a server goes down or there is a bug in live code. These should be extremely rare exceptions though.

I’m personally very guilty of this sin; I find myself working much more than 40 hours nearly every single week. Working overtime is just a nice word for “workaholism”.

Workaholism is stupid. It’s dangerous. It doesn’t mean you’re more important. It doesn’t mean you’re getting more done (it actually often means you’re getting less done and need more time to do what you should have done OR that you have too many things to do for a single person and that your superior should recognize this and help delegate things off your plate). Workaholics often create more problems than they solve, since they’re less rested and alert when they are working. It’s also not sustainable at all, the burnout will come, and it will come that much harder. Believe me, I know.

Open Space

Open teams breed collaboration, open offices breed distraction.

I have worked in a completely open office. I have worked in an office with high cubicles. I have worked in an office with short cubicles. I probably will end up working in an office with pods sometimes in the future.

I already discussed that small, dedicated teams are a great thing, and having the entire team in a relatively open pod, with whiteboards, tables, and other surfaces that afford collaboration between team members is phenomenal.

Having an office with only 4 walls and everyone works at tables with no separation is a nightmare. It’s extremely hard to focus with a constant buzz around.

Even with short walls, I listen to music nearly non-stop in order to drown out the annoying lady constantly yawning across the way or the man who deems it necessary to speak in the 100 decibel range at all times. Sometimes I just have my headphones on with no sound coming out of them in order to not be distracted by people trying to talk to me so that I can hold an entire model of a process in my head without interruption. And I know I’m not the only one.

Multi-tasking

First off, there are two types of multi-tasking: When you are coding or answering emails while in a conference call at your desk and when you have several independent tasks to complete and you constantly switch from one to another. While both are bad, the second is much worse. Especially since the first may be a side effect of the previous Overtime and Meetings sections.

I’m guilty of both, I need to focus better. Context switching is a huge productivity killer.

How do I combat this? I try to limit my notifications. I put my phone on silent and charge it out of sight so I’m not tempted to check it. I turn off the notification indicator on Skype. I close my email. I block Facebook on my own computer at times. It’s incredibly difficult to do though! I fail at it all the time, but when I succeed, it’s just an amazing feeling!

Sometimes though, communication is necessary. I often have important conversations with co-workers via Skype that would burn out far too much time face-to-face, or would be impossible to share code between and such.

The key to this is limiting scope. Skype is often just 1:1 conversations. Those are quick, easy, and useful (sometimes even as a break!). We need these communications channels. The ones that get in the way are the bulk (spam?) emails from the corporate channels to email at strange hours of the day. First thing in the morning would be fine. Maybe during lunch. But at 10:12am or 3:27pm? These are the times where I am fully engrossed in my work, and if I receive an email, I expect it to be extremely important and worth my time. Not a corporate message telling everyone what the most common birth month is for people working for the company.

Management

Upper management and Executives often have their fingers in too many pies and on too many day-to-day activities. This does nothing but bog down the process.

Middle managers far too often are too complacent in their position — they make enough money to be happy and if they can get away with doing less and less “actual” work, then they’re happy to be where they are.

In order to fix those two levels, one of two things has to happen: the entire company is restructured to remove the archiaic structured hierarchy and flatten out, or, those people have to retire and younger (well, different, they don’t actually have to be younger. This isn’t Silicon Valley [the place, not the tv show] and I’m not Mark Zuckerberg , I don’t discriminate solely based on age) have to fill in who are ready and willing to shake things up. People who are willing to take a chance. People who are willing to be heard.

Some software development companies remind me of the Southern United States in the late 1950's — trying so hard to hold onto their old ways, not wanting to do the little bit of work, to give up a little bit of privilege which is required to make things just a little bit more tolerable, a little bit more happy for everyone around them.

*steps off soapbox* — everyone who has had an opinion, ever

Lower Management is where a difference can be made by the individual. First off, every manager should strive to be a “Leader” rather than a “Boss”. This concept is shown beautifully by the below craft. Understand it, memorize it, live it (except for the part where the mission will come crashing down the second after it falls off the logs). This will make your employees respect you and go to the ends of the Earth for you!

I often hear it, especially from managers with junior employees straight out of college: “I don’t want to be your mother”, and my only response to that is: “Then don’t treat me like a child”.

Many managers come off as accusatory, instead, they should let me explain myself, let me give my side of the story. Innocent until proven guilty. How do you expect me to want to do any work for you when you give me zero freedom and micromanage my every move?

Warning: Deep Metaphors ahead, proceed with caution.

Many management schemes view developers and other employees as resources. Some people may have an issue being labeled as a resource or an FTE (Full-Time Employee); I am not one of those people, as long as I’m treated as the proper resource.

Many times, we’re viewed as water. There are two types of liquid water on this Earth, Fresh and Salt. For the purpose of this metaphor, Senior Developers are Fresh Water, and Junior Developers are Salt water. There are significantly fewer senior developers and they are the lifeblood of the enterprise. They keep the product running and satiate the nigh-endless thirst of the Executives and Shareholders.

Junior Developers (Salt Water), on the other hand, are treated like the ocean. There are many, many more of them, and they’re not nearly as useful. In fact, many of them are treated as the ocean to keep the Cruise Ships that are Executive level management afloat.

The Water Metaphor (trademark pending) is a dystopian metaphor because it assumes that everything boils down (ha) to the same thing. Steam and a bunch of hot air.

Instead, I present The Tree Metaphor. People are instead much like trees. There are many types of trees. Some trees grow quickly and bear fruit for many, many years (fruit trees as talented developers). Some trees take many years to reach their full size, but then are able to support entire ecosystems on their own (Redwoods as effective managers). Some trees are just meant to be planted, pop up quickly, and then be cut down for use (various types of lumber trees as contractors). Some trees take love, years of dedication and pruning, and don’t get very large, but instead fulfill a niche that none other ever could. (Bonsai trees as initially trouble-some developers turned into someone great in their field and that you wouldn’t trade for anyone else no matter the cost — it would be like losing a family member). I could continue on, but I think you get the picture.