Veselin Nikolov has been a developer since 1998 and has worked at Automattic since 2011 where he currently leads the Store Developers team. As a technical leader, he faces more communication, interruptions, pressure, responsibilities and dealing with people not doing what is expected compared to his previous role as an individual contributor. Effective management of other technical people requires maintaining technical skills, clear communication of tasks and responsibilities within the team, and understanding different roles within the organization. Good communication, listening, appreciation and avoiding criticism or micromanagement are principles the author follows as a technical manager.
17. „Management is the care and
feeding of the invisible.
You’re doing your best when
it appears the least is
happening.“
-- Managing Humans, Michael
Lopp
26. The Job
• Peter’s wife is pregnant
• Jane is fixing endless amount of bugs
• Joe is driving a fast car, mostly between the garage
and home
• Mike is feeding rumours
• Our boss gives us new projects
• Ivan wants to go to a conference
28. Good ways to give a task
• Ask questions. Give the person chance to have
the idea and take ownership of it
• Ask for opinions, listen
29. Feedback
• No smiling in the world with help you when
reviewing bad code.
• Sometimes we just say the wrong thing
30. Failures in communication
• Defence reactions, attacks, verbal aggression,
body language, change of subject, repetitive no
no no, lengthy posts, silence
• Harder when the person is across the ocean, 10
time zones away
Howdy. My name is Veselin. I’m a developer, with 15 plus years of experience. I’ve been working for Automattic since 2011, and had a few lead positions - Store Team technical lead and Store Developers team lead. I believed for a very long time that management is a knack, talent, not a skill, and to lead you need to be born with empathy, charisma, certain body type, voice, beard etc.
Like Aragorn. A born leader, with king’s blood.
I’m nothing like that. I’m a geek and introvert.
From the first week of the promotion everything changes. We want to keep doing what we were doing, but we can’t, because we have so much more communication, administrative work to do, and so many people ask us questions, that the coding time quickly goes down to 0.
This is not the only change. Developers rarely feel stressed about deadlines. Managers do. They also don’t seem to need reminders about what the current goal or project is.
A colleague of mine, who used to lead, started a public discussion about why we reward the best developers with leadership positions, in which they don’t feel very comfortable.
There are many good answers. I like Michael Lopp’s answer ‘Only geeks can manage geeks’. But also, to ship a highly technical project, you need highly technical leads.
And the nicest of all reasons is that the boss likes you and wants you to somehow inspire your team to be like you.
You need to know stuff, and you need to make sure everybody knows stuff.
You need to know everything that happens with your team. Any form of unhappiness, boredom. You need to know what happens with the projects, detect problems, blockers. And you need to know that everybody is aware what needs to be done.
Planning and making important decisions fall onto the upper management.
So, your job is communication. But communication means so many things.
This is the photo of the great leader Kim, who made 200 000 kids cry. In 1998, I worked for Mrs Nikolova, who had very similar leadership skills. She could make 200 000 old ladies scream at her. She was very good with that.
It didn’t work very well. Lucky for her, I found that the loudest old lady is actually cheating and we let her go. Soon, the decibels decreased, and the revenue increased.
In 2000, I started working for a team of ~20, and my boss had this habit to stop by and ask me what’s happening, about 2-3 times a day.
So, I tried to find a theory that works, not role models that don’t, and here is a book which changed the way I see the world. If you haven’t read it yet, you should.
It’s very easy to blame people for their failures, but failures are the worst possible moment to provide negative feedback. It is far better to pay attention, notice the good things your colleagues do, and express your appreciation. Book says that we shouldn’t praise too much, but in my experience, the feedback is so needed that there is no amount of positive feedback that’s too much.
People are going to tell you almost everything you need to know if you give them the chance to speak. Communication needs to be two-directional. It’s not about you giving orders and they saying ‘yessir’.
On a daily basis, it is more like that.
Asking people to do something is usually ok, but can go terribly wrong. They might not want to. We might not ask in the right way.
A team is always stronger than the strongest team member. If you have somebody the chance to think about the solution instead of presenting your own, they might actually think of something better than what you wanted. Or at least, they’ll feel like their opinion is valuable.
People respond differently, but there is always a reason. If you notice early enough that the conversation went wrong, you can stop, think, and try to make it right.
This book helped me a lot to identify communication failures. According to it, when people respond poorly, they felt either fear or disrespect.
My solution to the coding problem is very simple. I became proactive in communication. If you spend 5-10 min talking to a person, it’s very likely that they’ll ask you whatever they had in mind and not interrupt you 3h later, or tomorrow.