It sucks being on the critical path as normal developer, especially if you're late. When you're the senior developer, that the team is looking to for leadership, it's even worse.

When work for most of the team is stalled waiting on some critical piece what should the rest of the team do? We have limited access to the critical piece so others will simply be waiting no matter what we do. When the others are looking for advice on what to do what's a good answer?

  • 10
    Have you zero technical debt to pay down? Are there pieces of functionality planned for the future you could spike on? New technologies or paradigms you'd like to try out within the existing functionality? – jonrsharpe Mar 22 '17 at 4:38
  • 27
    @StudentT that's incredibly short sighted, given the likely difficulty in ramping the team back up once the blocker has been solved. – jonrsharpe Mar 22 '17 at 7:08
  • 8
    @StudentT rather the leader should be fired for not planning for the future, not anticipating things like this can happen. – jwenting Mar 22 '17 at 8:57
  • 13
    Starving devs? One word: pizza. – Mason Wheeler Mar 22 '17 at 9:26
  • 3
    If OP has zero technical debt to pay down and no unit/functional tests or deployment scripts to write/improve, he is definitely complaining from Deaven (Dev Heaven) and I'm suddenly very sad :< – xDaizu Mar 22 '17 at 9:28

Improve unit tests, functional tests, documentation, tools, etc. There's a plethora of things that can be done in down-time while waiting for the critical path to catch up.

  • 2
    This. The average dev (me included) constantly whines about a lack of time to refine things. Hold them to it. – Traubenfuchs Mar 22 '17 at 11:05
  • 4
    I like this general "do whatever you didn't get to yet". I'd add code reviews and refactoring to that. Make it a really neat piece of software that works like a well-oiled machine and is a pleasure to behold. That is satisfying for the developers. – Peter - Reinstate Monica Mar 22 '17 at 11:05
  • things that werent important enough to do before are probably still not worth doing now. its just 'make work' – Ewan Mar 24 '17 at 9:06

While I like the answer about improving tests, documentation, etc., and it is a good one you can also look at:

  • Assisting the critical path component, would it go quicker with team/buddy programming?
  • Restructuring the critical component into several sub-components that everybody can work on.
  • Dummy out the critical component with something, possibly rough, that does basically the same job but possibly not fast enough for production.
  • Establish an API for the critical component, fix that more or less in stone, and help to get the basic functionality for that component implemented, (subject to changes in implementation but not API).
  • See if you can take early, known problematic, versions of the critical component to work on the remainder of the system where the functionality is "good enough for now".

It is also a good idea to start the "lessons learnt" phase now by recording that such critical components need to be started earlier in the development process, possibly before the rest of the team is assembled.

  • 2
    I like the alternative of "there is always something to improve". If they're good enough, it's better to focus on the current problem and find a proper workaround. – Walfrat Mar 22 '17 at 8:32

You need a backup plan for your late deliverable

If a critical piece is already late, there's no guarantee it won't slip even more. What then? You just wait forever? That is not the kind of answer you want to have to tell to upper management.

Build a simulator

One way to manage the risk is to start work on a simulator (harness, shim, stub, whatever you want to call it) to take the place of the missing critical piece.

Does it have a defined interface? Implement it.

Does it have detailed documentation? Imitate it as best as you can.

Is it just someone's idea? See if you can get a prototype.

Then, when they slip schedule again....

That way, when they slip schedule again, you have an ace in your back pocket to close the gap. Not only will your team be unblocked (they can integrate with the simulator), but you will gain a valuable software asset.

If they slip schedule even more, use the time to write automated integration tests (against your simulator, for now). That way, when they deliver the real thing, you can just run your tests and detect any behavioral differences between the mockup and the deliverable. This will let you zero in on spots that you have to revise. As a bonus, you will quickly get an idea of how much they cut corners as their time ran out.

  • The simulator does not need to be complete or fantastic, just enough to allow you to make progress. – Thorbjørn Ravn Andersen Mar 22 '17 at 9:45
  • 1
    I think this is very sound and not immediately obvious advice. Especially the perspective beyond coding, namely tests. The mock is double value. – Peter - Reinstate Monica Mar 22 '17 at 11:03

If the critical component has a known interface and if there is no hope of getting it done in a short time, why not build a test double (for example a mock)?

This would allow the team to carry on coding, although the test results would be slightly less meaningful.


Apart from the obvious "do all those things you did not get around to doing thus far", it sounds like you and your team lack the peace of mind to do anything unrelated to the late project. Which is understandable but not helpful.

So the real problem may be to be relaxed about it. I am not saying indifferent. Be concious of your responsibility, of what you can do to help and if that leaves you with time on your hands, enjoy it. You cannot nor have to be on your toes all the time. If you are a leader, I would say this should be your message. Transfering your nervousness to the team will not make a more productive team when it matters.


You don't say what methodology you're using which makes it tricky to advise exactly.

Where I work if there is a blocker, it is every hand to the pump doing whatever they can to expedite the development.

Consider if there might be a wider problem with you as the lead taking on too much. Yes, people will be looking to you for technical leadership but that doesn't mean some of your more able team members can't share the workload if they're mentored.

Aside from this, is there any other non-critical work they can get ahead on? Also, is there any work they've completed that could be further polished (refactored, removing technical debt, documentation, adding tests etc).

If there really isn't anything, give them something - go thru logs, builds, documents, test plans, designs, diagrams, write agendas, arrange meetings, hold brown bag sessions, share knowledge etc. There is always something to do. If people are willingly just sat around doing nothing on the company coin that should be escalated as they're clearly not team players.

Not the answer you're looking for? Browse other questions tagged or ask your own question.