Recently, we hosted a mini-summit (definition: beer and pizza) for mid to senior level developers to get their take on workplace culture through the lens of software development. We found a number of things in common, and a few interesting variations that help to describe the nature of our field in both a business context and beyond.

But first…

The problem statement:

Late last year, we attended a small but well attended lunch time event with local organization execs who were struggling with the IT talent retention puzzle. The conversation turned quickly to the usual suspects: flex-time, jeans, remote work, pay scale and even ping-pong tables.

Many of these organizations were employing the same incentives, and yet the costs (measured and unmeasured) and developer turnover rate remained higher than they would like.

The conversation begged a number of questions about developers, the work we perform, motivation, incentives, IT environments, company culture and the town we live in.

Were there other causes behind the revolving door or was this just the nature of our industry? How could we attract and retain software talent from outside our town to live and work here?

• Do developers need to move every couple of years to stay technologically current?
• Was it the technology itself attracting developers, or stale technology stacks pushing them out the door?
• Are software developers as a profession intrinsically motivated differently?
• Is there a prima donna situation?

Being privy over the years to developer worldviews (yes, I was a developer too for many years,) I am always curious about a number of things:

• Are there local organizations where developers could point to as an example of a great place to work?
• Conversely, are there organizations where seasoned talent would never step?
• Knowing that developers talk, what do they say to one another about your company and IT cultures?

Are these the sorts of things organizations would prefer to know?

Regardless of the answers to the last questions, I thought it a good exercise to start a conversation, get some feedback and hopefully continue the conversation. Publicly.

Summit Feedback

A point of thanks to the participants. We were not disappointed by the extremely honest feedback and healthy discourse on the topics posed. It was a pleasant mixture of personal and professional opinions and observations from folks who voiced intelligent and introspective views on our roles, our industry and business.

There was no true consensus on every issue, telling us that we had pulled a good cross-section of opinions and experiences together.

Revolving Door

The recruiting game continues to be a cycle of poaching talent from organizations and moving it to others – using traditional incentives. That seems to be our circular status-quo – fighting over the same high-talent developers – rather than thinking about developing new ones.

Some larger organizations have been able to break from a complete dependency upon local talent and recruit nationally to fill the gap. But in general, large amounts of money are exchanged every week in this talent acquisition game.

With so much money being spent, with the continued high turnover and with a shortage of the same particular skill sets, wouldn't it be good to know why they stay and why they leave?

Incentives – apples to apples.

Are software developers intrinsically motivated by different things than traditional Management/HR incentives?

It appears that the incentives themselves are OK, it’s just that they are not a complete picture for what motivates developers. Traditional incentives appear to factor into talent attraction – a sort of nice to have, permission to play benefit. They are used as an apples-to-apples comparison list when developers are seeking new employment.

If the only thing holding your developers is money and traditional incentives, and other companies are offering those similar pay & benefits – then what’s the differentiator when all the apples equal each other?

Ping-pong and other Distractions

Organizations attempting to emulate silicon valley IT cultures by adding ping-pong tables and other creative areas, often end up having it backfire. Either management doesn’t quite grasp how to enable it correctly, or it misses the motivation mark completely.

Furniture is not culture. These approaches can also backfire by assuming all developers are collectively motivated in the same way. They are not – as not only our discussion revealed – but our metrics validated. (We’ll talk about motivation a little further down.)

Companies who offer these play-pens – but whose core culture is still traditional Command and Control mindset – send conflicting messages to developers. This sort of gimmick looks good for talent attraction, but generates more personal scrutiny for employees: “We want you to be creative, but in some established way.”

The conflict and confusion here is that traditional process cultures see this as play-time – a sort of celebratory reward for having already delivered something. As a result, these privileges are hall-monitored and productivity continues to be measured as butts-in-seats over value delivered.

The nature of the work – What is it we do?

One of the common topics that all the developers agreed upon, was the general misunderstanding of the work we perform. It leads to the wrong models of process and management being exercised – which in turn are key environmental factors generating developer disengagement. (This is also why developers attempt to address process as the key source for changing their environments.)

IT workers – especially software developers – are knowledge workers. Our work is not physical – it is intellectual. We are in the same category as Doctors, Architects, Scientists, Inventors, Researchers etc. The “doing” is now actually the thinking – however, old-school metrics on physical labor would have the “doing” as typing and counting lines of code.

What is “knowledge work?"

Much of the work we perform is problem solving. It happens when we are thinking, researching, experimenting, learning, brain-storming (talking,) collaborating, reading the code, driving to work and even in the shower. I used to keep a notepad by the side of the bed for when I woke up in the middle of the night with a eureka moment that solved some technical issue.

The brain is the tool here and blue-collar analogies to building, toolkits and speed of execution (velocity) fail because the majority of our work simply doesn’t resemble physical construction projects or moving production lines. Our work is simply not linear – and the job is never complete. (IT pundits pushing these models are actually doing us a great disservice in changing this mistaken worldview.)

We learn as we work. We are learning how your existing systems work – and how decades of historical decisions (technical and business) are now affecting every aspect of your organization. We are learning new ways of coding – as we code. Newer methods and frameworks are constantly entering the marketplace, and we are contiually trying to keep pace so as not to let your organizations fall behind. We are learning your industry and learning the politicking of influence on the software needs within your organization – as we go.

(The next post will cover Management conflict.)