Confucius said: “To practice five things under all circumstances constitutes perfect virtue.” Be sure to not practice my number 5 of the top ten reasons projects go haywire.
5 – Weak managers or team leads
Managers are supposed to manage people. That means a lot of things: protect the team from frivolous distractions, make sure they have the needed resources, cull poor performers, and much more. Management is, in a way, much harder than engineering. If you perturb a system five times the same way, you’ll generally get five identical responses. Do the same for a person, even the same person each time, and you’re likely to get five different results.
“Managing” means, in part, setting directions, measuring progress, and holding people accountable for their work . I have seen too many examples of the boss letting the inmates run wild.
In AMC’s (available on Netflix) series “Halt and Catch Fire” the developers are young and completely unruly. They run around chasing each other, constantly throw things, and act like unparented beasts. This is not what I’m talking about. As long as the employees conform to company behavior standards, the question is merely “are they doing a good job?”
Management leads the team. Redirects the effort when things go off-track. Ensure everyone complies with the rules.
But this is rare, at least for firmware groups. When I do software process improvement work I find there usually is some sort of defined software lifecycle. But never have I seen a company where all the developers even know what that lifecycle is. Often some know about it but choose to go their own way. The boss seems to meekly accept the status quo.
Do you follow the firmware standard? The boss should provide mechanisms to check for conformance. That might be code reviews or the use of automated tools. But few teams do a good job of adhering to the standard, which to me is a management failure.
Sometimes management has no idea that the rules are being flouted. That means they are not doing their job of supervising the project.
The great quality guru W. Edwards Deming had what he called the Plan-Do-Check-Act (PDCA) cycle which he taught companies to use to improve their products. When you think about it, PDCA is great guidance for any sort of project, including software engineering. Plan: establish the goals and parameters used to achieve them. Do: do the work. Check: ensure the work was done correctly. Act: Take corrective action if needed.
Does management constantly interrupt your work? Or are you subject to a barrage of text messages, email, IMs and the like? If so, the boss is failing the team. We have plenty of data that shows interruptions drastically reduce productivity (see Disruption and Peopleware in the references for examples).
I’m sure each team member has a private office – right? Alas, cubicles are shrinking, and more companies are adopting open offices. The goal is more face time between people to, presumably, spark innovation. It doesn’t work, and recent studies have shown the open offices reduce face time by 70%. To quote from one (see The Impact in the references) “[An open office] is an open expanse of proximal employees choosing to isolate themselves as best they can, e.g. by wearing large headphones while appearing to be as busy as possible (since everyone can see them).”
Are you productive when sick? In open offices sick days are 62% higher than in private offices (see “Sickness” in the references).
Managers must find ways to enhance, not destroy, productivity.
Does management have a relentless focus on quality? If not, you can be sure little will sneak into the code. When the boss is harping on the schedule to the exclusion of all else, customers will be disappointed with the resulting product. Quality can and must be measured and held against known standards. For example, Defect Removal Efficiency (DRE) is:
DRE = 100 * (number of bugs discovered prior to delivery)/(number of bugs found in development and up to 90 days after delivery)
Defect removal efficiency rates. How’s your team doing?
I do think a number of bosses are subliminally afraid of software people. When Joe refuses to use Lint, for instance, he should be first, asked, second, persuaded, and third be made aware that continued employment means following the team’s rules and software development lifecycle. Period. If one of the accountants felt that double-entry bookkeeping was optional, you can be sure action would be swiftly taken. I don’t see why the same shouldn’t apply to developers.
Yet it’s common for software bosses to look the other way when there’s a lack of rigor. That’s not management.
Next week: the peril of being optimistic.
Disruption and Recovery of Computing Tasks: Field Study, Analysis, and Directions , Shamsi T. Iqbal and Eric Horvitz
Peopleware: Productive Projects and Teams , Tom DeMarco and Tim Lister
The impact of the ‘open’ workspace on human collaboration , Ethan S. Bernstein and Stephen Turban
Sickness absence associated with shared and open-plan offices , Jan H Pejtersen, Helene Feveile, Karl B Christensen, Hermann Burr
Jack Ganssle ( ) writes, lectures, and ruminates about embedded systems. His blog is here: www.ganssle.com.