14 Oct 2020
tl;dr: the three things I expect from an engineering manager are:
- Support the members of your team and help them grow.
- Follow along the deliveries, setting quality standards, making sure the team has the support they need and upper management the feedback they need.
- Keep a constant practice of creating, improving or eliminating team or company processes.
Every organization has its own way of working and your mileage may vary. I’ve collected a few points that I believe that are overall expectations.
Andy Grove on his book High Output Management defined a manager output as the sum of their team output and the teams under their influence output. He also recommends selecting activities producing high leverage: an activity he did as a CEO was an introductory talk to new employees, in which he explained the history, the values and the objectives for Intel. If he does this very well, this can generate great impact on every new employee.
A good example of a high leverage is partnering with other leads: being able to understand where the business is going and helping building a technical roadmap to facilitate getting there. Another high leverage is to guide each member of your team to acquire new skills so they can increase their scope and increase their impact on the organization.
People
Your team’s output is really dependent on your team members, so an expectation for engineering managers is to support the members of your team and help them grow.
A good way to think about hiring and growing your team members is to think that they can replace you. You can’t actually do that unless you know everyone really well. What are their strenghts and weaknesses? What are their goals and what motivates them? Which level they’re operating? What might need them to go to the next one?
1:1s play a big role here: it is your time to learn more about each person. It is a great time to establishes trust and build rapport.
Another crucial factor on people is to set expectations: setting a clear expectation on what you expect from each person creates a more concrete notion on what they should and shouldn’t do and what level they should perform: recognizing when someone performed really well and giving constructive feedback when they haven’t reached your expectations. Feedback is a hard subject, but if you can back your feedbacks with examples, it will be much more clear on what you’re recognizing or you’re giving a constructive feedback: a good practice is to give continuous (a practice suggested by Camille Fournier on her book The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Changefeedback: on every 1:1 try to bring an example-backed feedback.
If you find yourself giving constructive feedback but you’re not seeing improvements, make it clear as early as possible. Dealing with underperformance isn’t an easy task, and sometimes we hope that with guidance they will improve, but making it clear that it isn’t working is part of your job and perhaps it is time to set more prescriptive actions and a timeline for improvement: a tool that can help is Personal Improvement Plan in which you set a clear expectations, actions that you think will help them you and an expected timeline.
A hard part of this job is that if someone isn’t performing even after this, you have to let them go. There is also behavior: if someone had an unacceptable behavior, it is part of your job to take action. Dealing with underperformance/letting people go is a tough subject (which I don’t have much experience): I highly recommend asking your HR Business Partner and your manager to help with that.
Your company will also count on you on performance reviews, which happens a few times a year and you can discuss with each person their actual performance along with career progression: if they’re doing really well, you can promote/make a case for their promotion to your peers and senior management. You can also use this time to set goals on what people need to improve and learn for the next cycle. Some companies use this period to set performance improvement plans for people below expectations. Performance reviews usually generate anxiety for everyone: if you’re working on giving continuous feedback every 1:1, it should be an easier conversation without surprises.
As a final recommendation on people expectations, I’d highly recommend learning more about delegation (without micromanaging): allowing people to have autonomy on how they should do a task will allow them to grow and also you can focus on exerting higher leverage. You can’t control every action and if there is a mistake, you have to guide people on learning from it: Ray Dahlio on his book Principles: Life and Work enforces that you should have a culture in which is ok to make mistakes and unacceptable to not learn from them. Google also researched a lot about psychological safety and they found out that in their best teams people feel safe taking risks.
Delivery
Another expectation on an engineering management job is delivery: your company expects that you follow along the deliveries, setting quality standards, making sure the team has the support they need and upper management the feedback they need.
This is where delegation plays its role: to exert leverage, you have to delegate the execution of a project to the team: delegating something doesn’t mean you can forget about that delivery, you need to make sure it is done (or explain why it isn’t) and support that delivery.
Andy Grove tells about 4 types of activities that a manager does: Acquire Information, Communicate Information, Decision Making and Nudging. When support delivering value, we perform these activities: we acquire information about what we’re delivering, we communicate back and forth, we nudge the team on decisions and when the decision has bigger trade-offs or when the team can’t make a decision, we need to make the decision based on the acquired information and communicate our reasoning to everyone else. If a decision is controversial, make it clear and explicit the controversial points and the trade-offs that were considered.
A recurrent is waffling a decision: when the team needs to make a decision and the discussions about it can’t converge: if a decision is a roadblock, it is your duty to understand the tradeoffs, discuss with all relevant parties and make a decision. If it seems complicated, it is because it is.
Communication is probably your most important tool on delivering: acquiring information, partner on generating a purpose along with your peers and communicate the problem being solved to the team and communicate the progress to everyone interested.
When a decision doesn’t seem big and only affects the team, I recommend delegating it to the team and discuss the trade-offs: if prefer one of the options but the other ones doesn’t have significant downsides, nudging is a good idea: telling what path you think it is best and why, but remember: your word carries a lot of weight and people usually expect that a manager makes all decisions.
Another important job is on setting a vision, a mission and objectives: a vision is a long-term objective something that with you expect to reach in 5 year, a mission is a short-term (6 months) and objectives are the guard-rails that will ensure you’re on path to the vision: OKRs is a very famous methodology to help with that.
Process
When teams and companies become bigger it is inevitable that rules, policies and do’s and don’ts start being created. As a leader for your team, it is expected that you keep a constant practice of creating, improving or eliminating team or company processes.
Since the agile manifesto with the tenet People and interactions over processes and tools, processes got a bad reputation: specially the ones more bureaucratic. But the process itself isn’t the problem, the problem is putting it above people and interactions.
I tend to say that the best process is a self regulating one, but I’m aware that it won’t be enough. Self-regulating a team backlog with a 2-3 person team might work, but for a 5-6 person team a regular weekly meeting to discuss and an organized kanban board can be valuable tools.
I tend to start with low or none processes on a new team and when a problem arises, I try to nudge into a process and make a working agreement that we’re going to experiment. With experience, it is likely we will find patterns and solutions we’ve seen elsewhere, but as every team and every context is different, rarely a process took from other team will fit perfectly into a new one.
And if it does not work, you probably need to re-discuss: it is not hard to become the rules cop and start complaining that the people does not follow a process. Instead, do a retrospective and learn what works and what not.
There might be a case in which a process comes from other team and your team is not happy. Your duty is to collect the pain points and bring the concerns to the other team. You actually don’t need to solve everything (and you can’t) but passing along the feedback and listening to the other team concerns as well helps.
Conclusion
I wrote this article as a first reading on someone interested in becoming a manager: I hope that helps you to understand. There are a lot of books and studies about these topics and you will find that improving your skills on them will significantly improve the quality of the work as a manager.
A common path that some companies take is to pick the most senior person on a team and promote them to manager but it takes a lot more than just technical knowledge to be a good manager: being able to communicate well and partner with other functions are other skills that help a lot.
To Learn More
I highly recommend Camille Fournier book The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change: it gives a comprehensible overview of each step on the management ladder.
A fantastic book about people management and specially feedback is Radical Candor: it tells not only the importance of caring about people but also work on challenge them.
22 May 2017
When you work, work hard. When you’re done, be done.
I’ve read a lot of books about how to increase your productivity and I’ve tried a few techniques, but I think this book goes deeper than any other one I’ve read: it tells about the importance of Deep Work and how to work deeply in an era of instant messaging, open offices and constant push notifications on our phones.
Why is that so important ? If you’re like me and work with technology it is not unusual to discover a new technique/language/stack/buzzword envery now and then, and with every new trend comes learning. It is also expected that you perform on our job at an elite level in terms of both quality and speed. However, our latest trends on our industry are Instant Messaging, Open Offices while we seem to be connected all the time (and proactively receiving push notifications on our phones) to a handful of social networks, which isn’t helping that you thrive. This is making people that learns fast and delivers the best work so well valued on our industry.
The book starts with three chapters making the case for Deep Work, why it matters, how it changed the author’s life, and then it goes to how to work deeper with 4 rules (each one described on its own chapter).
The first rule is Work Deeply this seems the whole goal, but there are various pitfalls: how will your willpower sustain your deep work ? How to deal with shallow commitments such as answering to e-mail or going to meetings ? This chapter explain some strategies and how someone can incorporate deep work in his/her daily work (specially if your occupation requires non-deep work as well).
Embrace Boredom is the second rule: it talks about the internet as an agent of distraction, and if you’re distracted all the time when you’re not working, you will also distract when you’re not bored: when you’re bored, do you usually pick up your phone and access a social network or play a game ? If so, you can’t cultivate focus time. As the book quotes:
Don’t take break from distraction, take break from focus,
so cultivate some time off (specially taking internet-breaks).
Following, the third chapter talks about another agent of distraction: Quit Social Media: time is a limited resource, and when you think about how much time do you spend checking your Facebook or twitter feed ? What I really liked about this is that the author presents the any benefit mindset: you think that because of any benefit you might get, you keep using it, without considering the drawbacks. However, if you coldly analyze, and see if it is helping your not your biggest life goals, you might see that the social networks might be costing you relevant time. Despite the dramatic chapter title, the author asks you to evaluate the social networks you’re using and see if it indeed worth it as mileages may vary and it might be useful for you.
Finally, the last rule is about time management, it is called Drain the shallow: I really liked this chapter: the author makes a point on why you should be more thoughtful with your time: you might be wasting it with something and not be aware of that, so he suggests that you keep a notebook (I’m using a calendar) and put a use to every minute of your day, including scheduling shallow tasks. He also recommends a fixed schedule technique: you should finish your workday by a specific time every day, to make time a more valuable resource (as deep work is limited and if you try to squeeze more you won’t ble) and enforcing you to make decisions on what to commit and to use it wisely and to restore your energy for the following day.
One thing that I’ve liked is that the author studied several knowledge workers like Carl Jung, Ted Roosevelt, Donald Knuth, Neal Stephenson, Bill Gates among others and how deep work made such a big difference on their lives. He also does not present it in a dogmatic way, but he rather gives the whys (and quotes academical works when doing so) such techniques provide great results and some real-life examples of each rule.
I’d recommend this book for everyone that does some kind of knowledge work: it might give you some insights on how to increase your skills. It is a great reading for those interested on how to work better, and how to boost your creative power to achieve your full-potential.
09 Jan 2017
As we have reached 2017, I think it is time to remember some things I’ve learned on 2016. All links and information on this blog post are my sincere opining here does not generate any form of revenue nor any other advantage to me.
Getting deeper in Clojure
One of the things I noted last year was that I lacked knowledge of some advanced concepts in Clojure.
The JVM-powered LISP may be threatening to tackle, but once you get the basics, you find yourself productive.
But after getting the basics, how do you organize your code ? How do you deal with mutable parts (like databases) on your code ? How to use Clojure async library ? When to use lists and when to use vectors ?
And sometimes, you will need to write or debug macros, how to understand them better ? Even macros being sometimes described as dangerous, you’ll need them at least to understand. So two books I’ve read about Clojure were “Mastering Clojure Macros” and “Clojure Applied” by Alex Miller (and I even wrote a blog post reviewing this last one), so if you think that you’re ok with the basics (I have a blog post about dealing with the basics too) and want to dive deeper on building applications in Clojure, I think these two are great books for this purpose.
Developing some missing technical skills
Even after 6 years working as a Software Engineer/Developer, I think I miss some important skills like performance analysis.
I had to do some kind of analysis on this area this area and found out that I’ve been using the Streetlight anti-method too much, and a colleague suggested me reading the book Systems Performance by Brendan Gregg. It teaches you some methodologies and some ideas on how to investigate different resources on a computer: application level, CPU, memory, disk and network. It shows how to not fall into pitfalls like only using top to check on a machine saturation.
It also tells about the USE Method, a technique to check for Utilization, Saturation and Errors for a resource to find performance problems.
Business-ish Books
I’ve took some time to read listen to some books (I still find weird to say that I read I book that I actually listened).
One I really liked was Delivering Happiness, by Zappos former CEO Tony Hsieh . It shows how he build Zappos, how he got some suppliers to accept being sold online and how he build the company culture.
One of the coolest things about Zappos is that they publish every year a culture book with quotes from their employee that aren’t edited (except for grammatical correction). I strongly believe that a company culture isn’t on a wall, an internal website or a leaflet that you deliver to new employees, but on actions and words that employees, managers and directors take everyday. I think this was a very bold move to ensure that you’re keeping the culture.
Another book that I really liked was Creativity Inc. Written by Pixel executive Ed Catmull (which I had the pleasure to “meet” on Steve Jobs Biography book that I read listened in 2016), it tells how the creative process works there, how they discuss ideas and how they take risks. I really liked how they tackle mistakes: they understand that they’re part of doing something new, and they’re also aware that ideas aren’t good at first, but after an iterative process, candid feedback and rework a flawed story (or idea) finds its line.
The Minecraft book and Power of Habit were also two other books that I had the pleasure to read this year. The first one tells the story of Marcus “Notch” Persson, and how he build Minecraft. The second book tells why habits exist and how they can be changed:
from Martin Luther King and the Civil Rights Movement, Target stores and how they predict purchasing habits, Alcoa CEO and Safety Concerns and how a NFL head coach made a unpromising franchise one of top teams in the league.
I think this book made me more curious to learn more about Psychology and how the brain works, but this is a subject for the next topic.
Personal Development books
I didn’t write a post like this last year, but one of the books that I’ve read listened last year that I most enjoyed was Soft Skills by John Sonmez and one of the tips he gave is on how to improve yourself not just as a programmer/engineer/developer but as a person. And after reading that I discovered that I had too much to learn indeed.
One of the books recommended was a really classical one: “How to win friends and influence people” by Dale Carnegie. The book starts telling you how to read it. It tells you to read every chapter twice and for you to explain what you have learned to someone else and ask them to monitor how you are practicing what you’ve learned. One of the great teaching I got from the book was “Be hearty in your approbation and be lavish in your praise”, it means that you should use your heart you complement something. But when you have to do some criticism, do it when necessary and be mindful to consider the other side reasons, plus make them see what is wrong instead of just enforcing it.
Another book I’ve read and liked was “Pragmatic Thinking and Learning”: it shows you how your brain works, hence how to learn, how to tackle problems and a different way to study. I think skill acquisition is a important skill: by reading this book you discover that reading books cover-to-cover can be a naive approach on skill acquisition.
Generic Trivia
I also like to read fun books: I really liked Periodic Tales by, a book that tells you the history and how some elements were discovered and used througout the ages. I’m a great fan of science books and I like to learn about science trivia.
Learning new things
In 2015 I started learning how to use Emacs and in 2016 I kept learning more about it: I followed Mike Zamansky channel on youtube which tells you some good tips about packages and techniques on Emacs. I also chose org-mode as my main tool for taking notes while reading.
Another library that I’ve learned how to use and its powers was Finagle. Built by Twitter, it intends to be an extensible RPC system for the JVM. It implements several protocols like HTTP, Thrift, MySQL, Redis and has several modules that implement some resilience strategies like circuit breaking, client side load-balancing, budgeting and retrying, that you can use with any of the protocols. One of the great advantages of such approach
is that it can give a small rest to a troubled part of your system (with exponential retrials) so it can recover. The retry may also help when only a node is down but others are up (and a load balancers on server side does the round robin) and the budgeting may avoid you retrying too much (and for the server side to recover. It is a must-have piece when you have some relevant load on your applications and you have a multi-service architecture.
Conclusion
2016 was a great year on many aspects: I was able to apply many of things that I’ve learned here on my daily routine, I’ve also deepened some concepts on Clojure and Emacs. Hope in 2017 that I blog more about the things I learned more consistently.
Feel free to recommend any book or article on this subject and a happy 2017!