1001: Managing Deadlines + Stress  🔗 **Source:** [1001: Managing Deadlines + Stress](https://share.snipd.com/episode/9a07c917-39b7-495b-ad27-3bf3c07a5c05) ## Highlights - **Slow Down And Put Tasks Into A System** - Slow down and take stock before rushing to code. - Scott recommends moving tasks out of your head into a system (Notion/Linear/to-do) to surface blockers and exact work items. Transcript: Scott Tolinski I think the hardest and most beneficial thing you could possibly do in a scenario where you are stressed to the gills about a deadline is to slow down and take a step back, which I hate that. I hate that advice. I hate that when I'm stressed out about stuff and Courtney's like, did you do your to-do list and break it? I was like, no, just trying to get it done but I know that's gonna be helpful yeah no time to plan and slow down and it's it's the right call every time it's just like when they say deep breathing Is the best thing for you and you're just like I don't want to deep breathe let me deep breathe it always works folks the stuff that always works is always no fun to do. But yeah, slow down. I think the biggest thing you can do here is take stock of what actually needs to get or what's actually done currently and what's not. Anytime I end up having a deadline, that's one of the first things I do is I like go through where are we at today? Like what exists and just get a real good handle on exactly what the lay of the land is. Take a step back. Here's what exists. Wes Bos And that could be using something like linear or some sort of issue tracking system, some Kanban board. It could be simply just like writing it down in a Notion document that says, this is what we've done. This is what we need to get done. ([Time 0:05:22](https://share.snipd.com/snip/300d55df-d039-4d73-93ba-7b92bdd2385b)) - **Break Work Into Tasks And Surface Blockers Early** - Break the project into detailed tasks and surface questions early. - Wes advises listing blockers like legal approvals or API access so you can request those before they derail the schedule. Transcript: Wes Bos Have one thing that says here is uncover questions you might have about the spec or needs. And this is a big one for me as well, because when you get talking about it, when you start trying to write things down, that's when the questions start popping up like, oh, how are we going To do X, Y, and Z? How is this feature going to work? How do these things relate to each other? How is the integration working? Who is going to be deploying this thing? There's all these little pieces that you may not have considered, but when you start putting them into a system, then you start to surface them. Scott Tolinski Yeah, even that planning. I remember when I worked at Ford, we needed to get legal approval before installing anything. And I remember we were up late on a weekend trying to knock out a project. And it was like, Oh, we need this library, but we can't get legals approval for it. And everything's due on Monday. But we didn't plan well enough. So we don't have legals approval. And we can't have this done by Monday. So we're just gonna have to rewrite the library basically ourselves or hack something together in time, we didn't plan well enough to know that that was something that we would need. And if you were to sit down ahead of time and be like, here's the plan, we're doing this, this, this, this, this, you might say, okay, here's the library needs that we have. Let's get legal approval or even like API access. ([Time 0:08:01](https://share.snipd.com/snip/23595a3b-7a40-4a95-8175-89b534254b62)) - **Ford Legal Approval Blocked A Weekend Launch** - Scott recalls needing legal approval at Ford which blocked a required library and forced a weekend rewrite. - That missed dependency planning meant they couldn't deliver on Monday and had to hack a replacement. Transcript: Scott Tolinski Yeah, even that planning. I remember when I worked at Ford, we needed to get legal approval before installing anything. And I remember we were up late on a weekend trying to knock out a project. And it was like, Oh, we need this library, but we can't get legals approval for it. And everything's due on Monday. But we didn't plan well enough. So we don't have legals approval. And we can't have this done by Monday. So we're just gonna have to rewrite the library basically ourselves or hack something together in time, we didn't plan well enough to know that that was something that we would need. And if you were to sit down ahead of time and be like, here's the plan, we're doing this, this, this, this, this, you might say, okay, here's the library needs that we have. Let's get legal approval or even like API access. Like, can you imagine if you're, again, especially like if you're working on the weekend or something to knock these things out and you don't have access to the one thing that you need To solve a problem. ([Time 0:08:35](https://share.snipd.com/snip/f664bfca-b825-45f7-96c0-06d7190768fc)) - **Cut Features To Hit Hard Deadlines** - Cut nonessential features to meet hard deadlines. - Wes notes OpenAI released an unpolished SDK by cutting most features so they could announce before competitors and add polish later. Transcript: Scott Tolinski I think part of this too, you also have figure out what can be cut in here. And that's something I think that's important too, because it depends on how hard this deadline is, right? Wes Bos Yeah. You have all these grand ideas of absolutely everything you'd like to have in every single feature you'd like to implement. But when it comes down to, is this worth my time? Like, is 1% of the users actually going to be using this feature? That's going to push us back? Simply what can be cut? I think we talk about all these big AI companies shipping so fast right now. If you really look into a lot of these projects, you're realizing the reason they are shipping so quickly is because it is it's not very polished. And a lot of the features have been been totally cut. Right. Like I remember when OpenAI launched their like apps SDK, which was like their like MCP thing. It was everyone's like, oh, wow, they released an SDK and everybody's talking about it. And I was actually using it. And I was like, this is not very done. They cut a lot of stuff. And that was simply just so they could announce the thing and say that they're coming out there before some other LM company announces their own apps SDK. They needed to get something out in time because there was a tight deadline. And they figured out what can be cut, which was most of it. ([Time 0:13:03](https://share.snipd.com/snip/3a9abda7-aeab-4d6a-8ef8-c895b1012acb)) - **Protect Quality With Blocking Tests And Lints** - Keep your standards and automated checks in place during crunch. - Scott recommends linting/tests that block merges so shortcuts don't create technical debt you'll later have to fix. Transcript: Scott Tolinski It forces me to finish something every single week. So next thing here is to get to work, you have your plan, you have everything you need, you've uncovered any type of blocker or question that could possibly come up. Now you can get to work, which is the thing that a lot of people just start with. I think the important things here are to not let your standards slip. I think something that we've all encountered is a situation where we've taken a shortcut and that shortcut has come back to bite us and we have to spend time then undoing that shortcut. I feel like there are some shortcuts that are calculated risks that do pay off. Yeah. But there are times when we take these shortcuts later you're just like i should have just done it right the first time i should have just authored this by hand etc or whatever i it's so Wes Bos This is happening a lot more because it's so easy to just boop boop boop type in the box claude ships it and then before you know it you've just like why did i do that or even just like why did A lot of my open source stuff i'm like why did i merge this you know at the time i was like that's sweet yeah merge and then i'm just like ah now i have this big burden that i need to maintain Scott Tolinski And yeah i've done it yeah so have those standards in place It's even better if your system that you have with your team, whether that's, you know, your linting and tests and whatever, It's even easier if those things are blocking your follies for you. If you can sidestep some of those systems or whatever, you can let your standards slip. But if you can't get something merged until you end up fulfilling requirements, no any, no casting, whatever you end up doing, then. ([Time 0:16:39](https://share.snipd.com/snip/ec33c9b7-114e-48be-8b71-13a74dd6b313)) - **Balance Process Versus Velocity** - Too much process can also block shipping. - Wes warns heavy gating (slow tests, flaky tooling) kills momentum, so balance safeguards with developer velocity. Transcript: Wes Bos I don't know i don't know if i i totally agree with that as well because like at some points i think it's fine to to let those things go especially because like if you have too much process That's blocking you from actually shipping anything or doing anything then it just becomes like you just you have you foster this place where nobody actually moves quickly because You have just like too much like oh i i don't want to do x y and z because now it's going to take me 100 years to just even get this thing running in local dev or or just like ah like the tests are Flaky and failing, you know, and that's probably more a look on your actual, your tooling as well. Scott Tolinski Your system. Yeah. One thing again is to update your tools and issues as you go and communicate clearly. ([Time 0:18:47](https://share.snipd.com/snip/6c9c49e2-ab6c-4ea5-ba4c-753c75d3a457)) - **Log Changes And Keep Issues Updated** - Update tools and issues continuously so stakeholders can monitor progress. - Scott suggests changelogs and conventional commit messages to hand to PMs and reduce status queries. Transcript: Scott Tolinski It's even better if your people who are monitoring your progress on this can monitor those things as well. So that way they're not having to bother you. Where's this at? What's going on? And it depends on what the deadline is. Is the deadline, you know, 12 hours from now? Is the deadline two weeks from now? I think communicating early and often is always going to be better, but communicating clearly. I really like having even like for projects like this, I like making change logs. I know that's not exactly a rare practice, but I like having change logs that I could just give to a project manager to say, here's the updates as they're coming in. And that's commit names, conventional commits or otherwise. It's true. Wes Bos And even for yourself, like updating your to do's, checking them off, that gives you those small wins make huge momentum. And then you're like, you're unstoppable. Like when we were cranking on the Sinhacks platform and all the mad CSS stuff, it was just like, we just had such a good flow of like, bam, log the issue. When something happens, log the issue. Somebody takes it. Somebody fixes it, pushes it. You know, just like sometimes some of these things were just so small that it would be like five, 10 minutes in between pull requests. ([Time 0:19:37](https://share.snipd.com/snip/6e3920cc-518a-4fbd-b1bd-f630815bcaa4)) - **Request Help With Specific Issues To Delegate** - Ask for help with clear, assignable tasks rather than vague requests. - Scott recommends assigning GitHub issues and asking teammates to complete specific items to avoid onboarding debates. Transcript: Scott Tolinski Yeah. Sometimes you have to ask for help. I don't know how many projects you've been in West, but I've been in many projects where it's very clear that maybe not many, but I've been in enough projects where it's very clear that Like, there's just not enough manpower in these two hands to get this thing done. So I've had to enlist the help of others. I've had others enlist the help of me. I remember one time we had, I'll keep referencing stuff at Ford because this seemed like something that happened there a lot, but somebody was let go from our team and there's three developers. This was actually very scary. We in a meeting with ford executives and we each had three projects to work on each of us had one and the guy who went first presented the first day and they tore his down so badly that he got Let go that day and then uh the next guy was presenting the next day and then me uh and uh next guy and I, his name is Jeff. He and I were just like, because if it would have been either of us going first, we probably would have gotten canned too. Because I think the expectations weren't made clear what they were actually looking for. And so Jeff and I spent all night cranking this thing out, just all night, and got it done and killed it. And likewise, he helped me, and we just made sure we executed. And we kept that job for a while. But sometimes you've got to ask for help. It's just straight up. Sometimes asking for help can slow you down. If you have to onboard somebody, got to get all you know set up with whatever the databases or keys or whatever like are you going to teach them the system questioning everything you know Wes Bos Why are we not doing it this way uh yeah please i in some cases i guess that's that's fine like it's good to talk through choices but many other cases just like please we're trying to get This done we not here to debate like validation libraries. It depends on the timeline, too, right? Scott Tolinski If that timeline is 24 hours or something that's different than like a month. But even then, yes, we're not here to debate. Yeah. Hey, can I get a handle on the hand on this? Whatever. I think a big thing is like knowing when that's going to help you and when that's going to hurt you is something that only you can know the dynamics of your team, everybody else's workload, What you have to do, what you need to accomplish. But I think the clearest thing is asking for help in a way that it clearly communicates what you need. I think clear communication is a big topic here. But it's like, hey, I'm not going to get this thing done. I really need help. Is there any hours you can help to knock out the following features? If I assign you these GitHub issues, can you do them? To me, that is so much more powerful than, hey, can you get a hand? Can you hand on this? Yeah. And just help me code it. Like assign them issues, project manage a little bit, whatever. Do these following things. ([Time 0:22:34](https://share.snipd.com/snip/e216a1cb-4860-436e-9ce3-54ef8917dec9)) - **All Night Push Saved Jobs During Executive Reviews** - Scott recounts a Ford incident where two teammates and he worked all night to survive executive reviews after a colleague was fired. - He and Jeff cranked through the night, presented successfully, and kept their jobs. Transcript: Scott Tolinski So I've had to enlist the help of others. I've had others enlist the help of me. I remember one time we had, I'll keep referencing stuff at Ford because this seemed like something that happened there a lot, but somebody was let go from our team and there's three developers. This was actually very scary. We in a meeting with ford executives and we each had three projects to work on each of us had one and the guy who went first presented the first day and they tore his down so badly that he got Let go that day and then uh the next guy was presenting the next day and then me uh and uh next guy and I, his name is Jeff. He and I were just like, because if it would have been either of us going first, we probably would have gotten canned too. Because I think the expectations weren't made clear what they were actually looking for. And so Jeff and I spent all night cranking this thing out, just all night, and got it done and killed it. And likewise, he helped me, and we just made sure we executed. And we kept that job for a while. But sometimes you've got to ask for help. It's just straight up. ([Time 0:22:50](https://share.snipd.com/snip/deacbae7-8f4f-402d-9118-f259e3bd20be)) - **Stop Crunch By Communicating Needs To Management** - Prevent recurring crunch by communicating needs and process issues to management. - Scott advises calmly explaining what resources or process changes you need and proposing specific improvements for future projects. Transcript: Wes Bos Prevention of what? What are you talking about here? Scott Tolinski Prevention of crunch time. Because a lot of this stuff with deadlines is almost always like the stress around it isn't from having a deadline or from having something get done. It's feeling like you don't have enough time to get the thing done or you don't have enough capability to get the thing done in time right yeah quite honestly this is sometimes just like Wes Bos A person problem you know like i some of my kids they have homework and they just leave it to the last day before and they're all stressed out about it and it's like we had a whole week like Whenever i did projects in school i always tried to have it done one day before it was actually due. So you have that one buffer day in case anything goes wrong. And then I have all these friends that were like up at like four in the morning before it was due at eight, just stressing out about it. It's like, just move your entire life 12 hours ahead and you might be a little bit better off. Scott Tolinski Yeah, I think so this is there's two parts of this, right? There's as a manager, how do you make sure that people do that? But then there's also as the person who's under crunch time, is it something that you can improve your process on start earlier, plan better and have a clearer idea of what needs to get Done so that way you're not scrambling at the last minute. That's number one. But let's say I've been in enough situations where especially in the agency world, the design, the developer is the last person at the end of the train. So let's say in January, they declare that the project is going to be finished in March. Okay, and that design will be finished by the end of January, and then development can take from February to the end of March, right? Well, design ended up going through several more revisions. And next thing you know, you don't even get to start development until March. And now you got like half the time you were supposed to have to build the thing. So sometimes that process is unfair to the developer, especially if that is the last process in the chain here. So I think it is important to clearly communicate what you need with management in a way that isn't like angry, or going to put people in a defensive position. But it's important to be honest and clear with your communication, especially if you're able to have those types of conversations, which honestly, I feel like that is something that You should be able to establish. I don't know. Developers are hard with this sometimes with communication. But you could say things like, hey, I'd really prefer in the future if we had solid deadlines for X. So that way I'm not getting crunched at the end. OK, or to be cognizant of that right or a a better process in integration or collaboration would help me work faster with smoother results can we can we talk about like what that is right Can we improve our process in these ways so the next time i'm not getting hit or, hey, if it's really bad, the last 10 projects have really ended in kind of chaos for me. Is there any way we can work together to prevent that from happening? I mean, we all have the same, you know, whether it's management or you, you all have the same goals to get this done smoothly. And if it's not smooth, like that's usually a fault of management, but you can help them with that by clearly communicating what you need. ([Time 0:25:46](https://share.snipd.com/snip/d73ec48d-01a6-46d5-8e5f-3a3007d525f8)) - **Developer Involvement Earlier Reduces Last Minute Crunch** - Developers are getting involved earlier which can reduce end-of-line crunch. - Wes notes devs now help plan and design in parallel, moving teams away from rigid waterfall handoffs. Transcript: Wes Bos I think as this maybe is a good thing with all this AI stuff right now where the dev is moving a little bit more up the chain into the planning stages of the project. And maybe the design is happening in parallel. And that moves things along a bit quicker. Because it previously used to be like you have a project manager and they figure out what they want and then you just waterfall it all the way down. And at the end of the day, the poor developer gets crunched, right? Like i feel like the developer is is involved much earlier on these days and in fact may even be the person that's figuring it out at the in the first place yeah yeah and along with that i Scott Tolinski Think you can also set yourself up for success a little bit more to have time saving tricks here and there like starter kits or various like, you know, decisions that you make that are Automatic that like can lead to better results if you're you're moving faster. Granted, these are all things that vary greatly from team to team work job to job. So like, this is not blanket advice for everybody. ([Time 0:29:12](https://share.snipd.com/snip/569d4d31-a82c-4ccb-ae01-5d8cb2a1e194)) - **Create Starter Kits To Save Time Under Pressure** - Build starter kits and time-saving conventions to accelerate future work. - Scott suggests automating common decisions and tooling so urgent projects reuse proven setups instead of starting from scratch. Transcript: Scott Tolinski Granted, these are all things that vary greatly from team to team work job to job. So like, this is not blanket advice for everybody. But I think the number one piece of advice in this regard is that communicate clearly what you need because people just don't know. You can assume that people know what you need or don't need or think about or whatever, or you could assume that your boss isn't going to listen to you anyways. But I think it's important to be very clear with what you need. ([Time 0:30:14](https://share.snipd.com/snip/5d2a31f3-aa25-4e8a-b0a1-0eb4c9769739))