> ## Content Index > Fetch the complete content index at: https://www.leadingwithempathy.blog/llms.txt > Use this file to discover other available public pages before exploring further. # Why You Can’t Rush a Development Team’s Growth - URL: https://www.leadingwithempathy.blog/why-you-cant-rush-a-team-that-needs-time-to-grow/ - Published: 2026-04-14T05:30:54.000Z - Updated: 2026-07-27T10:27:04.000Z - Description: Developers can produce more code under pressure, but that code often carries the evidence of the conditions in which it was written. - Author: Megan Tipps - Tags: Leadership, Engineering Leadership, Team Growth, Software Development, Developer Experience, Sustainable Leadership, Technical Leadership, EmpatheticLeadership, Team Culture, People Management, Developer Wellbeing You cannot rush a team into becoming something they are not ready to be, although that does not stop companies from trying. Deadlines are often set before developers are properly brought into the conversation. Expectations begin forming around what has already been promised rather than what the work actually requires. By the time the team gets close enough to ask meaningful questions, the date may already feel immovable. I have seen this happen across many teams and projects. The developers are rushed, they work late and everyone focuses on getting something over the line. The physical exhaustion is the most visible consequence, but it is not the only one. The codebase loses the refinement it would have had with more time. Edge cases are missed. Questions that might have exposed hidden complexity are never asked, and scope starts expanding while the team is already trying to catch up. Sometimes this pressure comes from people outside the development team. Sometimes, if I am honest, it has come from me. I once had to estimate an integration with a mobile provider. I based the estimate on their documentation and on what they told us about the work. With the information available at the time, the estimate was correct. The problem was that the information was not complete. As we began integrating, we discovered more and more things that had never been included in the documentation or the earlier conversations. Each discovery added work that nobody had planned for. The original timeline did not grow alongside that understanding, so the team had to absorb the difference. We worked late and still missed the deadline. That experience stayed with me because the estimate had not been careless. I had researched the work and asked questions. I had made a reasonable decision based on the information we had. It was still wrong. There is a temptation in those moments to respond by pushing harder. The deadline is approaching, people are waiting and changing the plan can feel like admitting failure. Working longer appears to be the most immediate way to close the gap. For a little while, it can even create the impression that the team is moving faster. What it does not create is more space to think. When developers are exhausted, the work becomes narrower. The focus shifts towards completing what is directly in front of them. There is less capacity to step back, question an assumption or notice the edge case that will matter later. The team may produce more code in the short term, but that code often carries the evidence of the conditions in which it was written. This is where urgency can begin slowing down the very progress it is supposed to create. Missed details return as bugs. Unasked questions return as scope changes. Decisions made quickly need to be revisited, and a deadline that was meant to keep everyone focused leaves the team with more work than they started with. Growth struggles under the same conditions. A team cannot develop confidence, judgement and ownership if every piece of work is treated as a race. Those qualities need enough room for people to think through what they are doing, ask questions and sometimes get something slightly wrong without the entire timeline collapsing around them. I saw a much smaller version of this during a junior developer’s first client demo. It was remote, and her camera was on. We had prepared beforehand, but once the demo began, I could see and hear that her nerves were taking over. She was speaking faster, rushing through the content and becoming increasingly stressed as she tried to get everything right. I sent her a private message telling her to slow down and take a breath. It was a small intervention. I did not take over the demo or interrupt her in front of the client. I simply reminded her that she had enough time to settle herself. After she saw the message, she relaxed and her pace changed. Afterwards, she told me that she was grateful I had sent it. The demo mattered, but so did her experience of getting through it herself. If I had stepped in and rescued her, the client might still have received the same information, but she would not have had the same opportunity to realise that she could do it. She did not need the pressure removed completely. She needed enough support to stay inside the challenge without being overwhelmed by it. That is the balance I keep trying to find as a leader. Healthy pressure can help someone stretch into work they have not done before. Harmful pressure asks them to stretch without giving them the time, clarity or support to succeed. From the outside, those situations can look very similar. Both may involve discomfort, uncertainty and work that feels difficult. The difference becomes clearer when you know the person. Over time, you begin to understand how someone approaches problems, what makes them withdraw and what helps them think. You learn when a person needs patience and when they need a more direct question. You also learn when additional time is helping someone grow and when the work is simply moving too slowly. There is no perfect formula for that. Leadership would certainly be more convenient if there were. It comes from paying attention, asking the right questions and understanding the person well enough to recognise what kind of support they need. I have watched people change when they are given that time and support. The difference appears in how they think about the work and in the questions they ask. They become less afraid of speaking up. They begin to challenge assumptions, take ownership and approach problems with more confidence. Those changes do not arrive because someone told them to grow faster. They emerge gradually through experience, trust and the opportunity to use their own judgement. This does not mean teams should be protected from every deadline or allowed to move without clear expectations. Patience is not the absence of accountability. A leader still needs to understand why work is taking longer, whether someone is learning and what is preventing progress. Sometimes the person needs more time. Sometimes they need clarity. Sometimes a difficult conversation is more useful than either. The mistake is assuming that pressure is always the answer. When a team is behind because the scope was never understood, pushing harder does not create understanding. When a junior developer is nervous during her first client demo, taking over does not create confidence. When somebody is still learning how to take ownership, demanding instant certainty does not speed up that development. Growth has its own pace. Leadership can support it, challenge it and create better conditions around it, but it cannot force the outcome before the person or the team is ready. Sometimes moving forward means asking for more effort. Sometimes it means adjusting the scope or admitting that the original estimate was based on information that turned out to be incomplete. And sometimes it is as small as noticing somebody rushing, sending them a quiet message and giving them a moment to breathe. The work still needs to get done. The question is whether we are creating a team that can keep doing it well, or exhausting them in our attempt to make growth happen on our schedule. [ ![Buy Me A Coffee](https://cdn.buymeacoffee.com/buttons/v2/default-yellow.png) ](https://buymeacoffee.com/leadingwithempathy?ref=leadingwithempathy.blog)