Developing Developers

When managers consider training for software developers, they usually use the wrong entry point. Typically these trainings are about technologies, sometimes about methodologies. But both approaches are toothless for several reasons:

• First of all – the need for training in a technology is usually a red flag. It doesn’t mean, that technology trainings are useless altogether, but normally a good software developer should be able to train him/herself most of the time in the relevant technology.
• Trainings in methodologies are more effective, but most of the time the new learned methodology isn’t set to use after the training.
• There are several other skills that are more important for success and are usually lacking.

And point three is what this article is about.

Reading Skills

You might think this is too basic, but let me assure you: It’s not.
Reading and comprehending a text is often an issue, especially when you are dealing with complex technical requirements specifications. People today are not used to reading complex long texts and understanding every sentence in the text. They usually read short texts on social media, and if it’s a long article, they only scan through it. This habit can lead to massive problems, when working with software requirements. So creating a habit of reading carefully is important. But not only that. Also understanding and interpreting difficult subjects is a challenge. Taking the time to really think about a single sentence, is not something that people are used to do.
The problem with training here is not that you need to train the ability to do that, because that ability is usually there. It is that you need to train the habit of actually doing it.

Writing Skills

When comprehending an already written text is difficult, then writing a comprehensive text is even more of a challenge. There are several rules on what makes texts comprehensive: short sentences, consistency, clarity, good structure, nice layout, etc. For my employees, I’ve created a full catalogue with examples of good and bad writing style. Then I make 1:1 writing trainings with software developers and requirements engineers where we do some kind of “pair writing”. I give immediate feedback on every sentence and I’m also usually referring to the catalogue of writing rules as a guidance during the session.

Responsibility

As Christopher Avery noted in The Responsibility Process, there are numerous ways to react in a difficult situation or a situation you’d like to improve. You can:

• Deny or ignore the situation
• Blame others
• Attempt to justify
• Sense shame
• Feel obligated to resolve it
• OR you can be responsible and empowered

This final option – being responsible and empowered – is a higher state of responsible. If you’re feeling empowered instead of obligated, then you’re acting from a place of responsibility. Although most people are not in this state often, it is something to strive for. I’ve found the process to be an effective guide when training people to take responsibility. Every time somebody doesn’t take responsibility, I discuss the situation and ask in which level (s)he is stuck. This typically brings awareness to the discussion. Afterwards I discuss with him/her, what (s)he can do about the situation from a position of responsibility.

Time management

Another trait that should be addressed through training and coaching is time management. Educated software developers usually come either from a specialized school with a fixed schedule, or a university, where most of the scheduling is up to themselves. Either somebody else told you what to do all the time (school), or you never had really any fixed deadlines (just skip the course and make it next semester). Both environments don’t prepare you well for working in a multi-project business.
Organizing oneself, avoiding distractions, keeping focus and being reliable is an essential part of the work environment that needs to be trained. See my blog article about managing many things at once about this.

Deep thinking

Even though software development is all about thinking, people are easily seduced into quick-fixing things. Just adding an if-statement here or there is easier than really getting to the bottom of things. Sometimes it’s pure laziness, but more often it’s because of the fear of being inefficient. In my experience though, getting to the bottom of things only enables you to become efficient.
So it’s typically more an emotional barrier to overcome. Having the courage to take your time will result in less time needed. Changing the people’s behavior is not easy, though. Sometimes I literally had to force people to take their time (which is kind of absurd when you think about it: “I urge you to work slower, my dear colleague”).

Creative thinking

Software development is after all a creative discipline. You have to come up with new solutions to new problems. But how do you do that? What people don’t know is, that creativity can actually be trained. Sure, there are those creativity techniques, but that’s not what I mean. It’s more about the settings and the attitude:

• Does a person really look for different alternatives? I have the rule that you should find at least 10 alternative solutions for a difficult problem, before you decide.
• Does the person take the time to think about a problem in a more “lose” way? Unstructured, without pushing, the opposite of deep thinking.
• Does the person take breaks or makes different things in between (taking walks, finishing other tasks in the meantime)? While context switching and procrastination are productivity killers, they are actually creativity boosters.
• Does the person ask the right questions about the problem? Taking different viewpoints or distilling the problem to its essence is a very important creativity skill.

Big picture thinking

Unfortunately regular employees often lack big picture thinking. From childhood on they have been trained to do what they are told. Being able to judge a situation objectively from a higher viewpoint, seeing all the relationships and interferences, is a real asset. As a manager and coach I always encourage people to reflect on the purpose of certain rules and challenge them to see the big picture. Recently I even forbid somebody to execute any of my orders if he doesn’t understand its purpose.

Appreciation of beauty

A good software has to be beautiful. If it’s not, people will not understand it. Beauty is not some high level abstract esoteric concept. It is an essential requirement for good software. And I have found out, that even technical people have indeed a sense of beauty. As a training method I use referencing: “Compare the beauty of your solution to the beauty of this reference solution. Is it equally beautiful? No? Then come up with a better solution.”

Search for excellence

Exceptional achievement does not come accidentally. It has to be intentional. If your people do not actively try to be excellent and perform excellent work, then excellent work will not happen. What I have found out is that raising the standards helps. But also challenging people’s owns standards is important. The ultimate goal is that their standards are higher than my own (which then forces me to raise my own standards).

Ability to train oneself

In today’s education system, everything is presented on a “silver platter”. Individuals often feel they are not empowered to train themselves or learn skills on their own. However, since the technology is always changing, it’s necessary for developers to learn new skills on their own. It’s the skill of acquiring new skills.
As a starting point, I usually let the coachees create a mind map of skills to acquire. Then we prioritize together and think of ways to learn and train the selected skills. Usually it is a combination of role plays (for soft skills), exercises, explaining things to others, reading books and consulting experts.

Coordination with others

Everybody is a team player today, right? Well… not so much. Especially in the developer community I have found out that the communication with others is something that is avoided often (who would have thought?). So training people to actually talk to others (and not write e-mails), negotiate commitments with teammates and give feedback is essential. I use role plays as a training method and behavior guidance rules for day to day business (like: pick up the phone first, then write an e-mail).

Final thoughts

It is quite a list, I confess. I have found it to be really effective, though, to do training in these areas. More than technical training. Although technical training should not be omitted fully, the above mentioned skills will give you more leverage when leading your team.