I'm on a development team with a total of five developers. The owner of my company quite often tells all of us to drop everything we're doing and focus on one singular task. The problem with that is that a lot of the tasks he wants us all to work on do not lend themselves to concurrent development.

My question is... how can I get the owner to stop doing this?

A few thoughts:

  1. If everyone is trying to collaborate on the same exact problem there could very well wind up being "too many cooks in the kitchen". The book The Mythical Man-Month elaborates on this further.
  2. It has a chilling effect on after hours contributions. When the owner isn't like this I'll usually work on tasks that interest me in the evening or on the weekends. But when the owner gets like this I don't work on anything other than what the owner wants me to work on. So instead of getting 60h out of me he winds up getting exactly 40h and that's it. I suppose that's not really my problem but if I owned a company I'd want to encourage people to do this - not discourage it.
  3. The owners wishes that we all assist notwithstanding the reality is that not everyone is going to be able to make meaningful contributions so what are such people supposed to do in the meantime? Just twiddle their thumbs and hope that the owner doesn't come around and ask them for the specifics of what they're working on? Working on other stuff is liable to get you in trouble when you've been told explicitly not to work on other stuff so that doesn't seem like a viable solution.

I suppose I could send the owner an email with the concerns I've mentioned above (are there other problems I'm not thinking of with this "all hands on deck" approach?) but who knows how he'd respond to that. Maybe a more passive aggressive way to deal with the situation is to get him "The Mythical Man-Month" as present for Christmas. Initially, he might see it as brown nosing and, who knows, he might not ever read the book, but I guess that's the risk you take when you act in a passive aggressive manner..

Any ideas?

  • 29
    What kind of issues does he call this "all hands" approach for? Are they critical production failures that should be fixed within minutes, or regular new feature development that could take hours or days?
    – Erik
    May 24, 2018 at 7:11
  • 37
    @Erik - they're actually often completely bogus issues. Most recently it was because he claimed that a menu in a system we rewrote was lacking all of the options that the original system had. I didn't have anything to do with the development of the menu but the two developers who did insist that that's just not true. And the owner has yet, to my knowledge, failed to provide us with an example of an item that's missing from this new menu. He's just been like "menu items are missing. This needs to be our only focus until its permanently fixed"
    – neubert
    May 24, 2018 at 11:52
  • Are you already doing pair programming? That is one useful way to not divide work into more independent threads but to effectively use more developers. There is some argument about whether pair programming is the most cost-effective development practice but it is one good way to get all hands on deck. May 28, 2018 at 5:15
  • @EdPlunkett at risk of being off topic here: many of TMMM's notions regarding architecting, project planning, documentation, office space, etc. is regarded parochial in the brave new Agile, informal, collaborative, open plan workplace - and some become more relevant than ever... (Whether I agree with such evaluation or not, is besides the point - what matters is if reading the book can be "sold" to management given their own special set of prejudices.)
    – frIT
    May 28, 2018 at 6:48
  • 10
    I'm astonished no-one has commented on this... You're working up to 20 hours per week essentially for free??
    – fgysin
    May 29, 2018 at 9:01

10 Answers 10


Stop this madness before it starts.

When your boss has an urgent issue that needs addressing "by everyone", call a meeting.

Discuss the issue rationally, work out what needs doing, work out the resources you need to make it happen, and put that plan into action.

Quit panicking, start planning. Get it done right, by the right amount of people.

Feel free to include your boss in the meeting and demonstrate that "all hands on deck" isn't appropriate all of the time - you need "the right hands on deck".

You then end up with a united team working on the problem in the most optimal/efficient manner. Anyone who doesn't need to be working on a task that's already fully (and efficiently) resourced can work on something else (ideally preparing for a later task (or shock/horror, creating/completing a test plan)). Either way, if the boss lands on someone's desk and demands why they're not feverishly hammering code into Visual Studio, they'll have the appropriate answer.

Sometimes, you might need everyone to work on an issue, but because you've planned things, everyone knows what they're doing, why, and when.

When the panic is over and the problem is resolved, try to work out what happened that caused the panic situation in the first place and put a process in place to mitigate future panics. The chances are that you discover the root cause during your initial investigations, but a post-mortem process demonstrates a proactive approach to issue avoidance.

  • 6
    That´s a good approach. Stop being part of the Problem, be part of the solution! Depending on setup you might want to get your boss in on this first though. Some owners react poorly if you take to much freedom while interpreting their orders ...
    – Daniel
    May 24, 2018 at 8:08
  • 6
    Plus, for all you know, it could be that the owner calls this because they aren't sure the path forward and are hoping someone puts a plan together but since no one does, feels obligated to keep calling the meetings.
    – enderland
    May 24, 2018 at 12:36
  • 42
    Good answer. Often an "all hands on deck" request from a manager just means they want to know that everything possible is being done to quickly fix an issue. By communicating a clear plan, you give them the re-assurance they need it's under control. May 24, 2018 at 12:50
  • 37
    This essentially means putting yourself into the role of a team lead, which you are not, if I understood you correctly. Be aware that your boss and your colleagues might not appreciate your initiative and instead see you as someone who is overstepping his/her responsibilities. May 24, 2018 at 14:00
  • 22
    @dasdingonesin: Or they'll appreciate that someone finally stepped up and took some initiative, and eventually formalise your new role with a nice payrise to boot. May 24, 2018 at 19:31

Back him. And be seen to be doing so.

Never talk it down in public and be seen to not do so.

Sounds like your boss is afraid. So make him unafraid.

I'm a developer of over 20 years. I've been a manager of large teams and small, (and in between). I've put my own money into projects and I can tell the feeling. It goes like this.

  • I'm busy and (maybe even) close to broke and I'm stressed out of my mind
  • I don't know exactly what my team do for me, if they leave i'm stuffed
  • I have customers/users saying stuff and I have to talk bulls**t on my feet and I hate it
  • My team feels like they're slipping away from me

EDIT: Including the quote from an ancillary OP comment

Most recently it was because he claimed that a menu in a system we rewrote was lacking all of the options that the original system had. I didn't have anything to do with the development of the menu but the two developers who did insist that that's just not true. And the owner has yet, to my knowledge, failed to provide us with an example of an item that's missing from this new menu. He's just been like "menu items are missing.

EG: the menu that things went missing from. It is entirely possible the menu IS CORRECT from a developers point of view "technically" usable but it is ALSO entirely possible the plenty of users have MISUNDERSTOOD and HATED why a REALLY USEFUL intuitive feature of the original UI menu was thrown out. It happened with Windows 8. It can happen to you. Too much focus on reactive content or UI interoperability/touchscreen/keyboard (EG: skipping past with key presses, auto expanding, showing clearly where auto expansion can happen) very often developers are in such a rush to get a "look" or a "feature" they forget that these things are used by humans.

And don't think that this sort of thing I mention about is trivial to users. They very often hate "new features" that break one thing they relied on.

The way to stop your boss being in a panic all the time is to give him back confidence. Support him no matter what. Do not have meetings that suppliant his authority. Speak well of him. Let him get things wrong, let him know one to one. Back him anyway. Let him feel you have his back and tell him what a good job he does. I think it's good you've come online to talk about this stuff, because doing it in an office can be the worst thing to do.

I say all this because, in the end, you are the only thing you can control. And if you follow my advice (and practice it!) the worst that can happen is you become such an incredible employee you will be unimaginably valuable throughout your career. The best that can happen is that you change your bosses mind about panicking.

  • 3
    If you're going to challenge the frame of the question, a good place to start is to directly answer the question. Then, once you're done answering the question, talk about how the question is (misinformed/not useful/not seeing the big picture/on fire), and then give your "corrected" question and the right answer to that question. May 24, 2018 at 16:18
  • 1
    @MrHeelis, I like your answer in principle (the "EG" paragraph it is a bit hard to read). Just to address your comment about "minus one"... I would suggest not to worry about that. StackExchange is a voting place, and votes do not always agree with you. People may not only downvote because they think yours is a bad idea; maybe they take other offense. It's nice if the downvoters comment, but it's not necessary. I'd suggest just to ignore the first few votes anyways (you have +1 -1 = 0 now, which is "nothing", only two people). Come back later when you got some comments by the downvoters...
    – AnoE
    May 24, 2018 at 16:27
  • 4
    ... and then it's always a good idea to have an open mind about what they actually commented. Finally; in such cases, I usually simply write a short comment like "would appreciate a comment from the downvoters" instead of ranting - it shows that you are open to it.
    – AnoE
    May 24, 2018 at 16:29
  • 13
    The problem with this answer is that while it might be sound advice, it's not actually an answer to the specific question. A long-term strategy for ingratiating yourself with the boss may be good for your career, but it doesn't address the fundamental problem, which is how to inform the boss that his approach is actually harmful. The question wasn't "how to stop the boss from panicking."
    – barbecue
    May 24, 2018 at 18:25
  • 1
    Good answer, but I think you might consider losing the entire "EG" paragraph. I have no idea where this missing menu item issue is coming from or what you're talking about there; it looks like you're trying to justify your answer with some context, I just don't see the connection. But everything else around it is superb advice.
    – Cypher
    May 24, 2018 at 19:50

As a general rule, owners don't change. If the good things about the job don't make up for this then you have to leave.

If you do stay, one approach which has worked for me with such an owner is to ignore him. Do what you think is best. This only works if you actually know what's best and you can show him results faster than he can find out what you are doing and get annoyed. This works especially well for owners with short attention spans. This doesn't work well when the owner knows the details of what you are working on all the time because then you don't have the time to get to a result you can show.

If you do leave, come up with a nice white lie for why you are leaving. He will be even less receptive to what you have to tell him when you quit.

  • 32
    Why lie about leaving? You don't owe any explanation beyond "someone is offering me a position that I want to take." Offering reasons for leaving just invites the owner to refute them and drag the conversation out.
    – alroc
    May 24, 2018 at 11:31
  • 6
    This answer does not seem to address the question at all. The OP asks neither about leaving nor how to handle the situation at all, but about how to tell the boss.
    – AnoE
    May 24, 2018 at 16:20
  • 12
    @AnoE You are correct, I didn't literally answer the question because it doesn't have useful answer. The one line answer to the question "how do you tell the boss?" is "you can't tell the boss". I advised the questioner on what to do in this situation.
    – user86764
    May 24, 2018 at 16:27
  • 10
    And sometimes "get out" is a valid answer. May 24, 2018 at 17:17
  • 1
    Yeah unfortunately software engineers are often not the ones responsible for tech decisions. This is exactly why I left the last two companies I worked for. Managers know best!
    – aaaaaa
    May 25, 2018 at 15:32

My suggestion is somewhat different than the one by Snow: meet the owner 1:1 at the time when there is no crisis. Going out for a lunch or coffee with him can be a good idea. Then, tell him pretty much what you wrote here and try to make it as non-personal and non-accusatory as possible: make the owner understand that "all hands" calls are bad for business.

Hopefully, the owner is a reasonable person and will understand your point. Otherwise, it's time to look for another job.

  • 14
    Depending on where you live this can be hazardous to your career.
    – kevin
    May 24, 2018 at 12:54
  • 2
    @kevin: I agree it is culture-dependent, but most business owners will appreciate seeing that their employees genuinely care for the business. May 24, 2018 at 13:03
  • 2
    @Nemanja Not only is it culture dependent, it depends on your relationship to your boss. This isn't a "starter" conversation.
    – RandomUs1r
    May 24, 2018 at 18:15
  • +1, but this can only work if you truly believe your boss is overall reasonable and just doesn't realize the impact of what he's doing.
    – Kevin
    May 24, 2018 at 20:43
  • 2
    This advice is spot on. Meeting 1-1 when the boss isn't stressed is the best and most effective way to share your opinions, not in front of others and not during the crisis (if possible). If you can't speak honestly to your boss, you should look for a better job. Good bosses want honest feedback. May 25, 2018 at 2:06

The short answer to this is that you need some sort of more formal Product Management function in your shop.

The main purpose of this function is to define, understand and maintain a prioritized backlog of work for the execution team. This allows the execution team to continuously review the work in front of them and to make good decisions on generally how to handle things, who and how many people to put on a given work area, and other aspects to maintain steady production without too many context switches and such.

Second, it is helpful to have someone in a project management type of role doing those things above for the execution team. Ideally it's not the same person doing the Product Management part, so that you can separate conflicts of interest around perceived urgency verses longer term team efficiency.

In a small company, these do not have to be dedicated people in each role. What is needed is a clear understanding of who provides what to the flow and when. For instance, your boss in this case sounds like the clear owner of the Product and would be heading the Product Management function. Whether he does most of the work himself, or delegates the detail work and just provides oversight and prioritization, is something you all would need to work out based on your unique situation as a company. Another person, typically one of the more senior and/or more organized developers, can take on the role of project manager. That person would spend part of their time dealing with the incoming work and ensuring that it is properly allocated, that thrashing does not ensue, and that there's communication back to the Product function around what the cost impacts are of too much re-prioritization.

I tried to state these things as generically as possible without specifying a methodology. Obviously there are flavors of Agile, good old fashioned Waterfall, and a slew of lesser known approaches to give you tried and true guidelines on how to work within one of these. From what you described, with frequent urgent and short term changes of direction, going with a simple version of Scrum would be a good starting point. From there you can evaluate how well it is working and evolve it to fit your company's needs. If you don't have anyone on board with at least some amount of Scrum experience to act as a coach, then that's a separate problem that probably has many good questions and answers around here already.


If there's no command structure between you and the owner, there really needs to be.

You need someone to manage the developers, and that is the person who the owner should talk to. It's this manager's job then to divvy up the work and get the issue resolved.

It doesn't even need to be a new person. I'm a manager, but also an active developer in the team. The work comes to me, I split it up and coordinate the effort. Because I'm also actively working on the projects, I understand the scale and issues, allowing everyone not needed to continue with their BAU stuff.

  • 1
    In small structures, the owner (or one of them) usually is "managing" (however laughably) the developers. May 26, 2018 at 19:40

the mythical man month problem is about adding people to an existing team when time is already tight. instead of speeding things up you spend time getting the new people up to speed and generally increase the communication overhead.

this does not apply here. you are already a team, and the team composition does not change. you are just getting faced with a new problem/task for that same team.

what your boss is asking looks a lot like mob-programming.


other teams have found a way to be productive with this method, so instead of trying to change it, i would take advantage of the situation, and find a way to get the most out of it

  • 12
    No, Mythical Man Month is pretty clear that it's about more than ramp up costs, it's mainly about lines of communication. More people on a team equals more lines of communication. Now more people working on the same problem together doesn't increase lines of communication as much, as everyone should be talking about the same thing. Having 5 people work on a problem should solve it faster, and better because more people mean more perspectives. But having 5 people work on five problems is far more productive. Mob programming is incredibly inefficient, just as open offices are. May 25, 2018 at 0:15
  • 1
    you are right, that's what i meant to imply with: generally increase the communication overhead. i disagree that mob programming is by nature inefficient. it depends on the team.
    – eMBee
    May 25, 2018 at 5:35
  • 2
    i haven't tried it myself, so i can't speak from experience. i am guessing that mob-programming works because it can replace wasteful meetings and reduce the communication overhead. like instead of spending hours in meetings deciding how to solve a problem and who should work on what, let's try solving the problem right on the spot.
    – eMBee
    May 26, 2018 at 3:56
  • 2
    If you have five developers, by far the most efficient use of their productivity is to give one separate task to each and let them do it. One woman can produce a baby in nine months. Five women can't produce one baby any faster.
    – gnasher729
    May 26, 2018 at 14:36
  • 1
    @gnasher729 we are getting off topic. xp has already proven that point otherwise, if we want to continue this thread, let's move that to chat.
    – eMBee
    May 26, 2018 at 14:52

Getting developers to work on tasks and code they're not familiar with is hugely inefficient. Getting developers to switch tasks is hugely inefficient because of the mental readjustment needed that is usually not considered in these types of conditions.

How can you get your boss to understand this? It depends on your relationship with your boss and what type of boss they are. Has your boss demonstrated a willingness to listen to developers in the past? Are you in good standing with your boss? Are you respected by your boss? Is your boss relatively stress-free? The fewer of these you answer "yes" to, the harder it will be to make any sort of positive change.

In my last job, we were told on the morning of a particular day that the number of help tickets was too high, and that we each had to close 8 by the end of the day. Every single one of us struggled, and we averaged 3 closed tickets each, which with hindsight was an amazing effort, but one that went unappreciated. I can't speak for the quality of the solutions that was put in place for those issues, however.

Basically what happened in your situation and mine is the boss panicked and tried to fix a problem by throwing more resources at it. Yes, it would be great if all of our bosses read, understood and agreed with The Mythical Man-Month. However, in my case I knew this would never happen. I hope your situation is better than mine was.

The only chance I can think of is doing a post-mortem on one of these times. Did it go the way your boss expected? Was it good for the business or did it just waste a lot of time and money? What lessons can be learnt? (here you can subtly guide your boss's thinking so that they reach the same conclusions as The Mythical Man-Month without reading it.) e.g.

  • We tried working on task A, but only Alice knows how it works, so she had to spend half the day explaining it to the whole team. We effectively wasted 2.5 working days as a team (the same as having one developer off sick for 2.5 days). What do you think we should do next time?
  • We found it really difficult to coordinate since we had so many people working on the same task at the same time (provide an estimate of the average time wasted per individual team member, then multiply it by the team size). What do you think we should do next time?
  • My deadline on Important Task B has been pushed out by a day and a half because I spent a day on task A and it took me half a day to get back into the flow of Important Task B (provide truthful figures only). I'm not sure I can complete it on time anymore. What do you think we should do next time?
  • Two developers were not able to contribute at all because they don't have enough experience with Technology C. The team wasted 2 working days by having them not contribute to task A. What do you think we should do next time?

What's great about this approach is that you are clearly communicating your issues, without sounding like you're telling your boss what to do. It puts the responsibility back on them, because it was never yours in the first place! Hopefully, they will start to realise the damage being done, and how it's affecting the bottom line. In (almost) any business argument, money wins! If they come up with an idea independently, they are more likely to implement it, regardless of exactly the same idea being found in a 30 or 40 year old book.

If you're really, really, lucky then after this has gone well a few times you can say, "Hey boss! Guess what? I've found this book that agrees with the changes you've put in place and suggests even more along the same lines!" Maybe they'll read it, but bosses are generally busy people, so a boss without an existing reading habit is unlikely to read it. They might ask you what else it says though.


Be sure of your facts first. Given an apparently indivisible task, are you sure it is indivisible? Maybe not five ways, but perhaps two or three? If it's a programming task, you should be creating unit tests, which don't need to be (or shouldn't at all be) done by the principal coder. Sometimes programming tasks which seem indivisible on the surface can be divided down at least a little finer. Yes, there is a limit, and yes, there will be diminishing returns as the effort to coordinate the work takes away from the actual productive work, but if it shortens overall time to completion, you've at least met the spirit of your boss's intent.

As said in another answer, it would be nice if everyone who had any connection to a software development effort (team leaders, project managers, supervisors, etc.) have all read and bought into "The Mythical Man Month". Perhaps at some point when there is no deadline pressure and things are humming along OK, you might find a way to introduce your boss to the book. "Hey I found this really fascinating read...".


My suggestion is that you don't tell him anything. After all, he owns a company and you don't. He most likely knows more about running a company than you do. If you truly know more about running the company than he does then perhaps you should be running your own company instead of working for him. That is not to say that there is not some inefficiency in the way he is approaching the problem, but there are likely benefits that you don't see and the owner of the company probably knows that those inefficiencies exist and he still feels that it's worthwhile getting everyone involved. I think it is a form of illusory superiority to think that your suggestion is the best approach.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .