Having a software team means that you are in for the long haul of continuous improvement. Only part of that looks to improve the technical performance of an individual team member. For my money, a quick way of “levelling up” a developer is to get them thinking about, and acting upon “the 3 P’s”, specifically:

Pain – how good is their ability to “see” the customer’s pain,

Price – how good is their understanding the commercial realities of their work,

Plumbing – how good is their understanding of the technical infrastructure on which their software has to run.

Pain

Key to the performance of software teams is the ability to deliver software that meets the customer’s needs. As an industry, we’ve tended to think of this as a matter of “putting the customer in the middle”. For me, this works better if the developers understand why someone is paying for the software in the first place. This means that customer understanding is all about sales.

Sales itself is all about pain, or rather the process of selling anything is about proving that you can resolve whatever pain the customer has. “I’m going to get fired if I don’t find some way to increase the efficiency of this department,” is an example of sales pain. All the software salesperson in this instance has to do is convince the customer that the software on offer can resolve that pain. “If you buy my software, we can increase the efficiency in the department, (and you won’t get fired!)”

Most development teams are set-up to access the customer as a tame resource for information, but most software teams do not look to join the engineering process up to the sales process. You’ll get better results if you do, because each developer knows why they are building what they are building.

Price

When a piece of software is commissioned, there isn’t necessarily a “sales” process. An organisation might write a business case, and then give the project to an internal team. (Of course, that same organisation might buy the software off-the-shelf, or outsource it.) However, the actual transaction is done, there still is a price. The organisation will build a business case, and that business case will have a budget.

Going over budget is something that needs to be optimised out of a team. However, most teams do not give a developer the tools to understand what the commercial impact of going over budget. Yet all developers are good enough at the sort of basic maths to work this out. You can give developers assumptions – tell them the salary, employers NI, the number of days they work in a month (hopefully 18 days a month), and a rough figure for accommodation, and IT support. The figures I use is that a £60k pa developer will cost you £300/day, ignoring project management, and QA resources.

With a figure in their head, a developer can then work out the rest of this problem for themselves. A 50-day project allocated to them costs £15k for the raw development, or rather the organisation has budgeted £15k for completion of the work. If they take 20% longer, that’s 60 days, or £18k. Tying this back to the first point, the developer is able to say fixing that that particular “pain” has a value of £15k to the customer. Someone somewhere has to absorb that missing £3k.

Plumbing

The last one that I find very helpful is encouraging developers to get deeper into the “sysadmin” side of things. A developer who can understand more about how the technical work that the IT operations team actually does is a more powerful developer.

The principle of DevOps is that you have two teams with very different disciplines, but both trying to achieve the same goal. Whatever those teams are, a more sympathetic understanding of the details of each other’s goals, the better – both from the perspective of building something that is practicable from the get-go, and from the sense of fostering new ideas. From the developer’s perspective, this means a “stronger” developer has a better understanding of how to configure group policy, set-up firewall rules, optimise databases, can source and recommend infrastructure products (e.g. Cloudflare), and so on.

The challenge here is that most developers don’t organically end up in this space. It’s likely a developer knows how to set-up a server, and install services, but unless they’ve paid money out of their own pocket, or been intentionally exposed to such things, some of the deeper infrastructure pieces they will not.

Another growth area that is important is to get developers to fully explore and experiment on AWS and/or Azure. I would go so far as to recommend setting aside specific budget for each developer to do this.

Conclusion

Of the three aspects we’ve discussed here, the idea is that each developer should be able to execute well enough on these roles, such that at a push and with all the stars aligned correctly, and if you imagine they were working in a small SaaS business, they should be able to be a salesperson who can sell the software, and/or a manager who can run the budget for the project, and/or a system admin who could take over the IT operations roles.

It seems like a big ask, but you’re not necessarily asking them to do this – you’re just asking them to understand each well enough that they have a better understanding of where their role fits into the greater picture.

The power of banning the word "bug"

Software developers don't think twice about referring to "bugs", but customers don't care about what causes there issue. They just want their problem understood, and a solution put into place. Banning the word "bug" is a very powerful move.

It's 2018, and it's time to use TypeScript

TypeScript can have a profound, positive effect on making complex JavaScript codebases easier to maintain. You definitely should be using it, regardless of where you sit on the static vs dynamic-typing debate.

Software engineers, or software developers?

One of the age old questions in our industry is "are we software engineers, or are we software developers". We want to be "engineers", because it sounds more worthy... but in this piece I'll argue we're actually "developers".

Share

Our evolving "Digital 247" Software Architecture Methodology helps us guide our technical leadership. We maintain it
in two forms — a benchmark that you can fill out to get a feel as to where you are with regards to your
peers and competitors, and a 7,000-word downloadable white paper that is free to download and is full of
helpful information and advice.