I used to be a nice guy.In the early days of my career I did a lot of training, both business and technically-focused. One of the most regular bits of feedback I got from course attendees was that I showed boundless patience with people who really struggle with the material.
I appreciated those comments and it is something I strive for every day.
Lately, and by lately I mean the last couple of years:
- My temper has gotten shorter and shorter.
- My overall frustration levels have been increasing steadily (like my weight)
- I have been sleeping less and less
- I have gone on fewer holidays
So what happened?
Of course, it isn't all bad, and I have had many successes over the years. This article explores my journey, looking at:
- Some of the things that cause projects to need a hero
- What you can do to prevent it
- Why you should focus all your energy on not becoming the hero
A teenie bit of context might be useful here:I play a leading role in the bespoke software development area of a large South African IT company. Which means we are often involved in projects where there isn't a pre-baked solution that can be purchased off the shelf.
- It took the customer ages to get through the business case and get budget allocated
- The procurement cycle took ages
- And then more time was spent getting the project team assembled and ready to rock and roll
- And of course, requirements are never defined or well thought through at the start.
But despite all of that, some big-shot exec has already made a delivery date commitment to the board of directors in order to get the money for the project.
Understanding the different role-players in projects
- Heros - People who REALLY know their stuff. Passionate about delivering the project - 15%
- Divas - Passionate technologists who think they are too good to be on the project - 5%
- Talkers - People who add little value except for the fact that they're old or seem to talk a lot in meetings - 10%
- Workers - Worker bees who do one thing well and put in a solid 6-8 hours of work - 40%
- Strugglers - People who want to work. And think they do, but they never seem to deliver anything - 20%
- Dead wood. People who are literally just on the project to fill a seat - 10%
It's probably obvious that we've killed off the Divas, the Talkers, the Strugglers and the Dead Wood, but what is also interesting is that:
Building your packThe best analogy that I can come up with for a project team is a pack of sled dogs. I'm not sure if it's just me, but I loved watching the Discovery series on the Iditarod, the epic dog-sled race in Alaska. In typical Discovery channel fashion they constantly tried to manufacture intrigue and surprising plot twists. But what I loved about the show was not so much the intrigue, but rather learning more about how these racers assembled their packs of dogs prior to the race and how they cared for them during the race.
- The whole pack slows down until the slow dog recovers
- You remove the slow dog from the pack
Depending on the project, there are two possible outcomes:
- Small projects become a one-man show with other project team members feeling useless and just sitting on the side-lines
- Large projects fail outright, because it is impossible for one person to carry a 10 or 20 person project.
Accepting the Kruger Dunning Effect
As could be expected, he was quickly identified and arrested. When the cops entered his house and placed him under arrest, the first words out of his mouth was: "But I wore the juice"
"BUT I WORE THE JUICE!?"You see, McArthur isn't very smart. He had heard about the fact that you could use lemon juice to write in a type of "invisible ink" which is undetectable to the naked eye. He then reasoned that if he rubs lemon juice over his face, people in the bank, and the security cameras would be unable to see his face. Master plan!
The Kruger-Dunning Effect describes this phenomenon where someone with a low level of competence in a subject, let's say Programming, also lacks the knowledge to accurately assess their own competence. As a result, they greatly overestimate their own capability.
You can summarise this as: A little knowledge is a dangerous thing.
The graph below depicts this phenomenon by showing how someone, once they start to get experience in a subject, slowly begins to realise how little they really know.
This is what happens to a Struggling junior developer if left to his/her own devices. They literally don't know that they aren't adding any value to the project. They actually think they are experts in their field.
So let me give a practical example of this effect from my day to day life: On a recent project, we had a junior developer who was very clearly VERY Afrikaans. For some reason, however, he was under the impression that his English grammar was impeccable and that it was his duty to correct people at every opportunity. It was so bad that I once had to privately address the issue with him, when he "corrected" the client's product owner in a meeting.
Here's one of the classics he added into JIRA as a defect:
Yes, perhaps a whimsical example, but it applies to most aspects of young developers who fall into the "Struggler" category. It's not just that they lack the required competence, they also lack the knowledge to realise their lack of competence.
Your goal as a senior developer should not be to criticise their lack of competence, but rather guide them along the path, helping them realise what they don't know and then encourage them to learn it. We'll touch on some approaches just now.
The Curse of KnowledgeBut first I want to address another cognitive bias that makes it difficult for experienced developers to teach younger ones. It's called, the "Expert Paradox", or sometimes the "Curse of Knowledge"
As a senior technologist, many things may seem easy or self-evident to you. This is function of your competence as well as years of experience. This knowledge and experience makes it difficult for you to actually empathise with the position of the inexperienced person. Your knowledge actually becomes an impediment to teaching.
I generally like to use a puzzle analogy: Think of your whole IT carreer as building a puzzle. It's the puzzle of knowledge. Each piece of the puzzle is a new bit of isolated knowledge - It only becomes valuable when you can look at it in context. As an experienced practitioner, your puzzle is already well established, so when you find a new piece, you have a much better overall picture and you can more easily understand where this fits in. Even if you find a difficult piece of blue sky or ocean water, you can more easily find where it belongs because you can compare it with the other patterns you've already constructed.
To a young and inexperienced person, they have barely begun assembling their puzzle. Each piece is a brand new experience and is often very difficult to see in context.
Here's one way that absolutely does not work: You pick a small, apparently easy bit of work and give it to the new guy to implement. And then you wait. This fails for a number of reasons:
- You wait too long
- By the time you receive something back the learning opportunity is lost
- You probably implemented it yourself, so the new person loses conffidence
I learnt a better way from one of my colleagues, William Gadney. I'm not sure if it is his own method or whether he read about it somewhere, but the process is both deceptively simple and yet deceptively difficult to execute.
The idea is simple:
- First, you find a piece of functionality that you will need to implement at various points in your project. A good example would be if you had to build a number of different REST services.
- Stage 1: When building the first one, the inexperienced developer sits next to you. While coding you "Think out loud", explaining what you're doing as you proceed.
- If it seems that the new person understands, you move on to stage 2, else you repeat stage 1
- Stage 2: At this point you switch seats. The inexperienced developer does the coding, but the mentor is right there, guiding, correcting and helping the whole time.
- If the learner gets the hang of things, you move onto stage 3, else you can repeat stage 2, or even go back to stage 1.
- Stage 3: At this point, the inexperienced developer goes away and writes the code by themselves. Followed by a detailed code review.
- If all went well, the rookie has become a journeyman in this particular skill, and you can pick the next one.
Help the team see the bigger picture
The next bit of advice I use to help inexperienced developers escape the Kruger-Dunning trap is by constantly assisting them with seeing the bigger picture. Effectively, I overshare information about the project so that they are always 100% aware that there is more to the project than the bit they are involved with.
This has two consequences:
- They are frequently reminded that there is stuff they don't know, but
- They have full access to learn that stuff - It isn't hidden from them
My strategy includes the following tactics:
Tip 1: Err on the side of a mono-repo
A multi-repo scenario might have many benefits, but it has one critical flaw: It entrenches a fragmented view of the solution. Even the most astute learner will struggle to fully understand how a solution fits together if he doesn't even know that he is looking at a partial picture.
Tip 2: Get the documentation into the repo
Tip 3: Make the architecture visible
- Add a GETTING STARTED section in the docs. Include reference links and introductory notes for each of the technologies used on the project.
- Do VERY FREQUENT code reviews. Not just at the end of a piece of work, but while they are busy.
- Establish a formal avenue for knowledge sharing. In our company we call it Lunch Time Learning - Every fortnight we have a team learning session on a Wednesday during lunch.
- Introduce project team sharing sessions. We do it after retro each sprint, where one team member explains a piece of the project to others in detail - A level of detail that doesn't make sense when the product owner is in the review session
Also, it is important to be aware of the benefits that await you. So let me help by summarising the medium term and long term benefits.
In the medium term you will create a situation where you DON'T ALWAYS HAVE TO BE THERE.
- You can afford to take a week off and go hike in the mountains where there is no cellphone signal.
- You don't have to be online with each deployment
- You don't have to prepare fully for each sprint-review
But the long term benefits are the most rewarding, and as someone who's been in this business for many years, I've now experienced it a few times. It's when one of the junior developers you had under your wing becomes a master in their own right.
It might take years, but the day will come when you can hand over an entire project to someone and know ABSOLUTELY that it will be a success and that you don't have to get involved at all.
That's the greatest feeling in our business.
And of course, if you have aspirations to begin that Tech Start-up you've always dreamt of, you are finally ready to get it started as well, because you now have people you can trust to get the job done.