Our boss is highly visionary. They have really good ideas, tells us about them, and then expects implementation ASAP. The flow of ideas is, we feel, on steroids.

Soon enough, they will come back and tell us they changed their mind and/or tack on some more features, mid-development. During development, we come across the need for more details, clarification, and what-ifs. When we present these to the boss, they often reply "I'll have to think about that and I'll get back to you". And the next day, they come back to tell us about changes and even more ideas when our original concerns haven't even been addressed.

We think that our boss doesn't think things through, as we always end up chasing them for clarification, more details, and what do for various scenarios.

There were times that we decided some things behind their back (as we saw made the best sense) just to get something to work and/or have something to show. We quickly learned not to do that again because it ended up either totally opposite or unlike what the boss expected.

Worse yet, they don't put their ideas in writing, so we have absolutely nothing to go back to except for the conversations. To combat that, we are the ones who take notes and hack our own brains for any applicable "what ifs" on the spot. Even when we take notes, we still end up in a situation where the boss claims to have verbally said something and we allegedly forgot to write it down. We requested numerous times for written expectations and details. Never got one. Responses were "everybody does things differently" and "you have been taking notes and asking me questions as you need for years; there should not be a problem", "well, this is how we do things here," and (ugh) "you guys need to figure out how to be more flexible."

Not only are they our boss but also one of our co-developers. Our biggest challenge is they like to (and actually do) update the live product on the spot, often without telling us the changes and when they made such changes. Eventually, it became our responsibility to always ensure that what we're about to save/submit won't overwrite any changes they may have made and also to ask for what those changes were so we can copy it in our local machines. The rest of us want to implement version control and obfuscated/compacted code on deployment, but with these spontaneous requirements, those are not possible.

We feel that this type of management/workflow is inappropriate, and there's nothing we can do about it. We want to get things done efficiently and (IMO, more importantly) effectively, but we're struggling without definite written plans and customer interaction scenarios.

If you face similar situations, what have you done successfully to manage or even combat this situation?


Thank you for all your responses so far. Honestly, I was expecting everyone to say that I'm an incompetent and/or overly-demanding worker who whines too much.

I can only wish that our boss starts writing things down and not just throw out ideas at us just like that. If ever I land their position, I will take your advise seriously and at heart. Or, if I find someone who wants to start their own similar or applicable business/practice/shop, I will give them your advises.

  • 1
    I have been fighting it for years. Even when I write it up and send it to my management they don't even read it. Some manager are just visionaries. You can try wire frames but that did not work for me.
    – paparazzo
    Nov 17, 2015 at 19:02
  • 1
    Is your boss the owner of the company, or the head of the IT department? Is there someone higher up than the boss or managers on the same tier as them?
    – simbabque
    Nov 18, 2015 at 9:18
  • @CluelessButTrying Considering that the person in question is effectively being talked about behind his back here, I doubt his pronoun preferences are important. Singular they is also not nearly as universally accepted as you believe.
    – Lilienthal
    Nov 18, 2015 at 15:25
  • @simbabque - the boss is everything from owner down to one of the developers. Nov 18, 2015 at 19:40
  • 1
    I feel like I might be able to write a good answer, but it would take some time, and I'm currently on my phone. For now, I'll just say: the behaviors you describe are examples of some of the personality traits naturally befitting executives, it's probably why he's the boss. The careful methodology of a developer contrasts sharply with these traits. The ability to bridge that gap is an invaluable skill. If you can solve this problem well, it could be a key turning point in your career. Nov 18, 2015 at 20:38

6 Answers 6


I am usually not the one that evangelizes the Agile methodology but this is one of those examples where it has the potential to greatly help.

It is time for your boss to decide if he is serious about taking software development seriously... Seriously! The thing that separates out a decent company with nominal results from a company with exceptional results isn't the ideas. Ideas are cheap. Every Jack and Jill in the software game fancies themselves a "visionary" but usually the better quality founders and managers realize and acknowledge that there is very little new under the Sun.

Think long and hard about what made Facebook substantially better than ideas that came before it. What was so groundbreaking and earth shattering about Facebook that caused it to excel over not only other startups with roughly the same ideas but also well established players like MySpace?

The people, and how they execute. That is the key. A good VC realizes that a smart investment considers the leadership to be as important, if not more important than the idea itself. Do these people have a good detailed plan? Do they have the ability to see it through and execute?

Nobody likes to get their hands dirty, but you need to make it clear that visions don't build a product, a Product Owner or a Product Manager is required to translate that vision into a disciplined approach and plan of execution. Agile can help evolve your backlog as your vision and your requirements change.

  • Management/Excecution > Vision/Ideas? Shocking! Yet I'm very relieved because my style of work and preferences (both personal and professional) leans more in favor of planning, weighing options, and establishing effective (and as a byproduct, efficient) practices. Nov 17, 2015 at 21:55
  • 1
    Agree about agile (or at least, something similar) being useful here. Excessively reactionary management/leadership is a common problem. And often trying to make the individuals involved act in a less-reactive way is a losing proposition. The better option is to put a process in place that, like agile, provides some insulation to the developers against sudden changes, documents planned work, establishes visibility of what's being worked on, and shows management the consequences that each reactive change has in terms of disrupting or delaying other tasks.
    – aroth
    Nov 18, 2015 at 2:20

Some degree of changing minds and not documenting is an extremely common problem. The key I think is to try to make it obvious to your boss the amount of effort that gets wasted every time they make these spontaneous decisions without spending some extra time thinking it all the way through.

Through documentation of your process, you'll have numbers that will help convince them that they're saving money. Also, while more process may seem like it's unnecessarily slowing things up, it's good if there is a little resistance to enacting change, because if it takes a little effort for your boss to push through decisions, they'll be less likely to throw them at you willy nilly.

  • Document how much time you spend on tasks, and how much of that work gets thrown out. In general, you should be tracking how much time you spend on tasks anyways.
  • Bring this document to your boss, hopefully it will make the problem obvious to them, and tell them the solution to this is that you need to formalize and document decisions, so you can know exactly what is being done, and how much time is spent. If your boss is a reasonable person this should seem like a good suggestion to them. You could even suggest that you will do these changes as a trial first, rather than pushing for the entire company to make this sweeping change.
  • For new projects, after discussing with your boss their ideas, start creating formal documents detailing the project, and insist your boss review them and sign off on them.
  • Whenever your boss makes a decision to make a change verbally, start insisting on at the minimum he sends you a written email with his requests. You will consider these written emails official sign off. If your boss doesn't even realize they're asking for a change, refer back to the original document he signed off on, and notify them of the change. Respond to all change requests with time estimates, and also time that you spent that is now being thrown out.

It will be difficult to enforce these changes, since it's very difficult to get people to change their bad habits that take less immediate effort and instead have the discipline of due dillegence. If you consistently insist though, hopefully you can push through these better habits.

  • I honestly never did point#1 in any work, so we'll need to think about that. We've done point #3, but they're in the back burner for now because they were just spur-of-the-moment visions of our boss. We lost on #4. They won't. Not even email. Again, we get "everybody has their own way of doing things." Nov 17, 2015 at 21:27
  • Well, if they really do ultimately refuse to change because "that's just the way we do things here" then it really may be time to find a place that has better process, and better attitude towards trying to improve.
    – Kai
    Nov 17, 2015 at 21:32

We feel that this type of management/workflow is inappropriate, and there's nothing we can do about it.

Yup! I'd get out of there if I were you, for the sake of your own sanity.

This person clearly does no understand the development process, and in my experience there are some people who will never get it - most often the truly "creative" types.

To them, any new, shiny idea is a dream to be chased, the old one instantly forgotten. The problem with this approach is that they do not commit to any one road - not for long, at least. They're all about quick, maximum impact solutions.

And I get it, that style of thinking, and flexibility have an important place in this world ... just not in software development. We require more structure, requirements, technical specifications - and we rarely get them, which is where our own flexibility comes in.

However you cannot be expected to succeed without some sort of middle ground. And that compromise is typically obtained by having someone very carefully manage this highly creative person, and trying to keep them on track - a go-between person, and preferably one with some authority.

By all means, try all of @Kai's suggestions. I sincerely hope it all works, and you impress upon your boss the importance of establishing a process, and committing to a course of action (or accepting the technical team's opinion that a desired path would not work).

However, I have a feeling that trying to impose structure on someone who thrives on the edge of chaos might not work out, especially since this person is both the final decision maker, and your direct contact. In which case, remember my advice: leave.


I have seen this many times with ideas not thought through thoroughly. My method is to make a plan of implementation with a step by step. Then send it to the boss to approve before getting started. Once it's been approved I'm good to go on it.

If he/she changes things along the way, I modify the implementation plan and send it again for approval.

This ensures everyone is on the same track and everyone has a chance to modify the plan before resources are used on it. Plus it can be referred back to anytime.

  • Like some have said above, we do write and send documents to management, but they won't even read our write-ups, let alone approve them. We do keep our own documentation for our own reference and sanity. Nov 19, 2015 at 1:22
  • 2
    been there, I just didn't start the work until I had approval, after a couple of times of them asking why I hadn't started and me saying I was still waiting for approval because I didn't want to go down the wrong track, they started signing off on things. It's not something any boss can argue against without making himself seem stupid.
    – Kilisi
    Nov 19, 2015 at 3:51

Difficult situations. There are really two questions: How can change your bosses style so that you avoid doing lots of work that ends up being thrown away. And how can you change your working style to be more effective in an environment of madly changing requirements. Forgot the third question: What should you do for career planning!

It sounds like you won't be able to change your boss. You will always get incomplete, vague specs and when you ask for details, you either will get nothing or you will get completely different specs. So don't ask for details.

Q1. Take the specs, and fill out the details yourself. Then you have a complete spec. You hand it to your boss and tell him that you filled out the gaps. Do NOT ask for his opinion. Do anything to keep him from coming up with new ideas. This might work and is likely your own chance. A nicely written spec also might give him a hint that what he is delivering is not very useful.

Q2. Write your code so that bits and pieces are reusable or replacable. Learn what tools you have to achieve this. That's hard, and any advice would depend on what exactly you are doing.

Q3. Take the opportunity to learn as much as possible so that you are a better developer when your journey ends. Which it will when the boss runs out of money. (If he is the head of your department, when his superiors are not happy with the way things progress). Make sure your CV is up-to-date and don't invest too much emotionally into the company.

  • A1. We have both succeeded, and got in trouble if our specs ended up not matching their vision. Sometimes, new ideas come up from them when they test our work. A2. We do. But every new feature requires another level of condition checks - how to combat this?" A3. Doing that. Slipping modern practices into the company even when they are reluctant to use it. Nov 17, 2015 at 21:38
  • @MickaelCaruso You just have a profoundly poor company. Software cannot be effectively created in such an environment. Your visionary needs to be tapered by a pragmatic product manager or your company will fail to deliver anything substantial. Nov 18, 2015 at 12:10

Use subversion for development and checkout one working copy on the server. Don't waste time teaching them how to use it, just commit whatever they changed.

Learn to play by their rules. You will have to jump over your shadow of being efficient, but you might learn a lot about creative thinking.

At the moment you are the blocking part between your boss and his vision. Try to minimize that effect and get to know how he thinks and when stuck on a question try to anticipate what he would do, you will learn to work "efficient".

I know this contradicts good software development, but you might gain something more valuable than work experience. The important part is to communicate what impact this working style has, what part of the already done work is lost, and so on.

But don't see this as negative, imagine some idea is better, but you first implement the old one just because it came up first. Embrace the startup mentality of your boss and don't see thrown away work as failure, it is part of the process to prototype and change requirements quickly:

I have not failed. I've just found 10,000 ways that won't work.

However, prepare for a big catastrophy, update your CV, and so on.

  • This is probably the toughest answer given so far, and your advise is exactly why I'm still with the company. I have yet to find any merits of working in this type of environment, so what would be more valuable to be gained from this other than work experience? Do you have any advice on how to stay motivated when an excessive portion of your work is figuring out workarounds and hacks to conform to such a workflow? Nov 19, 2015 at 3:00

You must log in to answer this question.

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