I am a technical specialist (engineer) and have been working for this company about 10 years. The general feedback I have received for most of my career is that I work very fast while producing high quality output.

I have been asked to "share my secrets" because team productivity has been down. Very, very down. When we had a smaller team on earlier projects, we were more productive.

I'd like to present something to the team, but the problem is that my answer is a deeply divisive one, and I'm not sure I even believe it. I've tried it out on a few people, and one person who I consider a good employee, said he would quit if my ideas were implemented.

In my industry we throw out 9/10 things we build. That means some funny things that people don't like to hear.

  • Quality of the 9/10 of work we do doesn't matter, just speed
  • Don't worry about details
  • Hacks are fine
  • Try to avoid finishing things until you're forced (since often 80% of the work is polishing, you don't want to polish something you're going to throw away)
  • Don't waste time on style, or cleanliness until there's a really strong reason
  • Obviously you do have to do a big clean up the final product, but that's much less work than cleaning every day

I can't really imagine saying these things in front of my co-workers. I don't think management will like it either.

Has anyone else worked in an environment such as this and has any feedback? How do you convince someone that something they pride is actually a hindrance?

  • 7
    Have you actually been working this way yourself over the years? Jun 8 '18 at 5:35
  • 1
    @さりげない告白 his reviews say that he "produces high quality output", so I can't believe that works that way. Jun 8 '18 at 6:34
  • 4
    @Mawg I ask that because he is supposed to be "sharing his secrets" if he doesn't work that way himself, she has no business sharing that. Jun 8 '18 at 8:03
  • 1
    IMHO the title doesn't really fit the question. "Unpopular" sounds like closing the break room. This is more about introducing "unusual" methods "optimized" to a particular business need. Jun 8 '18 at 17:34
  • 2
    @Mawg - the asker is making an argument that quality should be strategic. Thus it is entirely possible that the early work is done with little regard as advocated in their bullet points, while the ultimate output is of a high quality and yielding positive impressions. It's a novel strategy not without risks, but not always an inappropriate one. Jun 8 '18 at 17:50

It's all in the words you use. What you are describing is an approach where you prototype features first, then test them, make sure they are really what you want, and only then decide to implement them properly.

That doesn't sound nearly as bad as "hack it and don't care about quality", because everyone understands that prototypes are low quality and only exist to prove that it can be done and it's the thing you need.

Once people realize they are building a discard-able prototype, that should also help with the pride part; it's good to take pride in the real work you build, but prototypes don't require it. Instead, take pride in being able to prove the idea is good.

The hardest part here might be convincing management that a hacky prototype isn't the real thing. Make sure you prototype doesn't resemble a working product in any section except the one idea you were proving. That tends to help a bit. (Having a technical manager helps even more. It's hard for laypeople to see the difference between a product that "works" and a product that is ready for use.)

  • 2
    Yes. What is being described sounds like writing code to help an internal or external client identify an uncertain requirement. The way to formally fit this into a traditional process would be to clearly split projects into two phases: experiments to identify the requirement, followed by actual implementation. Jun 8 '18 at 17:32

I've worked in a place just like that. I was made redundant from there as they were - you guessed it - on their way going out of business.

If you audibly voice any of those opinions (unless it is a very small firm where everything is informal and the product is easy to maintain) you will be marking yourself as a loose cannon and a potential liability to the company.

Good companies have systems in place to avoid exactly those kinds of things. They're the ones still in business and consistently making money.


There is an old proverb that says, "A person who tells the truth should do so with one foot in the stirrups" - which is to say, you are right in thinking that simply sharing your honest perceptions and opinions can put you on the wrong end of a whole crowd of pitchforks, so you had better have an escape plan. This is, generally speaking, not a comfortable place to be. You do have a few options on how to proceed.

But first, you need to consider the core reality of what you would be trying to do. People who like their job as-is don't want it to change, and people who don't like their job won't automatically prefer the alternative you offer. Offering a different way - even if it were absolutely, objectively, vastly better than the status quo - is still highly likely to upset an awful lot of people.

Are you fine with that? If not, you should probably just parrot socially acceptable platitudes like about how you've been doing this a long time and just tried each day to be a little bit better, and luck helps a lot, and I couldn't do it without great teammates and managers, etc. They won't like that you aren't more helpful, but oh well, I guess you just don't have some secret recipe for success after all.

If you want to be be an agent of change, you will have to accept that this can backfire on you and make people upset, or even get you fired. Producing a radically new invention that the whole company adopts and turns out to be greatly successful can still end up badly for you personally, and you need to know that going in. We wouldn't have a saying about "don't shoot the messenger" if people did not, in fact, tend to want to shoot messengers. People are just like that, change is hard, and 9/10 change projects fail - just like how you've noticed most projects get thrown away, too!

If you want to proceed anyway, you have a few major options.

Option 1) Diplomatic Skills

There is a difference in speaking truths in a way people will not accept, and finding a way to say the truth in a way that people will tend to find acceptable. In general, when you want to change things, you need to find out common ground and existing pain, and start there. For instance, do your coworkers complain about all the wasted time and energy that is put into things that never go anywhere, help anyone, or seem to have any benefit at all? Do they publicly or privately grouse that most of what they do is BS? If so, you can start there, acknowledge/raise awareness of how many people feel this way, and then talk about how this can be addressed by being explicit about the fact that 9/10 projects are actually "throw-away prototypes" (the common industry term I'm familiar with).

I'm personally fond of analogy, so I like to point to sand mandalas:

By Ji-Elle - Own work, Public Domain, https://commons.wikimedia.org/w/index.php?curid=3882201

The practitioners spend hours upon hours constructing individual grains of sand into works of beautiful, intricate art - and then ritually dismantle and discard them. It seems like such a waste! How can you spend so many hours on something, only to throw it away, to not even try to save it or use it for something for more than the day? You'd be wrong to think it is easy for them, just because they are monks - that's a big part of why they do it. Even the best of things play their part for only a little while, and then return to nothingness.

The problem is, of course, not all of your coworkers are the same, and even if you love this and find it very appealing and spiritual, some will find it deeply depressing, unacceptable, stupid, short-sighted, fatalistic, and a dozen other nasty words (some of which will be found in the comments section). Some may enjoy focusing on "quality" of what they do, even if it is absolutely worthless to anyone else; effectively their job is like painting model airplanes that they will store in a box and no one will ever look at. Its fun for them, and good for them for having something they enjoy. These people are not going to be pleased that you point out that most of their work doesn't benefit anyone else, or the company, or the customers, etc.

Diplomacy has its limits. You can get more allies with a well told story than without, and making a negative into a positive - its not a BS waste of time if it is an experiment we knew in advance might not turn out to be used! But if you think it'll make you a hero to everyone, oh you will be so disappointed. Politicians can be great at this, and you know how people think about them!

Option 2) Ask For More Than to Give Advice - Ask for an Experiment

This generally starts with humility, and you basically turn people's request to share your secret formula into the basis for a bigger request. You do things differently, you agree with them, but not only are you not sure that anyone else would benefit from working the way you do, but you aren't even sure if the ideas you have are even why you are so successful at what you do. But - you have some ideas. You couldn't even begin to suggest them normally - no, they are far too crazy! Forget the whole thing, never mind, you should just get back to work.

But, well, if they persist - propose an experiment you'd like to conduct. You'd have a small team of coworkers you select - a "tiger team" in business-speak - and you would need authority to decide to do things differently in terms of project management/structure. You can explain how you would go about it - insisting that everything be built as a throw-away prototype first, with your coworkers all ageing on your crazy ideas of building fast and hacky and only even try to fix it later if the project ends up really being wanted in the end, etc. The goal of the experiment is to determine if your methods really work for more than just you, and it will need a set amount of times/projects, and a preset review process.

If at the end of the time period (6 months, a year, whatever), it is agreed that this didn't work out, you just go back to doing your work as you have done it and everyone else goes back to doing things their own way. If it works, you then have a meeting on if you expand the team, try to make a second team, etc. Less risk for you, your bosses, your coworkers, etc.

And if they don't want to give you that kind of arrangement? Then they don't actually care about your opinion. They want cheap progress, they want a magic pill, and that doesn't work and you don't have it to offer. They may just want someone to blame when things go wrong, or any of a thousand other reasons. But the fact is, if they aren't willing to offer you more than the chance to share a few words of wisdom, they don't really value you enough to bother. Anything you say would be as "pearls before swine" - they don't actually care, they just wished everyone did as much work as you do, without having to any hard work to make that happen.

Option 3) Ask for Outside Help In Experiments/Change Management

Other people have ideas similar to yours, especially about throw-away prototyping, rapid application development, reducing work on things that aren't going to ship, etc. So if you don't want to be in charge of all this, suggest the possibility of consultants who seem to share your ideas and are happy to roll in, upset people, and roll out with only their paychecks if things turn sour. The upside here is - you get someone to blame, too. "Jeeze, what a bunch of frauds, glad you kicked those guys out - oh well, back to work."

The other upside is they may have more experience in how to manage process changes like this, it requires management to make the decisions to hire them and accept/reject their advice (management support is basically required for things like this to work), and other than having a few extra meetings you can mostly just go back to focusing on your work. You can still be blamed for the suggestion, and they might turn out to suggest the opposite of what you would have, but at least most people are usually happy to blame outside consultants (and management for hiring them) instead of you.

Option 0) Just Decline

I end this advice as I began it - you can just decline. What works for you, works for you; your coworkers won't like it, they'll probably refuse to do it and would likely screw it up anyway, everyone will look to blame you for absolutely any downside while refusing to credit you for upsides, so why exactly do you want to agree to carried up the volcano by the over-excited villagers just because they offer you a laurel?

In my personal experience, I found I loved research projects of this type, trying to discover better ways of doing things and sharing them with others, and I found out (mostly the hard way) that if your officially mandated job is not exactly this, it will usually go badly for you. You will be blamed for the bad, others will take credit for the good, any issue with your other work will be more strongly criticized and you will be accused of "losing focus on the job you were hired to do". In the end, what worked for me was taking my experience and switching to work in research and development, where this sort of thing is explicitly "your job". What I have seen working for others is some variation of the above options, none of which are easy.

I've only ever seen one other thing work, and that is when management - from the top down - was explicitly invested in growing and supporting an unusual culture of championing the testing and growing insights offered by workers. It's so unusual that someone will generally write a book about it.

Choose wisely, and good luck - you're going to need it either way!


I was in your position. What I did was to ignore the what other technologists think and work directly with the business people to work the way I liked to work. I moved out from under the technology leadership and get imbedded in a business group. There I worked towards the goals of building useful things instead of over engineering useless things. A few others saw how much fun I was having and were envious and joined me. Business people and leadership will loved my contribution. I don’t worry that many technologists will complained that I broke their rules. In the long term my point of view prevailed in the leadership group and I ended up running the technology department. There I set about integrating the technology and business people.

The long-term answer is to change the culture by changing the structure of the organization.

Technologists often see them selves as a counter balance to business people. The common tension that the business people push for getting to market as quickly as possible and the technology people care about maintainability and scalability. Two parts of the business have misaligned goals. The management team often promotes this by setting business people goals around revenue, time to market, customer growth. At the same time, they tell the technology team that quality is important. If the business side wins the argument the technologists feel hurt and forced to do things they don’t like. If the technology side wins then the business people feel technology only cares about their own agenda and not the bottom line.

Many times one side or the other is wrong. Maintainability is not important if you don’t know if your company or product will be around in twelve months. Making more sales is not important if the database servers or supply chain is about to fall over under the load. Make these issues everyone’s concern, not one dept.

A solution I have seen work well to end this conflict is to create one team with one set of goals. Put together a team of business development people, technologists, designers, sales people, customer support, finical analysts (they are very important). Create a mini-company around the product deliverables. Give them goals based on the outcome you want. Then watch them all work towards these goals. The technologist will still bring up issues about quality but when they the discuss them they will understand the compromises they are making. Make the point that in a business everyone is a business person.

Early in the product life cycle the ‘business’ point of view will prevail. At this point amassing technical debt is good, it is supporting the growth of the product just like real debt. Have everyone contribute input into the decision about how much technical debt is sustainable. As the product matures ‘technical’ concerns will influence decisions more. Everyone will start seeing the benefits of technical improvements. People will be able to argue for these changes, not in technical terms, but because they can point to how the help the business. For example, rewriting the software code may be justified because it has become too slow to add new features or perhaps it is time to convert from small batch manufacturing to building out a manufacturing facility.

When developing a product, 90% of the ideas wont work in the market place but you can't know this untill you try. This is why building as many things as you can very fast and throwing them away is important.

How well this works does depend on the personalities. There are technologists who want clear requirements to follow and hard rules about technical tradeoffs. These people don’t work well on collaborative multi-skill teams. There are also technologists who love to be given a vague problem and build a solution, true hackers. People who don’t worry about the instructions when they get a box of Lego. These are the people you want.

I have spoken about products here. A product could also be an internal deliverable to other parts of your business. Everything still applies, you just need to find the right goals to work towards.

Good luck. When you throw off the shackles of technical orthodoxy then building things becomes a lot more fun, and profitable.


The big question we need answers to, is why 90% of output is not used. Is it not up to quality standards? You can test quality without a final polish on work.

Why are Hacks fine? You need to determine what a 'hack' is. If it's good it becomes part of the standard process. If not, then it isn't allowed.

You should define the output at each stage of the process, and determine what's inhibiting the output. Define a solution, and propose it. Look at the low hanging fruit first.

Yes - you'll lose staff. Staff who don't care about their work or the final product. Is that such a great loss? Productivity will go up, and staff wages will go down; I'm not seeing a downside.


Of course your productivity is down. You basically throw away the work of 7.2 hours from an 8 hour day, every day!

That needs to be rectified, if possible. I know chip manufacturing for instance has a certain quota of bad results but not as near as bad as far as I know.

Find ways to improve the quality of the interim product before it is being polished. If it is because of the production process or material deficit it should be possible to a degree to improve or use higher quality resources. If it is because of manual labor (i.e. speed, too superficial approach, laziness) I can however see how changes would gain resentment.

Still, in order to keep the company in business, changes need to be implemented and management would be ill advised not to take them on, even if it would mean that a certain amount of "problem workers" might leave.

Also, maybe the managements expectations on work speed are wrong and you should actually allow for slower work in order to get better results. This approach possibly could significantly reduce your waste of products, increasing the overall productivity / output of the company.

tl;dr: find out the reason for unproductivity / high product waste if you haven't already and suggest the changes. As was mentioned before prepare for stormy weather and possible jobhunt in the foreseeable future either because the company went bankrupt or because you left / were let go...

EDIT Considering the comments below, applied to software development, I agree that prototyping and testing functionality does result in work being discarded. However, I still think you should attempt to minimize the amount of discarded work. Maybe your company needs more senior/experienced employees?

You will need some repeatable solutions (maybe some pieces that can be copied / re-used from application to application) and you'll only be able to push things through with management on your side. (or rather by convincing them, that your approach is more efficient)

  • 2
    It doesn't sound like the work product being discarded is being discarded because it is defective. Rather, the argument the asker is making is actually for lowering the standards of initial work product that is only going to be discarded anyway. So likely the reason it is discarded is not because it is bad, but because becomes evident that it does not match what the actual needs have since been learned to be. Jun 8 '18 at 17:44
  • 1
    Throwing less things away shouldn't be a goal of product development. Making it faster to to get to a keep or throw away decision should be a goal. Edison's team tested over 6,000 different materials for use as an element in incandescent lightbulbs.
    – Ben Mz
    Jun 8 '18 at 18:21
  • 2
    In reality, lots of organizations ultimately throw the majority of their work product. (The whole idea of startups its pretty much predicated on that idea, and throwing away the entire companies too). Pretty much the only way you avoid such cost is to have very strong evidence before commencing work that the work proposed to be done is actually going to be useful. Most of the time that is not the case, though 90% may be an extreme. Jun 8 '18 at 18:47
  • 2
    You seem to be trying to apply a factory that makes the same thing every day mindset to the situation of an asker doing original work, which is in fact going to be largely composed of R&D. In effect, it's all R&D, except that the minority of cases where the guesses actually turned out be right, get respun into production form. Jun 8 '18 at 18:49
  • 1
    The work that is thrown away is not without value; the value was in learning that it was not the right approach. Again, 90% may be a bit high, but this is pretty much a normal cost of business. And the less clear the stakeholders are about their needs, the less willing they are to meaningfully evaluate early test versions, the higher these costs are going to be. Don't forget that "completing" a project doesn't mean the result is not still going to be thrown away - sometimes the need to take a different course is evident during the project, and it re-directs Jun 8 '18 at 19:05

I, too, am a software engineer.

I, too, have received similar feedback.

I really like your philosophy. However, it may come across negative. So be careful how you word it: Try not to use words like "waste"; State things in the positive, not the negative; Also include the reasoning/why, not just the principle:

Quality of the 9/10 of work we do doesn't matter, just speed

Consider: "Define what quality means. Then do that as quick as possible. Going above and beyond is not needed. What is needed is speed." (By definition because we've already defined what quality means)

It's not that quality doesn't matter, literally. Some people might what you said that way. Quality does matter, but it stops once you've acheived minimum (truly) viable product.

Hacks are fine

Consider: "Hacks are fine if they're the best thing that meets the goals. At the end of the day our goals matter, not how we achieve them." (If it did matter, then that would be a goal)

Just today I chose to make a REST delete endpoint use the HTTP POST verb because using DELETE would have been more work; it's an internal API. Maybe give some examples where you broke best practices for the sake of profitability.

Try to avoid finishing things until you're forced

Consider: "Do work only when needed."

Don't waste time on style, or cleanliness until there's a really strong reason

Consider: "If style or cleanliness isn't needed for the goals, don't do it"

My wording stresses the why - cleanliness and style are often above and beyond. It's not that they're not needed. It's that they're unneeded once goals are met.

I don't think management will like it either.

I think this philosophy is actually perfectly in alignment with management. Define the goals. Management does that. Then do just that. No more. No less.

How do you convince someone that something they pride is actually a hindrance?

You start by asking them what the goals are. Then ask them if something is in alignment with those goals. If it isn't, take it out. The conversation becomes less about opinions and experiences and authors and what people have said and very straightforward - does this meet the clearly-defined goals.

Of course you have to have clearly-defined goals. That can be a challenge. And then there may be debate over which goals are good. And that's another challenge. But I assume that's for management to figure out. The team implementing the software usually doesn't participate?

my answer is a deeply divisive one

I'd approach it like this:

"I was asked to share my secrets. I've found this to work well for me. But I don't have all the answers. I'd like to hear your thoughts. Do you think this would work well on the team? If not, what would work better? Let's not shoot down any ideas. Let's listen to one another. We all want the same thing - (drop your company mission/vision) - and the best way we can get there is if we combine our collective thoughts and experiences."

People will respond better if they're included in these changes instead of you dictating. That will encourage people to share their thoughts with you. And maybe they'll think of things you haven't considered. And you can adjust what you say accordingly. Your goal is to arrive at what to change, not to already know.

I'd also recommend doing this incrementally. In other words, maybe pick one pirinciple or thing to change (as team ask yourself what one change you want to make) and then do it. Hopefully you can measure the impact somehow. In a couple of weeks pick another thing to change. By only changing one thing you reduce risk of catastrophic failure. By doing it incrementally you have a chance to reflect and tweak things. (I like to approach processes executed by people the same way I approach code executed by computers.)

Finally, talk to coworkers who are most disgruntled/frustrated, figure why they're frustrated, and give them a recommendation on how they can lead efforts for change to fix their frustration that's in line with the goals of management. Win-win-win.

I think software is a people, not a computer problem. Figure out how to truly value every person impacted by your software (and not just your customers) and you'll do fine. Good luck!

  • 1
    +1 Great answer. However, the questioner doesn't say he is a software engineer.
    – Ben Mz
    Jun 8 '18 at 21:49
  • 1
    @BenMz Thanks for the +1! I saw software as a tag on the question and (possibly falsely) assumed OP was in software Jun 8 '18 at 21:50
  • 1
    You are correct. I didn't notice the tag.
    – Ben Mz
    Jun 8 '18 at 22:07

You must log in to answer this question.

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