Have you lost sight of what a developer is?

As a leader, have you lost sight of what a developer is?

It sounds like an odd question. “Of course, we know what a developer is”. I’m not convinced having been a developer since the 1980's.

Think about it, how do you measure developer success? With metrics? I I expect so... and as you go up the food chains there comes an instant where individuals behind the data points are lost in the data. Comparisons will be made without context.

Don’t tell the Agile coach, but in the age of Agile, individual performance can be inferred from the burndown rates and fancy frameworks charts they delivery to senior managers each month.

Its a complex information story getting distilled.

The information provided to show continuous improvement starts to generate questions around individual performance as though they are on a production line.

For instance; at the end of every sprint, the number of completed work items or story points gets assessed. The junior, mid, senior and lead developers will have completed a quantity against an objective, usually set during sprint planning, (ofc. no one challenges the planning, but that is another story).

Anything not completed is carried over into the next sprint. Managers don’t want to hear about carry over. Carry over is bad. Carry over is project slippage and risk. Therefore, a developer’s success or failure is naturally proved against their marks, no matter how artificial. Scrum Masters may even provide a nice chart of carryover rates etc. in their senior reports. Their intention will be mid-read at some point. Of course, carry over can be avoided by lowering the target, giving the developer less to achieve within a given sprint. Problem solved, no carry over! It’s all nonsense, but how else can performance be measured when Agile ceremonies, dashboards and reports give us so such 'performance' data on an individual or their team?

How many of us have a heard a manager instruct “You need to increase velocity!” – I’m not sure they really know what they are asking - they used to ask, “Can you do it quicker”. The answer is often yes, caveated that to achieve the increase requires investment or a degradation in quality.

Development frameworks were never designed to measure performance, they are there to control and insight.

But why is this relevant to the title of this article?

What is a developer? When briefing a recruiter do ask “I need someone who can clear seven work items a week or forty story points a sprint”? No, the brief centres on skills and experience.

Similarly, no developer CV will mention metric rates either. CVs will demonstrate success on skills achieved, the stuff the author is proud of. Their involvement in projects…. sectors worked… you will never see “I can clear forty story points in a sprint” as a brag to catch your eye.

Through hiring, we admire a developer’s proven creativity and get excited on how it could benefit the team. We’ll even introduced them to the team this way. They are no different to an artist, graphic designer, fashion designer…. Development is a creative industry. Developers love to build and watch what they build make a difference. “I did that” is their success, not any burndown velocity.

It’s forgotten the moment they walk through the door. The interview questions around career and aspiration rendered irrelevant. Welcome to your treadmill and you backlog of endless tickets heading your way.

The problem is frameworks like Agile can strip out the creativity, blinding the developer to all but small components they are to deliver. Individual user stories at best. Creativity is lost, ignored. Velocity is king.

In the weeks from their new start, a developers creativity is satisfied learning new process, products, and technology to get their treadmill up to speed. These are usually the attributes that attracted a candidate to the job description in the first place. They are learning the skills required for their next role. Eventually the hunger diminishes as the new becomes known. Unless the creativity is fed their interest will wane, the job will become a job and no longer an exciting reason to get out of bed in the morning.

In the good’ol’days a developer was given a specification to deliver, a thing, and not a long backlog of stuff. Start-ups will still operate in this way. It’s why start-up developers love their job, if not the salaries that come with them. I’m not suggesting bigger SME return to this way of work, but there are merits in getting part way there. I, for one, still give project ownership to a developer to own and deliver, and structure their backlog around it.

The downside, managers now start to budget for the treadmill, expecting a developer to stay a maximum two years and we as managers get upset when they leave. The risk is mitigated by having people ‘coming through’.

As managers we need to remember the creativity in development, that it's a creative industry. The reason we do it. There is creativity in code structure, UX/UI quality, feature delivery… we need to know what floats a developer’s boat. Embrace it. Nurture it. Give them projects to engage with as a creative and ‘velocity’ will naturally improve.

Stop gauging them on the speed of the treadmill and treat them as creatives.

Remember why you hired them.