Good communication is far superior to technical expertise

Soft skills training

I recently got involved in a program which helps IT professionals improve their soft skills. It’s primarily a cultural activity and we’ve got some really clever people. However, I instantly felt that the way people talked to each other was different from what I was used to in my home country.

This program is designed to show the cultural differences one might face. Things like “asking questions in the UK is seen as a positive” (active listening), whereas in other countries it can be seen as lacking qualification. It also goes into detail about tone, and how to phrase questions in a professional way avoiding cultural slip-ups.

Sometimes the developers, testers, and QAs don’t immediately see the value of the training sessions they go through. They are experts in their domain. Why would they need to learn how to ask questions? These are wishy washy skills which have no use in the world of serious software development.

The following is a far less subtle example of why good communication matters. Think of the program I just described as one of the higher steps to stakeholder mastery. The initial rung would be talking to your stakeholder on a regular basis!

Sticking to your task in a changing environment

Back in 2008 I started my coding career in a small but growing company. Like many in the industry, I was given scraps of paper with a list of requirements. Over time, these scraps morphed into stapled sheets. Using these pieces of paper, I was expected to make little tweaks, or overhaul whole systems architecturally.

These were complete ATSs (Application Tracking Systems) that helped with the Recruitment of Graduates.

As a new junior, I diligently set to work and coded. I would make sure that everything was done to the standard and I believed it to be ready. Unfortunately, my definition of readiness wasn’t the same as my stakeholders’.

Being a programmer, I focused too much on the details. Straight out of university I wanted to make sure that everything was bulletproof. Add to that learning on the job and the fact that sometimes I was painfully slow.

After about 6 months, I’d learnt the existing systems in the company, was much better at coding, and a bug issue tracking system had been put into place. Bugs were assigned to me and I’d rattle through them all as quickly as I could. We had a good process, I’d look at my list of bugs online and work through them. The scraps of paper were gone. Each bug resolved gave me a little hit of dopamine; I was enjoying work.

With my confidence and reputation increasing after bug heaven, I found myself looking after and creating a brand-new system from scratch. Once again, I received my stapled sheets as to where the system varied from the norm and I was off on my merry way.

Each system was bespoke to a client and the methodology went as follows:

• Copy and paste an existing client’s system.
• Hack it around until it matches the new clients’ requirements.

Being too sure of my own abilities and not knowing how long software development can take, I decided to write my own perfect system from scratch.

What was initially meant to take about 3 weeks took months of work. But I pretty much had free reign to do as I pleased; I was working alone and had little oversight. No one was really looking over my shoulder and I felt that time wasn’t too much of an issue, especially in my pursuit of perfection.

I was feeling pleased with myself when the system was finally ready for the client to see; especially after mentoring some junior developers who were brought on to help see the project over the line.

As you can tell this story doesn’t end as nicely as I was expecting at the time. Come delivery to the client, I was fearful that we missed out some features that were present in the system which we were meant to copy. But to my surprise, that wasn’t the issue at all.

The requirements had changed, we’d spent months building essentially the wrong thing. What was specified on the scraps of paper (which I think was an old PowerPoint presentation) was no longer needed.

Of course, I hadn’t spoken to the stakeholder in those months of development, I was far too focussed on technical perfection. I wanted to build something extensible that would be a better launchpad to copy from. I didn’t care about the features we were delivering to real people.

The feedback was very passionate: “WHERE IS THE IQAMA ID ON THE FORM? HOW CAN PEOPLE APPLY WITHOUT THAT?”. Back then this was the first time I’d heard of the needed form field. There were a multitude of changes which would create a far more bespoke system that was originally anticipated.

Feeling very deflated, I started working through the list of changes, but now the CEO was not happy with me at all. They started micromanaging me and we argued about priorities and technical possibilities, and it was clear that I had let the company down.

Agile: no more pieces of stapled paper

Not being seasoned enough to understand why everything was going so wrong but taking a lot of heat, I decided it was best to look for another position at a different company. There was a 6 months lead time before my next development role, so I thought I would just weather the storm until then.

While I was sadly working through all the changes, I discovered that the client was an intermediary that oversold the systems capabilities to their own stakeholder. The client then vanished for a bit and the company parted ways with them entirely. I don’t think those changes ever got finished and the system was never used.

I was tasked with working on other things and my reputation was on the rise again. I was genuinely sad to leave when those 6 months were up.

However, the company gave me one last gift in these months before I left. We started to build a new system in a modern programming language at the time. We were moving from Classic ASP to ASP.NET Webforms. This project would remove the need to copy and paste entire systems. It would involve configuration and whitelabeling and bring in a new technical era for the company.

While unfortunately not being involved with the project, I was part of the daily stand up and the new methods. This was my first introduction to Agile software development a better way of delivering software by splitting work into manageable chunks. Then these chunks are validated to ensure that they provide value.

At the time I didn’t know that this was signalling the end of my pieces of stapled paper. Having a “full specification” upfront was not the only way of delivering software. My work on the bugs was successful because it had parallels with Kanban.

Now that I’ve had time to reflect on this part of my career, I can see why these two components of the Agile Manifesto are so important.

• Customer Collaboration
• Responding to Change

The risk of getting separated

By working in isolation, even with best intentions, it was clear that I wasn’t paying attention to my stakeholders. And there’s no way I could have known that the requirements were changing as I was coding away.

If I had spoken to the stakeholder on a weekly basis, demonstrated progress and had that regular feedback loop, then the project could have been steered in a far better direction.

Technically, we built quite a good system. The reality is that the company we worked for spent months (hundreds of man-hours!) on something that was never used primarily due to poor communication.

That is why good communication is far superior to technical expertise.