Download to read offline
Uploaded byVeselin Nikolov
Leadership for Developers, WordCamp Norway
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.
More Related Content
Similar to Leadership for Developers, WordCamp Norway
![[make_a_copy]_Complete_Manager_Sprint_Project_July_2023_.pptx](https://cdn.slidesharecdn.com/ss_thumbnails/makeacopycompletemanagersprintprojectjuly2023-230818234239-3cbfd28b-thumbnail.jpg?width=640&height=640&fit=bounds)
Leadership for Developers, WordCamp Norway
- 2. • Veselin Nikolov Developersince 1998 Automattic since 2011 Store Developers Lead
- 3.
- 4.
- 5.
- 8. Shock • 2-3x morecommunication • 2-3x more interruptions • No time to code
- 9. More • Pressure • Responsibilities •Deadlines • People don’t do what you expect from them
- 10.
- 11. WHY! • Only geekscan manage geeks • Technical skills are required • Career
- 12. Cloning More like youare appreciated
- 13. Understanding your position inthe organisation helps
- 14. A team leaddoes: • Communication & acquiring information • Sharing information
- 15. The Middle Management •Cross-team communication • Planning
- 16. Executive Management The BigBoss. Communicates with the outside world.
- 17. „Management is thecare and feeding of the invisible. You’re doing your best when it appears the least is happening.“ -- Managing Humans, Michael Lopp
- 18. Communication is Oxygen myexperience…
- 19. 1998 200 000 studentscrying
- 20. Screaming and losing yourtemper rarely works.
- 21. 2000 Something is wrongwith your TPS reports.
- 22. Micromanagement doesn’t work either Also,leads are different.
- 24. The rules Ifollow • Show sincere appreciation • Don’t criticize, complain or condemn
- 25. The rules Ifollow • Smile • Listen
- 26. The Job • Peter’swife 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
- 27. We ask peopleto complete tasks
- 28. Good ways togive a task • Ask questions. Give the person chance to have the idea and take ownership of it • Ask for opinions, listen
- 29. Feedback • No smilingin 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
- 32. To manage humans, youneed to be one.
- 33. And don’t stopcoding Or you’re doomed
- 34.
- 35. • Image credits: •http://blog.cwonder.com/2013/06/11/puppy-love-2/ • http://commons.wikimedia.org/wiki/File:Mexican_Wolf_065.jpg • http://wnpr.org/post/retiring-research-chimps-and-our-unique-human-evolution • http://www.ibtimes.com/humans-got-punier-energy-hungry-brains-became-stronger-new-study-suggests- 1591186
Editor's Notes
- #3 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.
- #4 Like Aragorn. A born leader, with king’s blood.
- #5 I’m nothing like that. I’m a geek and introvert.
- #9 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.
- #10 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.
- #11 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.
- #12 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.
- #13 And the nicest of all reasons is that the boss likes you and wants you to somehow inspire your team to be like you.
- #15 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.
- #16 Planning and making important decisions fall onto the upper management.
- #19 So, your job is communication. But communication means so many things.
- #20 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.
- #22 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.
- #24 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.
- #25 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.
- #26 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’.
- #27 On a daily basis, it is more like that.
- #28 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.
- #29 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.
- #31 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.
- #32 This book helped me a lot to identify communication failures. According to it, when people respond poorly, they felt either fear or disrespect.
- #34 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.