1–10 of 186 posts
For all those of you who've done the same or planning to do the same: What are the most important skills or what's the most needed knowledge in such a position? Where can I learn it? What should I read?
- Engineering and Management are very different. When writing code, there's an obvious end goal. There is no such end goal in Management. Your job is to remove obstacles to allow other people to do their best work.
- Get used to interruptions. your job will be interruption-driven. When coding, you want as much heads-down time as possible. In Management, you will be interrupted as problems come up and people look to you for solutions. And these problems dont always have obvious solutions as they are people problems.
- You will code less. Get used to giving up the "interesting" parts of the codebase to engineers. Your role now is not to code, but to provide the right environment to allow other people to be happy and productive.
- Learn how to give feedback. Different people on your team will take your feedback in different ways. You may have to be direct with some people, and more delicate with others. You have to learn how these people react to different types of feedback and deliver news appropriately.
- Understand who on your team is a "superstar" (a person wants to work on latest code, wants to move up the corporate ladder, may only be on your team for a year), and who on your team is a rockstar (the "rock" of your team, someone who doesn't want to move up because they are perfectly happy doing what they are doing). One is not better than the other. People switch between one and the other in different stages of their lives. You have to treat them appropriately in terms of projects, feedback, expectations.
One of the books that helped me a lot was Radical Candor https://www.radicalcandor.com/
I went from a Software Engineer to an Engineering Manager about 1.5 years ago. Here are some of the things I've learned: - Engineering and Management are very different. When writing code, there's an obvious end goal. There is no such end goal in Management. Your job is to remove obstacles to allow other people to do their best work. - Get used to interruptions. your job will be interruption-driven. When coding, you…
Giving feedback seems to me especially challenging - I'll definitely read Radical Candor.
So... you’ll need to develop ways to gather daily progress reports and monitor work is progressing. When it is not progressing you have to remove the road blocks if possible while also communicating up any roadblocks that might be causing delays to keep your bosses expectations inline with the current state of the projects progress.
You will also need to start thinking about the process in which people work, and make adjustments to the current process as problems show up. I have a Wednesday meeting with my leads/senior team to sync up and address pain points, I call this meeting “What’s working Wednesday” with the main topic to specifically look at and adress what is not working. So that my team and I can adjust our way of working. This allows me to get in front of problems when there small, and have knowledge of frustration/pain points.
My goal with teams is to inspire them to make good choices, show them the right paths and help them succeed. A leader serves his team, and doesn't stand over them demanding progress reports daily. A good leader gets updates from his team daily because he talks to his team daily, but doesn't do so because he needs status reports. Managers need status reports and many times use them to justify their job, or to throw Johnny under the bus because he is behind. A leader knows Johnny is behind because he talks to him nearly daily and has been helping him get back on track already. If Johnny can't get back on track the leader is looking for a way to make Johnny successful even if that means he moves him off the team or to another role. The leader turns to his superiors and takes responsibility for the team, but never hides behind Jonny for being behind.
Another key, always vent up, but communicate in all directions. What I mean by this, is always find a mentor at your same level or higher that will listen to you, who will let you vent some frustration and help you if you need guidance. Sometimes this isn't someone in the company, that's fine. Never vent to your team or other teams. Communication however, should never stop and be happening at all levels.
Last point I guess. Hierarchy isn't evil, it gives people boundaries so they know who to go to for what and when/why. Flat organizations sound awesome, but are sometimes a nightmare to be in because there is too little structure to give good guidance to people. Flat organizations that are successful are so because people are given boundaries and generally have good documentation or rules/values they can turn to and use as a guide. You are not a good leader/manager by giving total free rein, having boundaries is critical to success for everyone (same goes for parenting when you have kids, give them opportunities to take chances, make mistakes but have boundaries in place).
- Managing Humans by Michael Lopp
- The Managers Path by Camille Fournier
- Radical Candor by Kim Scott
I think the netflix culture deck is also helpful: https://igormroz.com/documents/netflix_culture.pdf
And if you want to peak at how other managers manage check this out: https://hackernoon.com/12-manager-readmes-from-silicon-valle...
Or check out this podcast on the topic: https://anchor.fm/soapbox/episodes/6-Melissa-and-Johnathan-N...
IMO, developers get annoyed at having to report to someone who doesn't understand at least the basics of what they're working on our who can't provide recommendations in a pinch.
The respect you'll have with your developers makes managing them infinitely easier in my experience.
1- The individual would grab the most annoying task no one else wants to work on and would close it while staying positive
2- The individual is often used as the go-to person when a decision has to be made, or critical information is missing in a project
3- The individual has a great relationship with most of the people around (known as a friendly and respectful person)
4- The individual is wiling to help others behind the scene and doesn't look for any gratification other than making sure people learned something while being helped
5- The individual has made multiple decisions that appear to be great decision after all (probably the most important point).
If you fall into all this categories, you'll be just fine. It is a constant learning process as opposed to being an engineer. Why? because the process changes constantly, there's actually no process at all. If you learn a pattern, a language or a framework once, you can re-apply the same process for the new upcoming stuff. As a manager, every day is a new day. If you're a shark who produces a lot of output and burns a lot of relationships along the way, chances are, you'll most likely get promoted, but you'll fall into the large pool of bad managers. There are more bad managers than good managers out there. If you don't have the 5 qualities mentioned above, work on that prior to switching to management. That's my best advice.
* D E L E G A T E => Your job is to keep your people productive and effective. Doing that starts with yourself - do the things only YOU can do and delegate the rest to the people who are better served to handle that.
* Check out the Manager Tools podcast and focus on the basics (https://www.manager-tools.com/manager-tools-basics)
* The 2 books I got solid, actionable advice from were "The First 90 Days" [1] and "The 27 Challenges Managers Face" [2]
[1] https://www.amazon.com/First-90-Days-Strategies-Expanded/dp/...
[2] https://www.amazon.com/Challenges-Managers-Face-Step-Step/dp...
Focus first and foremost on helping coach and improve the performance/productivity of the people on your team, each and every day.
If you're a good engineer/employee in general, this will be very hard for you. Mostly because, it will make you feel much less productive and as if you aren't contributing. You won't be able to commit as much code, perform as many code reviews, etc. You will at times worry that you are falling behind, or at times even as if your team members are outperforming you.
Don't worry about your personal productivity, just worry about the improved productivity of those on your team. No one will ever fault you as a manager if you are known for consistently making the people below you better, regardless of where they currently sit with respect to position, skillset, etc. And an improve team will lead to an improved product, even if you aren't the one committing the most code or new features to that product.