Great article, guys! I’m curious about the moving fast philosophy. While I was working on my startup, where we created custom software for clients, we always took the time to write clear onboarding documents and set up steps for the team working on the project later. But these were smaller projects, so I thought that’s why anyone could get it running in hours.
However, working now in an enterprise with a more complex project, I assumed that it was normal for me to need a day for setup.
But now reading your experience at Meta I began to think, maybe it depends on how much effort you put into developer experience? I’m sure whatever you set up at Meta was more complex than the current enterprise project I work on.
I mentioned that this was not fast or easy or straightforward at Amazon. The main reason for that is that Amazon is distributed. From a code perspective, they have millions of separate code repositories, thousands of independent teams that choose how they want to work, etc.
Meta has a monolithic repository (monorepo) where tens of thousands of developers work in the same code base. Engineers work across team boundaries all of the time. This centralization makes it possible to build a consistent developer environment.
It also makes it trivial to fix a bug that requires one-line changes across a dozen teams’ code. At Amazon this would take one hour change would take weeks of negotiations.
So, everything comes with trade-offs. Amazon teams are self contained and have a ton of autonomy, which entails a varied and non standardized developer experience.
I just had a question, the goal of a manager (eventually) is that you grow your people enough that they can autonomously go from 0 to a 100 in a project with little to no oversight. Your contribution as a manager will be smaller and smaller but that, to me, means you did a great job. When a great IC performs very well (like in your example), is that accounted for? You might actually have little to no contribution for that project, but that doesn't mean you didn't support and help then get to that point.
Really great question! There are two main aspects to this, in my opinion.
The first is, what does it mean to DO a great job as a manager. From this perspective, the work that you did in the past means that you were a great manager in the past. What about the present? Can you do more to support that IC’s growth even more?
The second aspect is about how to EVALUATE the performance of a manager. This is much more challenging, precisely because there is a “phase shift” between action and result. The value that a manager creates is often, but not always, only realized several months later. This time-offset grows the further up the ladder that you climb.
Regarding the second part, from the point-of-view of the line-manager, my recommendation is to first and foremost have a NARRATIVE of what you accomplished. You should be able to tell a STORY about what and how you contributed. You should collect and back it up with evidence, but only after you have a clear narrative.
Thank you for answering Gilad! I like the idea of a narrative, if you're doing it right that should become self evident by supporting the IC growth deliberately. If it's not then you might need to stop and reflect a while longer about your team's journey.
Let's assume your engineer is indeed doing great, and you are not involved at all in their day. They plan things themselves, execute, and barely talk to you, all the while succeeding. In this case, the only thing you do is 'not interfere', which is not much. The question should be - how much better can that engineer be, and what can you do to support them? Maybe just helping to choose the right projects, connecting with people inside the company or from your previous companies is enough.
I believe that if you can't point to specific things you did to support that engineer, you didn't do that great of a job.
Thanks for answering here, I like the idea of "not interfering" which is eventually what I was leading to. Generally agree though there has to be a distinction between "I did nothing as a manager, they had to figure it all out" vs "I coached them to get to this point and made sure they were successful in delivering this project autonomously". It has to be a culmination of a growth journey rather than a complete absence from the manager, I should have called that out better. Thank you again!
I think there is still a place to dive deeper here :)
So for example you coached them for 3 years, and they grew a lot. There are specific things you did to coach them - 1:1 conversations, helped them learn from mistakes, and so on. You had a 'positive delta' on their progression.
Now, in year number 4, you didn't interfere, and they delivered autonomously. That year was a culmination of the previous 3, but during it, you didn't do anything actively to help the individual.
In this case, I still feel you could have done your job better. Maybe that individual is now ready for a bigger challenge, and a cross-team IC role. Or they can take on more management responsibilities that will challenge them.
I think that if you look at a long period of time (3+ months), there are for sure things you can do to help ANY individual in your team to succeed more. It doesn't mean interfering, but thinking on how to grow them even further and not be satisfied with the great coaching you already did.
I definitely do not disagree with that, there's always room for growth and wonder about "what's next". I like to think about this as the teacher/student relationship where once the student "surpasses" the teacher we reach an ideal teacher/student relationship. Your highlight though is a good remark on the fact that coaching continues to evolve from there, so your job as a manager is not done (in your example, it is not "done" by the autonomous delivery of the project).
I promise this is not AI generated, I was re-reading my message and felt compelled to point that out ahah
Thanks for the thoughtful comments! I think it’s an interesting debate, and a common case of good managers, who feel satisfied with ‘past’ coaching and don’t try to push people even further.
Interesting journey! Most of the learnings can apply to other startups, like moving fast (for this investing in tooling and DevEx is critical) and having a calibration process to provide fairness performance reviews. Thanks both for the insightful article!
Great article, guys! I’m curious about the moving fast philosophy. While I was working on my startup, where we created custom software for clients, we always took the time to write clear onboarding documents and set up steps for the team working on the project later. But these were smaller projects, so I thought that’s why anyone could get it running in hours.
However, working now in an enterprise with a more complex project, I assumed that it was normal for me to need a day for setup.
But now reading your experience at Meta I began to think, maybe it depends on how much effort you put into developer experience? I’m sure whatever you set up at Meta was more complex than the current enterprise project I work on.
As usual, there are trade-offs.
I mentioned that this was not fast or easy or straightforward at Amazon. The main reason for that is that Amazon is distributed. From a code perspective, they have millions of separate code repositories, thousands of independent teams that choose how they want to work, etc.
Meta has a monolithic repository (monorepo) where tens of thousands of developers work in the same code base. Engineers work across team boundaries all of the time. This centralization makes it possible to build a consistent developer environment.
It also makes it trivial to fix a bug that requires one-line changes across a dozen teams’ code. At Amazon this would take one hour change would take weeks of negotiations.
So, everything comes with trade-offs. Amazon teams are self contained and have a ton of autonomy, which entails a varied and non standardized developer experience.
I'm curious to hear Gilad's answer here :)
I'm working at a small startup and it can take more than a day to set it up, and it's definitely less complex than your enterprise :)
I think it for sure depends on how much time you put it. As a company grows, it has to be a constant effort to battle the entrophy
I just had a question, the goal of a manager (eventually) is that you grow your people enough that they can autonomously go from 0 to a 100 in a project with little to no oversight. Your contribution as a manager will be smaller and smaller but that, to me, means you did a great job. When a great IC performs very well (like in your example), is that accounted for? You might actually have little to no contribution for that project, but that doesn't mean you didn't support and help then get to that point.
Really great question! There are two main aspects to this, in my opinion.
The first is, what does it mean to DO a great job as a manager. From this perspective, the work that you did in the past means that you were a great manager in the past. What about the present? Can you do more to support that IC’s growth even more?
The second aspect is about how to EVALUATE the performance of a manager. This is much more challenging, precisely because there is a “phase shift” between action and result. The value that a manager creates is often, but not always, only realized several months later. This time-offset grows the further up the ladder that you climb.
Regarding the second part, from the point-of-view of the line-manager, my recommendation is to first and foremost have a NARRATIVE of what you accomplished. You should be able to tell a STORY about what and how you contributed. You should collect and back it up with evidence, but only after you have a clear narrative.
Thank you for answering Gilad! I like the idea of a narrative, if you're doing it right that should become self evident by supporting the IC growth deliberately. If it's not then you might need to stop and reflect a while longer about your team's journey.
That's a great question.
Let's assume your engineer is indeed doing great, and you are not involved at all in their day. They plan things themselves, execute, and barely talk to you, all the while succeeding. In this case, the only thing you do is 'not interfere', which is not much. The question should be - how much better can that engineer be, and what can you do to support them? Maybe just helping to choose the right projects, connecting with people inside the company or from your previous companies is enough.
I believe that if you can't point to specific things you did to support that engineer, you didn't do that great of a job.
Thanks for answering here, I like the idea of "not interfering" which is eventually what I was leading to. Generally agree though there has to be a distinction between "I did nothing as a manager, they had to figure it all out" vs "I coached them to get to this point and made sure they were successful in delivering this project autonomously". It has to be a culmination of a growth journey rather than a complete absence from the manager, I should have called that out better. Thank you again!
I think there is still a place to dive deeper here :)
So for example you coached them for 3 years, and they grew a lot. There are specific things you did to coach them - 1:1 conversations, helped them learn from mistakes, and so on. You had a 'positive delta' on their progression.
Now, in year number 4, you didn't interfere, and they delivered autonomously. That year was a culmination of the previous 3, but during it, you didn't do anything actively to help the individual.
In this case, I still feel you could have done your job better. Maybe that individual is now ready for a bigger challenge, and a cross-team IC role. Or they can take on more management responsibilities that will challenge them.
I think that if you look at a long period of time (3+ months), there are for sure things you can do to help ANY individual in your team to succeed more. It doesn't mean interfering, but thinking on how to grow them even further and not be satisfied with the great coaching you already did.
I definitely do not disagree with that, there's always room for growth and wonder about "what's next". I like to think about this as the teacher/student relationship where once the student "surpasses" the teacher we reach an ideal teacher/student relationship. Your highlight though is a good remark on the fact that coaching continues to evolve from there, so your job as a manager is not done (in your example, it is not "done" by the autonomous delivery of the project).
I promise this is not AI generated, I was re-reading my message and felt compelled to point that out ahah
Thank you for the thoughtful exchange!
I didn’t think at all it’s AI generated 😂
Thanks for the thoughtful comments! I think it’s an interesting debate, and a common case of good managers, who feel satisfied with ‘past’ coaching and don’t try to push people even further.
Interesting journey! Most of the learnings can apply to other startups, like moving fast (for this investing in tooling and DevEx is critical) and having a calibration process to provide fairness performance reviews. Thanks both for the insightful article!
Yeah I really liked that interpretation of Meta's moving fast, I never thought about it like this :)