You are a senior engineer or a tech lead who works in a company that has gotten big enough where it’s hard to “get things done”. There are always people with a different agenda than you and you have to work through multiple layers of bureaucracy to get your projects prioritized or even considered. But you know that it’s not impossible to get it done because things are happening and the culture is not worse than any other company - this is just what happens when the company starts to get big (if it feels impossible to get things done for everyone, it might be time to start leetcoding). So, let’s discuss what you might need to get the projects that you are interested in prioritized.
If you are in a traditional tech company, you’ve got your Product Managers (PM), Designers, Engineering Managers (EM), and other Individual Contributors (IC). In each of those verticals, there are folks at the IC level ranging from Junior engineers/designers to Staff or above. The EM could be a brand-new manager or a Director managing a team of 250+ engineers. The PM could be an apprentice or more senior like a Group Product Manager (GPM).
While seniority is by no means an indicator of proficiency in skills, it is a good indicator of the level of scope that those folks are operating at and what level of control they have over the team’s roadmap.
If you want to get things done, you need to know who to talk to, who to build a relationship with, and who to convince. Trying to only convince a superstar Junior engineer to get a 6-month project that requires 5 engineers prioritized is just not going to work, no matter how excited the engineer is to work on it.
Are you waiting for the right project to come by or are you willing to show initiative and come up with your own project? I have seen both strategies work really well but the former one seems to be dependent a little on luck (or networking?) whereas the latter one puts you in control. For me, creating my own projects has worked far better than waiting for the right project in terms of career growth and overall performance.
What the project is depends very much on your team and org - is your team a Product, Platform, Infra, or somewhere in between. Does your team build user-facing features or internal tools or maybe you own engineering heavy systems like supporting the storage layer for the entire company or the Kafka cluster. You get the idea.
The project has to fit in to what your team and your org does. If you work in the storage team and have a great idea for a user-facing feature, it is going to be an uphill battle. In these cases, it might be best to pass along your idea to the right team’s PM or change teams to position yourself better. If you are not sure of the idea, ask yourself that if your project is successful, will your team’s core metrics improve in a measurable way? The more aligned you are with your team, the better chances you have of getting your project prioritized.
In any case, the goal is to have a project that you are willing to work on for the next few months, that you are excited by, and are even willing to fight for. While your life doesn’t need to revolve around work, a little bit of passion never hurt anyone’s chance of succeeding at work.
Once you have a project, it is time to start campaigning for it. The goal is to build consensus around the team that your project is a worthy investment and that it will have a positive impact on the team’s core metrics. First things first, write your thoughts down. Whether you work at Amazon and have a writing culture or you work at a smaller company where writing is not prioritized, it is a more elegant and efficient way of communicating your thoughts. The document can be shared along, people can comment on it, and it will have a much wider reach than your network.
This is also the time for you to ‘match’ your project to the right stakeholders. There are a couple of criteria when trying to find the right stakeholders - type of project and its scope. The type of project will determine whether you need to convince the Engineering, Product, or Design vertical (or some other vertical depending on your project). The scope of the project determines how high up you need to go up on the ladder.
If the project is engineering heavy (ex. reduce tech debt), it should make sense to convince the EM. If the scope is limited to code that your team is responsible for, you don’t need to go further than your EM. But, if you have a goal of reducing tech debt across all of your services, you will need buy-in from other teams as well. This is when you go up the ladder, convince the leadership, and then propagate the message back down to all EMs. The wider the scope of your project, the higher up you need to go, and the better your arguments need to be for your project.
Whether you have a small or a large project, it almost always makes sense to write your thoughts down. At the least, set context for your project (assume your reader has very little knowledge of how your teamorgproduct works), how things are done today, what the metrics look like, and so on. Then, pitch your proposal that should include all of the changes you plan on making and what impact it will have i.e. what the product or metrics will look like once the project is completed. Make sure people can trust your hypothesis and buy-in to it.
Once your document has made the pitch, put in your ask ex. I need a team of 5 engineers for 4 months to complete this project. Now, in your 1:1s, start talking about the project, share this document, and get feedback. Use the feedback to either tweak your project or clarify your arguments. Rinse and repeat until you start to build consensus.
The timing of pitching your project is important - many teams either plan quarterly or twice a year (H1 & H2). In most cases, it doesn’t make sense for the leadership to de-prioritize existing projects and replace it with your projects (it can happen if the project is truly urgent). Remember that resources are finite. It always helps when you understand the decision making process and can reverse-engineer it to your benefit.
Having said that, it is never too early to start talking about the problem that you are trying to solve and the solution that you are pitching. But, you have to remember to notch things up when it’s planning time. Get your project on everyone’s radar, make sure it is discussed, and more often than not, if your arguments are clear and logical, impacts the right metrics, your project will get prioritized.
It may be helpful to know that in many companies, leadership needs new projects. Especially in fast growing companies, the headcount can grow faster than projects can be created. By pitching your own projects, you are making their life easier.