In these days I had a nice chat with Önder Göğebakan to exchange some views about team leading: one of the points I loved to face was how to deal with arrogant coders that don’t want to consider the indications received from their technical lead.
Pulling responsabilites is not that bad
It makes no difference the reason why the developers is going against your opinion/advice/dictation: it may be due to inexperience or attitude, and this is not that bad.
A developer which pulls responsabilities shows a good attitude, as it demonstrates that he wants to take a decision based on different variables evaluated differently than you: passive coders1 are just a bad smell within your organization, because they won’t ever be as productive as you might need; don’t get me wrong on this: passive developers are a valuable asset, as you can’t rely on a team of cocks, but you shouldn’t hire too many passives, since, in a team of 4~6 people there will be room for 1, maybe 2, washermen.
Push systems are just a bad idea: if you throw duties and responsabilities to your developers they won’t feel comfortable with them and will suddenly fear the assigned tasks; make a developer pull his responsabilities and you will be able to work in a strongy energized, motivated, self aware and fast growing team2.
If you will ever be in troubles when a proactive developer go against your decision, I want to share with you a few thoughts on that.
Use exampl…your experience
Being a CTO, team leader, technical fellow or whatever, you gained so much experience from your previous “developer’s years” that you have an unvaluable knowledge about problem solving, and when I say unvaluable I mean that there’s no inexperienced brain that could overcome a seasoned veteran.
Think about the way you solved that technical problem earlier in your
career and start adding examples to your cause: don’t pretend to
think that this new problem “it’s just the same I saw in some company
back in 2001”, because the developer will think that your are
just scratching the surface of the issue and will look at you
with no trust.
When Michael Jordan got back into the NBA for the second time, with the partially self-owned team of the Washington Wizards, he was 38, and wasn’t able to provide the physical strength, speed and responsiveness that he had back on his 20s.
Although all of this, the great thing that Mike did was to take advantage of his experience to overcome youger players and rough defenders: without a fully-supporting body, he was able to perform great games, with a 51-points legendary performance against the Charlotte Hornets, just to mention one episode.
At 38.
Don’t think your technical knowledge will be as exhaustive as during your full-development period, but take advantage of the situations occurred during those valuable years.
Approach the problem from different points of view
Sheldon Cooper has a huge problem in his life: he’s not open to look at the situations he faces from perspectives different from his own one.
This makes impossible, for him, to solve decisional problems taking different looks, from different point of views: one aspect of your job is to provide different solutions to the same problem instead.
Solutions may be incomplete, or may be not suitable for the developer against you, but will help you in gaining trust when explaining your points: someone stucked to his view may be considered stubborn and not qualificated, but if you are able to provide different pros and cons to different solutions you will get respect from the person at the other side of the argument, as you will be recognized not as a firm believer, but as a thinker.
Make spikes
It may sound inefficient, but spikes are a good way to bring your result home: you are not meant to directly write a spike for a use case but you should encourage the counterpart to start writing small and rough pieces of code to test if some of the solutions he thiks are gonna work seem to be working fine.
This makes the developer feel that he’s gaining trust from you, as he is allowed to actually spend some billable time on his implementation, but as some problem comes out ask him how to solve it: a good developer may immediately find that he was wrong about it, so your problem is solved; if he keeps trying to follow this deadly way – maybe for pride – just move at the subsequent step, which means making the developer recognise he needs help.
Bear in mind that whenever you decide to make a spike, something practical actually happens, and it could turn out that the implementation you were criticizing may accomplish its duty: since no one is perfect prepare your words to congratulate with the developer and thank him for the good approach, without feeling embarassed.
Consolidate doubts
With a socratic approach, as you see that he is developing some spikes but comes to unacceptable endpoints, start smashing his beliefs pointing out the flaws his design has, the possible problems that you are going to face and the limitations that this piece of code will bring to his direct components – just to mention a few possible type of problems.
I strongly recommend you to read The Republic, by Plato, to understand how the socratic approach works in practice: it’s a really good practice to rely on ancient wisdom to solve inter-people issues, as this kind of knowledge is transversal to any kind of context.
Give trust, feed the monster and save him before death
May 8, 1970: Willis Reed, captain and leader of the New York Knickerbockers is injured, and the Knicks need to defeat the Los Angeles Lakers in game 7 (last game of a 3-3 tied series) to become NBA champions.
Willis starts the game, sinks down the first two points for New York with a perimetral shot and, well, then he stops there.
Your developer is Reed: he’s under pressure, feels he can’t solve the situation but dramatically tries not to drown; there comes Walt.
Walt Frazier is a tiny little point guard, a decent scorer: he’s facing LA’s Jerry West, one of the legends of the NBA, named Mr. Clutch due to his ability to stay focused and sink shots in high-pressure conditions.
Walt does not care: inspired by his captain, he puts together an awesome performance, scoring 36 points, serving 19 assists and stealing several balls from West’s hands.
Now it’s time – for you – to play as Walt ‘Clyde’ Frazier: as the developer is drowning down you need to come there, give him the advices to fix his implementation and to get out of that situation, pair with him and make him feel that you could also be in that situation, it’s not such a big problem: doing this he will firmly listen to you, as you are leading him out of troubles, the best way to gain respect from others.
Gain trust
The key to lead a team is gain trust from its components: it is rarely acceptable that a team leader could lead his team with a cocky behaviour, so you are going to fail if your only aim is to do people management, and not team leading.
Letting people pull responsabilities, giving them trust, analyzing with the team the problems which may occur after a decision (an implementation, or the change of a process), involving everyone in your job.
As I like to state:
Great leaders let other leaders emerge.
Be humble and step back
What if you were wrong? It may happen, and it’s perfectly acceptable: don’t be rude when supporting your ideas, because as it turns out that you were wrong, this may harm your position.
If you sell yourself as a humble guy, you will get the trust of your team, because they will recognize you as a wise guide, not a tyrant.