Engineering practices @ Meta: #2 Software engineers choose their projects
How software engineers at meta have a lot of autonomy in choosing what they work on
One unique aspect of Meta’s engineering culture as I experienced it, is the degree of autonomy that software engineers possess in choosing their projects.
When you onboard to any new team, you initially follow the onboarding process of that specific team, It’s very task-centric in the beginning
You get started with some starter tasks. Initially, they are small in size, something that you can reasonably expect to finish in a day or two and they incrementally keep on increasing in complexity from a few days to weeks and possibly even multi-month projects
You own your projects 🫵🏼
As you move on from task to task, and after you finish your first month in the team, you are expected to find a project that is appropriate to your specific level and scope.
This is quite a departure from working in a typical start-up environment where say a lot of problem space identification and scope definition may be done by product managers, business, or engineering leaders.
You personally get a lot of autonomy towards choose something that you want to work on.
Usually, it’s a good idea to also align with your manager on if it makes sense to pursue that idea/project and you get a wider mileage with it in your performance reviews if it directly contributes to achieving your team/org OKR but projects are not always driven by this.
If the team has an experienced tech lead or engineering manager then they may be able to also provide suggestions on potential problems to pick up from the problem space and help you craft project ideas
In the absence of that strong leadership, You as the software engineer have to take ownership of picking a problem, defining it, and eventually driving it to a solution.
I’ll caveat this by saying that this comes from my biased opinion of having worked in a horizontal platform team. Your mileage may vary on a product team tasked with shipping features to the customers, but this is what I’ve heard other senior engineers also say is the norm.
What about n00bs? 🤔
Now, As I understand, Software engineers who are earlier in their engineering careers or just new to a domain/team also struggle with this problem since they don’t necessarily have the big picture right at the start to find a project that makes sense.
In such cases, the advice I’ve found myself giving is to speak with members of the team, understand their pain points, and find out what if fixed may make life easier for them or the end users.
Choosing to work on a solution to that problem while ensuring it is somewhat of a priority and can contribute towards making a meaningful impact is usually a good strategy.
After soaking in the problem space and working in that specific area/domain for some halves, you also start to also develop a knack for figuring out what is a true problem vs just noise and get good at choosing your projects.
| Thanks for the time you spent reading this 🙌. If you found this post helpful, please share it with your friends and follow me (@automationhacks) for more such insights in Software Testing and Automation. Until next time, Happy Testing 🕵🏻 and Learning! 🌱 | Newsletter | YouTube | Blog | Twitter. |
Comments