Sharing an article written by the good folks at officevibe.com about leadership styles. The list could be endless, depending on who you ask and which book you read but I feel this captures them well enough for me to share. It’s a good reminder for those you might have had read too much books in the past and forgotten.
Leadership styles apply not just for work but even in the family, friends and politics. There are always debates on what works and doesn’t work which makes sense since every situation could be different. This does represent my own “default” though. And at the very least, knowing them will make us understand each other more and as they say, “if you only have a hammer everything is a nail”.
This infographic was crafted with love by Officevibe, the software that shows you how to be a good leader through employee feedback.
Engineering Leadership (or management – some engineers are not fans of the term “manager”) is not easy as some people think. Leadership is hard enough, the complexity of people then add to that the complexity of engineers. There’s not a lot of books on the specific subject so it’s not surprisingly that I still hear top executives saying that one just needs be technically proficient/architect, sure – architect of teams/people maybe but not just of systems/code. That’s where the challenges of engineering leadership comes in, one is expected to be both good at systems/engineering and people. Those two could mean different worlds.
Long topic but I wanted to share what I hope to follow and achieve. These are taken mostly from Google’s Proxy Oxygen (Google’s Quest for a Better Boss), books, articles I have read on the subject (you can catch some at my GoodReads account) and experience from peers, friends and my own.
These are “big” topics on their own, (obviously thousands of books have been written on leadership), my goal is to simply to share in case it helps and for others to remind me should I forget to walk the talk.
Also, though useful in most cases, it could vary depending on what stage your company/team is in. If you are just starting up, you need more coding + pitch/sales/marketing power more than maybe engineering leadership.
There is no timeline to get these right (if even possible at all), it’s a lifelong process and better have a target than nothing at all.
1. Be a good coach
Provide specific, constructive feedback, balancing the negative and the positive.
Have regular one-on-ones, presenting solutions to problems tailored to your employees’ specific strengths.
Learn more about coaching and apply (and be more organized, templates etc)
2. Empower your team and don’t micromanage
Balance giving freedom to your employees, while still being available for advice. Make “stretch” assignments to help the team tackle big problems.
Give them tools to enable them to do their best
Demand the very best, help if possible, otherwise find other options, if all is exhausted cut losses
Trust them to do their best
Emphasize results, not time spent
Delegate that which is not your strength
3. Express interest in team members’ success and personal well-being
Get to know your employees as people, with lives outside of work.
Make new members of your team feel welcome and help ease their transition
Treat them well
Know what makes them tick (money, power, status, popularity, greater good)
Do the hard work of knowing but also ask what motivates them
4. Don’t be a sissy: Be productive and results-oriented
Focus on what employees want the team to achieve and how they can help achieve it.
Help the team prioritize work and use seniority to remove roadblocks.
Shield the team from distraction
Manage external expectations
5. Be a good communicator and listen to your team
Communication is two-way: you both listen and share information.
Understanding is the goal, communication is just a tool
Hold all-hands meetings and be straightforward about the messages and goals of the team. Help the team connect the dots.
Encourage open dialogue and listen to the issues and concerns of your employees.
6. Help your employees with career development
Mentor when you can, refer to someone if outside your expertise
Training time on regular work week hours (internal + external expertise)
7. Have a clear vision and strategy for the team
Even in the midst of turmoil, keep the team focused on goals and strategy.
Involve the team in setting and evolving the team’s vision and making progress toward it.
Team vision, Core values
Where does each one fit in the team (roles)
To be the best, know the best (who are our competitors)
When saying no to roadmap/tasks, support it by giving costs
8. Have key technical skills so you can help advise the team
Roll up your sleeves and conduct work side by side with the team, when needed.
Understand the specific challenges of the work.
Learn their code base – invest time on this
Good architecture – “With good architecture, debugging is a breeze because bugs will be where they should be.” – David May
Just, fair, transparent
Do not commit without consulting them
Give people proper credit
Confront problems, not people
10. Advocate Quality
Test, Test, Test
Cannot commit if builds are failing
5 whys – incident report always
Do not build something you cannot measure
Have a Devil’s advocate, 10th person on architecture decisions
Advocate design thinking – emphatize, define, ideate, prototype, test
Safe environment to learn from instead of fear failures and move on