As you grow in a role, it’s common that you’re increasingly taking on more responsibility and direction setting. You need to provide the right kind of project work for other people and then help them get from A to B. But what’s the “right” kind of work? And what if you aren’t sure how to get there yet?

Most organizations expect you to pick up how to do this over time by watching others, but you can intentionally build this as a skill, too. I often coach this as: See. Spot. Run.

See: Take a look around.

Your ideas should push your company forward towards their goals. If you don’t know what

Make sure you understand your company’s business.

Especially as organizations grow, it becomes increasingly important to understand your team’s mission. How do they make money and what’s their current strategy? A big part of the buy-in process is being able to articulate how your work advances those goals. Your company probably publishes a strategy somewhere. Read it until you understand it well enough to explain it in less than a minute.

Read and listen to others.

Go see what other teams are doing. Maybe they regularly publish reports or present at company wide meetings. Find some projects that you think were done well. Ask the person who ran them how they had the project idea and how they iterated on it.

I highly recommend breaking out of your company bubble once in a while, too. Attend a conference or a meetup in your field and learn about what problems other places are facing. You’ll learn so much from a shift in perspective. (Some companies set aside budgets for this if cost is a concern. Ask your manager.)

Reflect on your own experiences. Is an idea right in front of you?

What does your team complain about together? What’s harder than it has to be? Do you set aside time as a group to swap notes on what could be improved? All of my best project work has started with something that frustrated me personally first. Frustration can be a signal that something is important, so it’s usually worth spending some time inspecting.

One of the most helpful mindset shifts: your frustrations are your project ideas.

• I am so sick of these tests taking forever to pass! —> Propose a project to investigate and improve the speed and quality of the tests so that you can rely on them.
• I absolutely dread it when I have to touch this part of the codebase. —> Here’s how we should refactor this haunted graveyard.
• If I get this automated alert for a false alarm one more time, I’m going to scream. —> Review all of your alerts and decide if and how to tune them (or delete them).

When you’re keeping an eye out for all of these inputs, you’ll find pieces that start clicking together. You’ll hear about similar problems other teams have solved and start seeing how their methods (or a combination of them) could be applied to your problem.

One of my favorite book recommendations came from attending a local CoffeeOps meetup. Another engineer talked about the book Never Split the Difference by Chris Voss while I was struggling to get an agreement from an engineering manager about how my team would support their team. I realized then that I was actually in a negotiation, and I still credit the book for helping me push through the hardest parts of that conversation.

Another time, I remember sitting in an internal company conference watching a presentation by a senior woman engineer who worked on a major Google product. I mostly went to attend the talk because I was a little starstruck. When she presented, I realized her team had already solved a larger version of the problem that my team was facing. After the talk, I sent her slide deck to my team. Ultimately, someone on my team mapped how we could re-use her team’s solution. She got a big thank-you and my team saved a quarter’s worth of effort.

Spot: Connect the dots.

Taking in all of these inputs is only the first step. You have to intentionally carve out some deep thinking time for yourself to process it all. I really recommend creating a regular calendar block where you just draw on a dry erase board what you’ve learned recently.

There is often way more project work that we could do than what we have time and resources for. An important part of proposing projects: there is no singular “right” answer. Everything is about trade-offs. We’re trying to pick the kind of work that gives us the set of trade-offs that we’re most comfortable with.

What’s the same about your problem and what’s different?

How does this connect to your team’s goals, mission, and values? If you can’t explain how your work will help make progress to those things, then this might not be the right time for the proposal.

What else could we do about this?

There are usually multiple “good” approaches to a problem. In every proposal, make sure you’re looking at what else you could do. I’ve often seen an alternative solution become the official plan once discussion kicked off. Exploring alternatives lets your teammates know you did your homework, and they might even learn about a new tool or method this way. It also helps keep you focused on the problem you’re setting out to solve. When you send out a proposal, you should really be saying “Here’s what I found and out of these 4 ideas, I’m recommending this one and here’s why.”

Reason about what happens if you don’t do it.

Maybe a certain type of customer might have a poorer experience. Maybe you’ll violate some government regulations. Maybe you unlock a new revenue stream. Can this wait 6 months? Why or why not? What level of risk are you comfortable with?

If your company doesn’t already have a proposal template, ask for one! Design document templates can be a great way to seed starting questions. Often a little bit of structure is less intimidating to get started than a totally blank canvas. It doesn’t need to be that fancy: maybe a few section headers each with a couple guiding questions around it. I recommend keeping the first one lightweight so that you can get discussions going. It helps determine what should be in the project plan later; as people start asking questions, they reveal the parts about the project that are important to them.

You should be able to walk yourself through your proposal end-to-end first and you should also be able to connect how your work will tie back to better business outcomes. If you can’t do that yet, you need to spend more time researching and talking to others, or you need to go explore a different problem. Your dots aren’t fully connected yet.

As a quick example, shortly after I had joined a new team at a new company as a junior engineer, my team lead asked me to create a dashboard to understand the number of users our project was converting after the launch. He said I didn’t need a design doc; I should just whip up a dashboard. I spent all morning finding the data sources I needed and spinning up a small website. He was frustrated when it wasn’t done by the next day. I was dumbfounded, thinking I was making good progress. This was an expensive way to find out that I didn’t know we had a dashboarding tool called “Dashboards” that had access to the metrics I needed already; I just needed to configure it. When he said, “Steph, whip up a Dashboard for this,” it did not occur to him that the capital D was silent to me. If I had typed up my plan quickly, or if he had written it down, we both might have realized I had that knowledge gap. Once I was shown the tool, the whole thing took about an hour. He learned how to communicate better as a lead; I learned to ask better questions.

Run: Make it happen.

Once you can explain it to yourself, start writing it down. A strong proposal is one that you can effectively articulate to other people. I’ve coached a lot of engineers who viewed design documents as bureaucracy, only to find that once they started writing it down (because I made them) they learned a lot more about the problem in the process. Writing things down so you can explain it to others forces you to think through the nuances of a problem. It’s not just there for writing’s sake.

Determine who needs to sign-off on it.

At smaller companies, you might just need your manager’s thumbs up. For more ambitious projects, maybe you need to coordinate with other teams involved. In all situations, make sure they understand why this proposal advances their goals. If you don’t know who should see this, discussing who your stakeholders are can be a great first topic for your next 1:1 with your manager. Ask them who is likely to be worried and who is likely to be excited if you don’t know yourself.

What do you need to be successful?

A key part of any proposal is covering cost, resources, timelines, and risk. I’ve met engineers who worry that they’ll get these answers on, and I’m here to reassure them that they will. I once said something would take one quarter when it took five. (I said Q3, but not which year, so was I wrong? (Yes.) )

No one ever masters estimation, but you can improve. The human factors in a project can be tough, and most projects uncover surprises as they go. Give yourself extra time in the project to account for those things.

So how many people do you need, for how long, to deliver which specific outcomes? What’s the risk if we don’t do that work?

Some good guiding questions:

• If you had one more or one fewer people to help, how would that affect your timelines and what you could deliver?
• If you had 6 more months, could you do it with fewer people?
• How will you know if the project is a success?

Ask for feedback, with a deadline.

A nice side effect of writing things down is that people can re-read things as many times as they need in order to understand. They can ask you to rephrase or clarify something. They can ask questions and you can give yourself time to respond to the feedback, which is especially helpful if you’re nervous about seeing what other people think of your idea. Rather than having to react in the moment in a meeting, you can take some time to process what people have to say. You’re part of a team; this feedback is a discussion on making sure you’re working on the most important things in the most effective way.

Remember: everything is a trade-off. The goal is to make the idea better, not make it perfect. We could go in circles forever trying to find every flaw with an idea, but ultimately we have to make a call. Put a timebox on it: if people are dragging their feet and not reviewing your proposal, schedule a meeting to make a decision. Time is also a trade-off.

As a junior engineer, I once received feedback on a proposal 6 months after I sent it out, when it was already mostly implemented. There was a stakeholder who had missed the feedback deadline and forgot about it, until just before launch. Then he shared some opinions that needed to be taken into consideration. In this case, my team lead stepped in and resolved the concerns, but it turned what could have been a simple proactive conversation into a fire drill.

Make a decision.

Not doing the project is also a decision. It doesn’t mean your proposal was a waste of everyone’s time. Rejected proposals often force overdue difficult conversations, usually around prioritization.

Your project proposals will get stronger over time as you learn how to best write them up for your company’s culture. They’ll also teach your team what they value in a proposal and the questions that they would want answered in the future. The more  proposals you get rejected, the more you’ll learn about the team and the company’s priorities, and you can carry that with you into your next proposal.