I was recently reflecting with a good friend on a skillset that is just as valuable for me in industry as it is just as valuable in her work in academia. Our ability to iterate quickly has allowed us to leapfrog problems and make the most of our time, both when developing products and developing theses. Being able to iterate quickly is a skill that is best learned as quickly as possible, and something worth working on with new and relatively-inexperienced hires.

Iterating quickly requires personal discipline to know when a strategy of accomplishing a goal is not working out, and then quickly pivoting to the next best decision. “Knowing” that something is failing is more of an art than a science, but by setting deadlines and goals upfront, you relieve yourself of the decision-making burden in the moment. Managers need to adhere to these standards, and then promote those same standards in their teams. I’ve found that with managing more-inexperienced reports, they will often not set hard goals upfront, shy away from asking for feedback and slowly start slipping on deadlines. Iterating quickly is a learned skill, and something you can teach through good management.

For example, I was managing a product manager who was developing a pitch deck for a new project. They were ready to take the job and run with it, and present it in a week at a larger meeting. This made me nervous for a few reasons.

First, we needed to slow down and share context of the final goal. Where was the output of their work going? Who would see it, and how would the information be used? Our goal was to help another person make an educated decision about investment.

Next, we talked about the deliverable. Saying, “I need a draft of this deck” is imprecise, especially if the two people haven’t worked together before. We went over what the draft deliverable would contain and what it would look like, and what the final deliverable would contain and what it would like.

Lastly, we talked about the delivery date. My report was initially surprised I wanted to see a high fidelity deliverable far before the meeting; we decided the established meeting time would not give them enough time to prepare, so we chose a new final meeting time.

I think it’s so important to schedule feedback sessions with your reports. Ideally, your reports are establishing feedback sessions with you, but inexperienced reports often will not do this at a high enough frequency. For example, I once took a class with a professor who offered feedback at any time, we as students would just have to schedule it. Hardly anyone scheduled time with her.

There is an argument to let your reports fail and learn on their own. In this case, if you aren’t scheduling feedback time with your reports, when they inevitably fail, it’s important to underscore where they went wrong: the slide deck or product requirements document needed improvement, but ultimately their process needs improvement.