Come on kids, tidy up your room! Pick up those Lego pieces.
Whenever I tell this to my kids and come back 5 minutes later, I go crazy because the floor is still covered by socks, pencils and basically any other toy which is not a Lego.
What did I say? Tidy up your room! Why didn´t you pick up all that mess?!?
I guess right now you imagine the answer, even though you don´t have kids:
You didn't say that! You told us to just pick up the Legos!
As a father, tech lead, and developer I am always surprised and upset when after "giving an instruction" the outcome is not what I expected.
I immediately start to wonder where I failed in my communication. Most of the time it is indeed because of that.
Like with a program it could be a matter of syntax or a misunderstanding about the API, with people it could be that the message was not clear ( too specific or too generic), the context was not properly defined, the language/ vocabulary not shared, and so on.
But this is true up to a certain point.
Exactly because I am not talking to a robot, which might take what I say literally, I expect other people to understand the context and do whatever is possible to make sense out of it.
True, I gave an instruction that was too broad and generic "Tidy up", and another one that was too specific: "Pick up the Lego pieces!". My fault. But among two misleading instructions, they decided to follow the one that required less effort on their side. Those lazy cheeky brats!
Last week, in my train of thought, chain of googling and compulsive clicking on every link I see, while writing about Good Quality Code I ended up on this post of Coding Horror where he says:
I have a hard time criticizing the few developers who care enough to gold-plate their code in the first place.
and links another very interesting post that explains further the difference between two kinds of people: Big heads & Little heads (taken from an Israeli Army example from this guy).
I ended up reading about the Work-To-Rule and Italian Strike, when you basically slow down productivity, by well, simply following strictly, literally every possible rule your organization has.
All this made me think about the difference among developers and why some of them are - even without huge differences in their skill set - below average and some of them could be described as 10X developers.
I already talk about what in my opinion makes a 10x developer. But I think this also makes the distinction between PinHeads and 10Devs much clearer.
On one end you have someone whose goal is solving a problem. When they have a task or goal, and run into an obstacle, they proactively try to find solutions, they overcome the obstacle often with creativity by going around or right through it, or reframing the context, the original problem. (Way too many times I saw problems simply disappear or become easier or quicker to solve because the root cause (or the solution that was chosen to fix it) was suddenly another one.) Check the Rule of 5 Whys
On the other end, you have someone who stops at the first excuse. As soon as they find a justifiable reason to stop looking for a solution, they consider their job done:
First try, the bug is not reproducible: Ticket closed. Eventually, QA will open a new one, and some other dev will be assigned to it.
UI crashes because the backend sends wrong data? Ticked closed and a new one for backend is opened. It does not matter if maybe is our UI that sends invalid data, that causes the backend to return an error. If that is the case, the backend developer will open a new ticket asking frontend to send valid data, and hopefully, that ticket will be assigned to another developer.
The bug can be fixed with a quick workaround? Let´s commit that tiny change, without asking yourself if that could have a bigger impact on other parts of the application, or further down the line, in the backend or in the future. If it will, another bug will be reported. And not necessarily the correlation with this change immediately found.
The Task description is generic or implementation details misleading. Send back the ticket and wait for the product owner to start other long sessions of meetings and discussions about requirements instead of contacting the stakeholder/reporter with a quick slack message.
You might find this behavior lazy, unprofessional, and plain stupid, but unfortunately, there is a lot of people ( not just developers) that work and live with this attitude, which is not necessarily malicious.
Since this is the reality, being smart, broad-minded, creative, proactive, being able (having the courage and humility) to ask questions ( or ask for help) when in doubt or when stuck, can really make the difference in your career.
As I said many times, there is no magic in those mythical creatures called 10X developers, most of the times are simply quite skilled developers who take initiative and do what is desired, not what is requested ( plus a good dose of soft skills to handle it)
Disclaimer: I am not, in any way saying that some colleagues - or my kids ;-) - are stupid! Just pointing out the difference of attitude I saw among developers, over many years, in many different companies. And teaching this right attitude is one of my main goals as a father, and tech lead.
Top comments (7)
Well you can always give them a limited choice to do it.
I do that to my nieces like "you can pick up toys now and put it away" or "you can pick up it now and put it in that box" to let the kid choose.
If they are smart they will reject both but they still pick one and you hold them to it on doing it cause they had made a choice.
Most people are the same as they take ownership of the decision they make. So give it to them to take ownership. It's a sales technique that i learnt that was really helpful.
my kids are 9 and 12 so they are already in that age where you don't know they are old enough to try to outsmart you and find valid excuses, or still small enough to be kind of naive and not understand the underlying message. :-)
The advice you are giving is very valuable. There is nothing better than having people take ownership, and it is very likely they will take it if they took the decision for themself.
There are lots of techniques to manipulate people to do what you want them to do. Especially within sales. I rry to start on the reason instead, why we are doing things. If the kids do not want a room that is tidy, they will not put in a effort. So first thing is to agree on the reason. Then how to get there, instructions. Being concrete when it reduces cognitive overhead. E.g. put the Lego in that box. When all done, celebrate somehow. Positive reinforcement is not bad when you've done something you actually wamted to achieve.
agree even though, expecially with kids, but with coworkers as well, i dont like much the word manipulation nor I want to reduce everything to the simple equation precise-instruction --> expected-result.
My goal as a father and lead is having genuine conversations, shared goals, and most of all I'd really like to develop this *attitude of proactivity. *
I want you to question what I am saying, to ask questions if in doubt, take initiative if you think it's worth it, even go against what I said if it makes no sense and you think your idea is best. But not just do what i said, and stop at the first (valid) excuse.
But yes, reducing cognitive load and positive reinforcements are all part of the process.
thanx
To me whatever works and help to teach a life skill to the kid. But giving options and having them to take ownership is better. I would rather want the person to get me out of the way. Let them do the work while updating to me, what they had learnt or the result of the things they are doing.
Thanks for your thoughts!
Your kids' story reminded me of this video.
In Hungary, there used to be strikes, when the bus drivers said, they will follow all the rules when checking out a bus from the garage....
Btw, a link is missing for the article from Coding Horror.
Thanks. the Exact Instruction Challenge video it's A-M-A-Z-I-N-G. I will show it to my kids as soon as they come back from school. Btw, my son has a test on thursday where they have to basically write instructions, exactly like this, so that could really be useful :-)
thanks for pointing out markdown error, just edited.