Authors note: This is a multi-part blog series covering a number of topics discussed in our mini-summit. Part 1 can be found here. 

SCROLL_TEXT

Management Methods and Developers

Our discussion revealed that heavy production-line management methods factor into low developer retention. The question we heard here takes the general form: “How do we convince management that we are not blue collar workers?”

The modern means of production is the intellect. People who think for a living are going to have a very different reaction to management techniques designed for repetitive work patterns from the manufacturing age – because they’re the wrong models.

Developers don’t need to be managed in the same way as physical line workers because the work we’re performing is not physical and the work we maintain is often not “visible” in a traditional sense.

Traditional management equates activity with productivity and when they see developers thinking, reading and quiet thoughtfulness, but not typing – they get anxious. They have been wired to look for a physical activity to mark productivity.

Businesses who are trying to attract knowledge economy workers with production-line management techniques, will continue to exhibit high turnover of good IT talent.

Managers and Developer Retention

When a developer talks about the environment, or the culture – often they are talking about how the processes and management practices in place are misaligned. Some consistent differences in worldviews came up in our discussion – here are a few.

—Reactive Management

"This is now the most important thing!” These style managers can only pull that trick so many times before they loose credibility. Developers are counting on managers to determine what is truly valuable to the organization and not create ADHD LIFO work environments.

Reactive management styles get the immediate gratification sought, but they accumulate to unstable damaged software systems over time that developers are too afraid to touch. When they do, they are asked to take responsibility for things that break – those historical contradictions in business rules born from “just this one little thing…”

Reacting to everything that moves, is a sign that management is not in control of business. It’s a sign that they lack alignment, and have not taken the time to determine what is important to the organization and its clients.

Environment – the mess of code that is created from knee-jerk decisions – is a large trigger factor in developers exiting.

—Priority #1

Value – is the ability of a manager to understand that not everything is a top priority and that solving the right (bigger) problems, makes smaller ones go away over time.

When managers can’t organize their top 27 priorities, this speaks of organizational instant gratification cultures spiraling out of control. They often expect their developers to be simultaneously working on these top 27 priorities and they have difficulty in understanding why nothing is getting done.

These environments cause developers to work extraordinary hours – the old world value of working hard as opposed to working smart. This puts the sort of unnecessary stress on developers which ultimately pushes them out the door. Anyone showing competence in these environments are asked to do increasingly more, and will finally crack.

—Multi-tasking myth

Many production era managers are still stuck in this often debunked fad from the 1990’s. They are blissfully unaware of the waste associated with context switching – measuring instead, the flurry of (failed) activity.

Constantly juggling produces little to no real progress – but appears insanely busy.

The false managerial expectation is that when a developer is switched to a new task, that the previous task is still somehow getting done. If not, then that developer has to make time outside their 40 hours to give that false impression – unfortunately, confirming for the manager that multi-tasking "works."

—Moving between Projects

There is large (unmeasured) organizational cost in pulling developers mid-stream between assignments. The procedural cost is the continual ramp-up time involved in “getting my head back into it.” The cultural cost is jerking people around and not allowing them the job satisfaction of delivering something. Developers aren’t fond of this and management falsely expects zero ramp-up time and no cost associated with context switching.

—Hours versus productivity.

Production-line managers who are still preoccupied with work hours physically present as opposed to work produced, are still stuck in factory clock-in/clock-out models. They directly (and wrongly) equate hours worked with productivity and busy-work productivity with progress. They misunderstand the work being performed, and are a factor in developer turnover.

Organizations who actively take pride with some number in excess of 40 hours per week as a marker of higher productivity, have lost the plot. We are in an economy where working smart should prevent working hard as some badge of honor. Working hard is thinking – not counting hours.

You wouldn't want a pilot working extraordinary hours nor a surgeon. Costly mistakes get made. Knowledge work deteriorates after 40 hours and you are not getting more done. In fact, you are often damaging the system (and the worker) with fatigued intellectual decisions and code.

—"We work Hard around here!"

When developers hear that “we work hard around here” it’s a red-flag to poor process, lack of thinking, overreacting and inability to change the right things. Technology should be making lives easier – not harder. If things are getting harder, it’s a signal that management is not supporting and listening to its developers when they ask to fix things.

In knowledge work, you can be physically present, but not producing intellectually. The historical bias for a "butts-in-seats” mindset does not necessarily reflect environments conducive to quality knowledge work or productive output. But it’s often the only one we know.

—Held to ransom

This moving of reactive, instant gratification “needs” into the responsibility realm of developers (to be held accountable and blamed later,) is a cultural exit factor. No one likes to be held accountable and forced to take ownership of a whim based or poorly thought-out decision by someone else.

Developers like it less because that decision ended up in the code – the thing we’re meant to own. The organizational impression is that IT must have been involved in that decision. This is how gate-keeping starts and how IT becomes non-responsive – because they get tired of getting blamed for the poorly thought-out siloed decisions of others.

—Forced Ownership

Because memories are short, we are often asked to explain why a decision was made. We can look into the code and tell you what the system does, but we can’t tell you why a manger wanted that particular change and why it was done.

This is how excessive documentation and “contract” style process begins. Agilists are constantly having to learn this repeating human pattern. CYA finger-pointing cultures deter collaborative developer personalities – they shut down, and give the bare minimum.

Managers who are used to getting their own way without question and associated responsibility are often able to plausibly deny and mis-remember their last minute requests.

Demanding that your developers be history majors producing audit trails for reactive management 11th hour decisions will factor into low employee engagement and thus low retention.

—Fire Drill Cultures

Adrenalin junkie managers who are addicted to urgency/emergency modes of operation actually prevent developers from finishing work – creating vicious cycles of escalated urgency. They typically have more interest in starting new things and manipulating tasks in motion rather than actually finishing them.

These cultures are not sustainable and factor heavily into workplace mental fatigue. Developers who are asked to constantly react to some new whim that damages their environment, will eventually crack and leave.

—Wasteful Coding.

Not being able to finish a task is a large factor in developer job dissatisfaction. Having to throw away copious lines of hard-worked code due to fickle whims and continuous mind-changing will cause developers to initiate a go-slow until they get a good sense you really mean what you say this time. If that culture persists for long periods – this will factor into developer exit tension.

—Lack of support

Lack of support from managers to make things better also ranked as a key reason for developers disgruntlement with environment – and a large reason for leaving. When developers realize that no change is going to happen, they will look to be productive and helpful somewhere else. They like progress.

Organizations who are stuck in “this is how we’ve always done things” will not retain good developers very long. Our industry is about change, improvement and progress. We want to make things better, but when we see resistance to improvement, we start looking around.