Tips for engineers from Google manager
Hello!
My name is Larisa. I work at Google and run a blog at larrr.com , where I originally published this article.
Today I bring to your attention an article that was originally written solely for internal use by Google. I really liked it, so I contacted the author, with her permission, I redid her a little and got permission from Google Press to publish. My translation
Just in case, this is not an official Google document, and Google is not responsible for its content. It is subjective, and is written by an employee for employees.
')
Tips for engineers
April 15, 2013
Edited May 21, 2014
Translated August 31, 2015
Gretta Bartels, Software Engineering Manager at Google
Dear reader,
In this document, I described some of the principles on which I rely in working with my teams. There is nothing fundamentally new or revolutionary in them; all these principles have long been known to each of us. But knowing and doing are two different things. Therefore, this document is also a reminder for me too that my job as a manager is to follow these principles myself and remind others of them.
One of my more experienced colleagues taught me that it’s very important for a manager to be as predictable as possible. A manager should have some set of simple rules that all his subordinates know about, and which they can follow even when there is no manager nearby. Therefore, my goal is for the programmers on my team to ask themselves the question “What would my manager say to this?” And answer themselves correctly to him. Then the team will be able to work almost independently, without my leadership. And I will sit at home and eat cakes :).
Here is a list of my basic rules:
1. Do the work that really matters.
1a) Always ask yourself the question “Why are we doing this?”
Whatever you do, everyone should always clearly know two things - 1) why are you doing this? 2) How do you understand that you have achieved the desired result? Even if it seems to you that you can answer yourself for the question “why?”, Do not stop at the first appropriate answer, look deeper. Ask yourself this question again and again until the answer is simple, obvious, and at the same time quite large-scale.
This is somewhat similar to the “ 5 why ” method, when technicians repeatedly ask themselves the question “why?”, Delving back to find the cause of the problem. But in our case, I propose to use this method for any work, and not just to find the causes of problems.
And here's an example from life. One of my teams is currently working to improve the quality of data for Google Maps (namely, we find and eliminate internal data contradictions). In this case, the “why” chain might look like this:
We eliminate data inconsistencies.
-> so that we can integrate existing and new data easier and faster
-> so that we can update the data faster
-> to ensure that Google Maps is as accurate as possible.
-> to ensure that the quality of Google Maps meets a very high standard and user requirements
-> so that people actively use and trust Google Maps (and Google products in general)
Looks pretty simple, right? But based on my experience, not all engineers ask themselves these questions and see beyond the specific and isolated task they are working on.
In fact, understanding “why?” Is very important for your work. Critically important, I would say.
By the way, there may be several answers to your “why?” This is a good sign - probably your project is really important.
And more important, especially for managers: using the “why” chain, you not only can better understand why you are doing something and how to do it better, but also see other strategic areas of development for your projects. Just go from the other end of the chain and ask yourself the question “how?”.
1b) The most important thing is the result
As a manager, I rate my employees by the following parameters: Knowledge and Experience, Difficulty, Leadership and Results. Although all of them are important for professional development and career growth, one of the parameters is much more important than the others. This is the result.
Most companies are not training and development sites for programmers. These are businesses that work, and it is thanks to this that we can work in them. By the way, I personally like this combination - business and technology. I like working on things that change the world. And many engineers with whom I spoke on this subject - as well.
It is curious that the result does not follow at all from the other parameters. You can be a smart, experienced, knowledgeable charismatic manager or a technical team member who is working on an incredibly difficult and interesting task. A task that does not have any strategic importance at all. On the other hand, it is hardly possible to create something worthwhile without having knowledge, or without being a good leader.
By the way, about the complexity. It happens that to achieve an important result, you do not need to do anything complicated. This is normal. Always look for and take simple and important projects at the same time when you get the chance.
1c) Plans are useless, but important
I believe in OKR (abbreviated Objectives and Key Results - goals and key results - the method used in modern project management. Allows you to synchronize team and individual goals and provide effective control over the implementation of tasks. Wiki .). I ask all engineers in their teams to write and evaluate them quarterly.
Writing goals has many advantages. But I think that the most important one is this: your time is limited and you should occupy it with the things that will bring the most benefit. In addition, they can significantly improve the quality of planning. Without strategic planning, you can easily fall into two very common pitfalls: overestimate how much you can do in a quarter, and drown in urgent matters instead of important ones. However, with planning, you can also get into them, but it will be much easier for you to recognize them and get out of them.
The situation when you do urgent things instead of doing important things is familiar to many. Here in this article, this topic is well disclosed. Read if you are interested.
An even more interesting problem is the revaluation of its capabilities. As a manager, I regularly have to help engineers be more careful in their assessments - in my experience, many people greatly overestimate the amount of work they can do in a given period of time. There were cases when people set many goals, did each by 30-50%, but did not bring any goal to the planned result. Much better to do two or three goals at 100%.
Using written planning and evaluating their results after the quarter, many can significantly improve their skills in setting and achieving goals. Even without significantly changing their productivity, they begin to make more realistic forecasts and bring several really important things to the end. That is why I think OKR is incredibly important for their teams, and I hope that as many people as possible will master this skill.
2. Do not waste your time
2a) Accelerate (aka How about a couple of tests?)
During my studies at the university, as a test job, I had to write a Boggle game with a beautiful interface and support for the remote game of several users. Naturally, I didn’t even move a finger until the last day before surrender. At 3 o'clock in the morning I discovered that my hastily written program contains a bug that got out at the very end of the game.
So I spent the rest of the night playing my game, trying to repeat the bug and find its cause. Of course, it was at least stupid. I just had to set the game timer for 5 seconds and it would have gone much faster. In my defense, I want to say that it was near morning, I really wanted to sleep, and not to look for errors in my program. It would be even better to write a test, but then I didn’t even hear about the tests.
Every time you repeat a piece of a program again and again, trying to find a mistake and fix it, make sure that these repetitions are as short as possible. Most likely this will seem superfluous to you, since you will be sure that you have found the error the first time. But it happens very rarely. You will probably soon realize that this is not it, and you will have to repeat the process from the beginning. And then again.
Therefore, when working on any project, try to make it as easy as possible to test it. Make it modular, make it so that any part of the program can be as simple as possible to isolate and test. Believe me, the moment will come when you will be glad you did it. And if you have problems with modularity and insulation, then this is a good reason to think about how good your design is in principle.
A similar principle applies to working with people and products. When you are in a situation of uncertainty, think about how to conduct a quick and simple experiment that would give you at least some preliminary data.
2b) Get rid of the problem once and for all (aka Automate)
People should not waste time on things that are much better with computers. This is not even discussed.
We all do programming to make life easier and automate things that can be automated. It would seem that engineers will try to maximally apply this principle to themselves as well. But it turns out that not at all!
Many times I have seen people doing the same recurring task from time to time manually instead of automating it. The main excuse in this situation is “it only takes a few minutes, and the process automation will take a whole day.” Sometimes it is even true, but not as often as it may seem.
Automating the task:
2c) evolve
Do not do the same thing for too long. After you have mastered some area, either automate it (see above), or train another engineer for this job and move on. Grow professionally, do not let yourself stagnate.
Sometimes people do not do this because their work seems routine to them and they do not want to transfer this routine to others. But what may seem like a chore to you will be a great opportunity to learn something for another, perhaps less experienced, engineer. Even if this is not the case, it most likely makes much more sense for the team when several people deal with a specific task at once. Otherwise, it may become a narrow link.
Sometimes people hold on to their tasks because it seems to them that it is too difficult to explain them to others, or because they believe that they cope with them better than anyone. If this is your case, then you should seriously consider creating good documentation.
I constantly advise engineers in their teams to switch to new tasks and develop professionally.
3. Do not work in a vacuum (aka Communicate with others)
Try to describe the design of the systems on which you will work, in advance (aka write design docs). Send these documents to your colleagues and ask what they think. By doing this, you:
Talk about your work (you can with slides). Encourage others to tell about their work. Be actively interested in what others in your and neighboring teams do. You and your team will benefit from this.
Many do not want to talk and write about their work until it is ready. Or they just do not like to write. These are weak excuses. If you do not want to write, or do not want to make a presentation at once for the whole team, then start small - just talk to one specific colleague, draw a sketchy design on the board. It will help you organize your thoughts, and writing a document or discussing it with a whole group will be much easier.
If you liked the article, then come to my blog . Perhaps there you will find even more interesting things for yourself. I have almost 300 articles on Google, career, self-development and productivity (some of them were once on Habré). I love to write, and, as it seems to me, I am doing quite well. At least sometimes.
I would be glad if you like it!
My name is Larisa. I work at Google and run a blog at larrr.com , where I originally published this article.
Today I bring to your attention an article that was originally written solely for internal use by Google. I really liked it, so I contacted the author, with her permission, I redid her a little and got permission from Google Press to publish. My translation
Just in case, this is not an official Google document, and Google is not responsible for its content. It is subjective, and is written by an employee for employees.
')
Tips for engineers
April 15, 2013
Edited May 21, 2014
Translated August 31, 2015
Gretta Bartels, Software Engineering Manager at Google
Dear reader,
In this document, I described some of the principles on which I rely in working with my teams. There is nothing fundamentally new or revolutionary in them; all these principles have long been known to each of us. But knowing and doing are two different things. Therefore, this document is also a reminder for me too that my job as a manager is to follow these principles myself and remind others of them.
One of my more experienced colleagues taught me that it’s very important for a manager to be as predictable as possible. A manager should have some set of simple rules that all his subordinates know about, and which they can follow even when there is no manager nearby. Therefore, my goal is for the programmers on my team to ask themselves the question “What would my manager say to this?” And answer themselves correctly to him. Then the team will be able to work almost independently, without my leadership. And I will sit at home and eat cakes :).
Here is a list of my basic rules:
1. Do the work that really matters.
1a) Always ask yourself the question “Why are we doing this?”
Whatever you do, everyone should always clearly know two things - 1) why are you doing this? 2) How do you understand that you have achieved the desired result? Even if it seems to you that you can answer yourself for the question “why?”, Do not stop at the first appropriate answer, look deeper. Ask yourself this question again and again until the answer is simple, obvious, and at the same time quite large-scale.
This is somewhat similar to the “ 5 why ” method, when technicians repeatedly ask themselves the question “why?”, Delving back to find the cause of the problem. But in our case, I propose to use this method for any work, and not just to find the causes of problems.
And here's an example from life. One of my teams is currently working to improve the quality of data for Google Maps (namely, we find and eliminate internal data contradictions). In this case, the “why” chain might look like this:
We eliminate data inconsistencies.
-> so that we can integrate existing and new data easier and faster
-> so that we can update the data faster
-> to ensure that Google Maps is as accurate as possible.
-> to ensure that the quality of Google Maps meets a very high standard and user requirements
-> so that people actively use and trust Google Maps (and Google products in general)
Looks pretty simple, right? But based on my experience, not all engineers ask themselves these questions and see beyond the specific and isolated task they are working on.
In fact, understanding “why?” Is very important for your work. Critically important, I would say.
- Without this understanding, it is much more difficult to evaluate the results of your work. And it is much more difficult to adapt to the ever-changing requirements of the project, as a result of which you may need to prove to the management that what you are doing is really important.
- In addition, this way you can find other people and teams that have the same fundamental goal. You can find support and allies, the importance of which is very difficult to overestimate.
- Plus, you can better prioritize existing projects.
By the way, there may be several answers to your “why?” This is a good sign - probably your project is really important.
And more important, especially for managers: using the “why” chain, you not only can better understand why you are doing something and how to do it better, but also see other strategic areas of development for your projects. Just go from the other end of the chain and ask yourself the question “how?”.
1b) The most important thing is the result
As a manager, I rate my employees by the following parameters: Knowledge and Experience, Difficulty, Leadership and Results. Although all of them are important for professional development and career growth, one of the parameters is much more important than the others. This is the result.
Most companies are not training and development sites for programmers. These are businesses that work, and it is thanks to this that we can work in them. By the way, I personally like this combination - business and technology. I like working on things that change the world. And many engineers with whom I spoke on this subject - as well.
It is curious that the result does not follow at all from the other parameters. You can be a smart, experienced, knowledgeable charismatic manager or a technical team member who is working on an incredibly difficult and interesting task. A task that does not have any strategic importance at all. On the other hand, it is hardly possible to create something worthwhile without having knowledge, or without being a good leader.
By the way, about the complexity. It happens that to achieve an important result, you do not need to do anything complicated. This is normal. Always look for and take simple and important projects at the same time when you get the chance.
1c) Plans are useless, but important
I believe in OKR (abbreviated Objectives and Key Results - goals and key results - the method used in modern project management. Allows you to synchronize team and individual goals and provide effective control over the implementation of tasks. Wiki .). I ask all engineers in their teams to write and evaluate them quarterly.
Writing goals has many advantages. But I think that the most important one is this: your time is limited and you should occupy it with the things that will bring the most benefit. In addition, they can significantly improve the quality of planning. Without strategic planning, you can easily fall into two very common pitfalls: overestimate how much you can do in a quarter, and drown in urgent matters instead of important ones. However, with planning, you can also get into them, but it will be much easier for you to recognize them and get out of them.
The situation when you do urgent things instead of doing important things is familiar to many. Here in this article, this topic is well disclosed. Read if you are interested.
An even more interesting problem is the revaluation of its capabilities. As a manager, I regularly have to help engineers be more careful in their assessments - in my experience, many people greatly overestimate the amount of work they can do in a given period of time. There were cases when people set many goals, did each by 30-50%, but did not bring any goal to the planned result. Much better to do two or three goals at 100%.
Using written planning and evaluating their results after the quarter, many can significantly improve their skills in setting and achieving goals. Even without significantly changing their productivity, they begin to make more realistic forecasts and bring several really important things to the end. That is why I think OKR is incredibly important for their teams, and I hope that as many people as possible will master this skill.
2. Do not waste your time
2a) Accelerate (aka How about a couple of tests?)
During my studies at the university, as a test job, I had to write a Boggle game with a beautiful interface and support for the remote game of several users. Naturally, I didn’t even move a finger until the last day before surrender. At 3 o'clock in the morning I discovered that my hastily written program contains a bug that got out at the very end of the game.
So I spent the rest of the night playing my game, trying to repeat the bug and find its cause. Of course, it was at least stupid. I just had to set the game timer for 5 seconds and it would have gone much faster. In my defense, I want to say that it was near morning, I really wanted to sleep, and not to look for errors in my program. It would be even better to write a test, but then I didn’t even hear about the tests.
Every time you repeat a piece of a program again and again, trying to find a mistake and fix it, make sure that these repetitions are as short as possible. Most likely this will seem superfluous to you, since you will be sure that you have found the error the first time. But it happens very rarely. You will probably soon realize that this is not it, and you will have to repeat the process from the beginning. And then again.
Therefore, when working on any project, try to make it as easy as possible to test it. Make it modular, make it so that any part of the program can be as simple as possible to isolate and test. Believe me, the moment will come when you will be glad you did it. And if you have problems with modularity and insulation, then this is a good reason to think about how good your design is in principle.
A similar principle applies to working with people and products. When you are in a situation of uncertainty, think about how to conduct a quick and simple experiment that would give you at least some preliminary data.
2b) Get rid of the problem once and for all (aka Automate)
People should not waste time on things that are much better with computers. This is not even discussed.
We all do programming to make life easier and automate things that can be automated. It would seem that engineers will try to maximally apply this principle to themselves as well. But it turns out that not at all!
Many times I have seen people doing the same recurring task from time to time manually instead of automating it. The main excuse in this situation is “it only takes a few minutes, and the process automation will take a whole day.” Sometimes it is even true, but not as often as it may seem.
Automating the task:
- Anyone will be able to cope with this task, even a person who has just started working in a team, or an automatic process. Hand-made minutes will quickly gather in hours and even days - the task will start when you sleep, when you eat, and when you are ill.
Automating a small task can open the door for more extensive optimization. - You can discover situations that you never even thought about before attempting to automate the entire process.
- Creating processes in order to automate them later will significantly improve your process design skills.
2c) evolve
Do not do the same thing for too long. After you have mastered some area, either automate it (see above), or train another engineer for this job and move on. Grow professionally, do not let yourself stagnate.
Sometimes people do not do this because their work seems routine to them and they do not want to transfer this routine to others. But what may seem like a chore to you will be a great opportunity to learn something for another, perhaps less experienced, engineer. Even if this is not the case, it most likely makes much more sense for the team when several people deal with a specific task at once. Otherwise, it may become a narrow link.
Sometimes people hold on to their tasks because it seems to them that it is too difficult to explain them to others, or because they believe that they cope with them better than anyone. If this is your case, then you should seriously consider creating good documentation.
I constantly advise engineers in their teams to switch to new tasks and develop professionally.
3. Do not work in a vacuum (aka Communicate with others)
Try to describe the design of the systems on which you will work, in advance (aka write design docs). Send these documents to your colleagues and ask what they think. By doing this, you:
- Streamline your own thought process.
- Make sure that someone else is not involved in a similar project.
- Improve your design by taking advantage of helpful advice from your colleagues.
- It is much easier to find colleagues who will agree to help you.
- Show yourself as an active and responsible team member.
Talk about your work (you can with slides). Encourage others to tell about their work. Be actively interested in what others in your and neighboring teams do. You and your team will benefit from this.
Many do not want to talk and write about their work until it is ready. Or they just do not like to write. These are weak excuses. If you do not want to write, or do not want to make a presentation at once for the whole team, then start small - just talk to one specific colleague, draw a sketchy design on the board. It will help you organize your thoughts, and writing a document or discussing it with a whole group will be much easier.
If you liked the article, then come to my blog . Perhaps there you will find even more interesting things for yourself. I have almost 300 articles on Google, career, self-development and productivity (some of them were once on Habré). I love to write, and, as it seems to me, I am doing quite well. At least sometimes.
I would be glad if you like it!
Source: https://habr.com/ru/post/330296/
All Articles