7 ms·

I like your idea. Why don't you write up a white paper and we'll review it at the next staff meeting? That is a sure-fire way to stop most people.

• dekhn 5y ago
  This is a great idea. Can you write a design doc? Please make sure it's fully fleshed out.
• Frost1x 5y ago
  I've actually had this happen, so I pretty much wrote a white paper (charging company time and delegating time from dedicated efforts by way of the name of the person who requested it). I sent it, then continually followed up on the status of the points made. Some changes ultimately did get integrated because of it, I think calling the bluff forced someone to actively read, think, and respond to it, even if it wasn't leadership, they had someone else spot check and agree/disagree on points.
  • divbzero 5y ago
    There’s something to be said for corporate cultures that require written memos describing each new proposal. Forcing people to “actively read, think, and respond” is a great way to increase the likelihood that the best ideas bubble up to the top.
    • shoto_io 5y ago
      AFAIK amazon is pretty well-known for that? Some say it was key to their success story.
    • bobthechef 5y ago
      Indeed. It cuts down on impulsive and thoughtless decisions.
    • csydas 5y ago
      > Forcing people to “actively read, think, and respond” is a great way to increase the likelihood that the best ideas bubble up to the top. I think that it requires acknowledgment that there are two sides to such issues; as someone who is on the side that typically ends up having to handle the majority of the busy work to get many proposal through in my company I absolutely want the proposer to make the effort to figure out the stakeholders/costs/challenges for their project as well as answers. I'm willing to __fill in gaps__, but I don't really want to be having to do the basic legwork for someone else's project. I don't mean to sound like I want to stifle inconvenient creativity; it's certainly not the case, and when someone has really taken the time to make some new tooling/project with benefits and acknowledges the costs involved, I'm more than happy to champion such projects. But when someone just has a desire (or disparagingly, a whim) to change stuff up because it simplifies their workflow and they expect someone else to handle all of the communication of their project without even giving me the courtesy of doing such research, I cannot deny I approach such proposals negatively as I feel a bit used and I think that the expectation is "I want this, make it happen", which is not my job. Similarly, I find myself encountering persons who expect that I and the rest of the company will magically intuit the importance of very niche projects without being willing to take the time to simply explain the pain point they wish to address. I'm not even talking about deep technical details here, but simple things like: "We spend N amount of time on task X" "I have an automation workflow that will require Y hours to implement, but N is reduced by Z [time value]" Instead, the presentation is "I want to implement this automation workflow; what do you mean explain the value? Can't you see it? Why are we so caught up in corporate bureaucracy?" I'm all for reducing N as much as possible, but if I myself can't explain why spending Y is vastly cheaper than N, I have no confidence in my ability to convince others that the cost of Y is worth it. I've truly been on both sides, and it is some work to justify a change, sure. Formal proposal documents are a bit much for my taste, but whether we like it or not, C-Levels aren't going to read your code and they definitely aren't going to read a 2000+ word stream-of-consciousness email describing the project in an unstructured way (much less any git readme.md files). The impetus is on the person proposing the change to at least make an effort to convey the reason for the change to the relevant stakeholders.
    • jollybean 5y ago
      It's more likely to make those who are able to manage bureaucracies get their ideas to the top. Requiring some basic rigour to the thinking is good though.
    • tgsovlerkhgsel 5y ago
      It's also a surefire way to stall an idea out in paper form that by the time it comes to implementation, people have gotten distracted by other urgent work and the idea never comes to fruition. Since time can only be spent once, you are essentially picking between a quick&dirty prototype and a nice document. The document invites a bikeshedding session and consumes reviewer time, the prototype often allows you to immediately see whether the idea is worth pursuing, it may directly deliver a part of the benefit of the completed solution, and most importantly, it'll show the actual weaknesses in the design and the real constraints you have to deal with in a way that a theoretical review can't.
      • BogdanPetre 5y ago
        "time can only be spent once" - that's so important, yet people rarely realise it
• mjfl 5y ago
  some people will call your bluff.
  • romero-jk 5y ago
    How? One could answer, "Sure, but that will take away time from current things that need attention."
  • jrace 5y ago
    Perfect. Its not a bluff, it is a way of weeding out the non-serious requests. If you take the time then so will I.
    • drawqrtz 5y ago
      Man I wish that were the case. I've written way too much that has been discarded after a furtile glance. Maybe u just bad at bringing my ideas across
  • anders_p 5y ago
    > some people will call your bluff. Its not a bluff, when the point is to weed out the ones, who aren't willing to actually do a written proposal.
• endisneigh 5y ago
  I hope you don't work at Google with that attitude, lol. context: design docs are frequently written at G.
  • z3ncyberpunk 5y ago
    Why would you want to work at Google in the first place? Gross
  • isoskeles 5y ago
    Is there a difference between white paper and design doc? My impression is that a white paper is more academic, and so I'm not sure what it ends up looking like. At one of my jobs, we wrote design docs for most major changes (we had a checklist for deciding if the doc was necessary at all). It was ultimately quite helpful because documentation about most important changes existed, even if the dev didn't write any documentation in code. The technical designs also had a template, so it was a fairly easy path for a developer to know what questions to answer or not in their doc. Is this the same idea as a white paper?
    • pie42000 5y ago
      White paper sounds cooler
  • sitkack 5y ago
    I have seen google design docs at google, most are trash. Most design docs everywhere are trash. The confuse more than they explain. I don't care if the idea is good, if the design doc stinks, it will kill a good idea.
    • Ancapistani 5y ago
      Effectively communicating a complex idea is a skill that's orthogonal to coming up with good ideas. I advise other engineers, especially those early in their careers, to actively develop and hone their communication skills. It deserves far more focus than most people seem to give it.
    • 5y ago
• dqpb 5y ago
  On the flip side, it's amazing how many minds you can change with a small demo captured in a simple slide deck.
• goostavos 5y ago
  This is par the course at Amazon and, honestly, I think it's pretty great. We all tend to get a lot of ill-thought out pet ideas about what needs to happen in a project. Even a tiny informal doc listing out what problems you're actually trying to solve is a massive boon for communication.
  • mikepurvis 5y ago
    I agree. I'm a big fan of the lightweight design doc— what's the background, what are the motivations, what's the proposal, what are the alternatives and why aren't we doing them, what are the implications and potential downsides, does the proposal change anything about our exposures as far as security, privacy, etc. I like the discipline of writing these out for myself, I like reviewing them, and I like being able to look back on them for my own past projects as a way to quickly warm my mental cache.
    • rrrrrrrrrrrryan 5y ago
      > the lightweight design doc— what's the background, what are the motivations, what's the proposal, what are the alternatives and why aren't we doing them, what are the implications and potential downsides, does the proposal change anything about our exposures as far as security, privacy, etc. Maybe it's just me, but this sounds quite heavy.
      • mikepurvis 5y ago
        I think it's as heavy as you want it to be— not every point on there requires a whole treatise, but each is an opportunity to be like "is there information here that I have which might be useful to my colleagues or my future self?"
    • shoto_io 5y ago
      Could you share the basic outline / structure? Which points need to be addressed?
      • 5y ago
• skeeter2020 5y ago
  I don't suggest doing this as a passive-aggressive attack, but I use a variant when presenting to a group that includes the "always negative" person. I suggest they do some work investigating and sharing alternatives to the things that "won't work" and they miraculously start focusing on viable solutions.
• ianmcgowan 5y ago
  Aka "The Wally Reflector": https://dilbert.com/strip/2005-07-10 https://dilbert.com/strip/2005-07-10 I do this all the time, sometimes even something as simple as asking the user to write up the request in an email is enough for them to go away forever. It's a simple way to check if the requestor is invested in the request, or just trying to slide something from their to-do list to yours with zero effort...
• patmcguire 5y ago
  Yeah, it's good for these kinds of discussions when it's a universal requirement, or when the white paper concerns will actually be addressed before confirming a design. I do get suspicious when it comes up for the first time when it's something someone doesn't want to hear, or when the discussion continues on like it's obviously untrue in the meantime.
• loxias 5y ago
  Amazon is like this, and it's part of why I think I never worked out well. Too much process. Compounding the pain was the fact that my instinct would always be to whip up a proof-of-concept demo instead, for the next meeting. Management hated that, and to this day I don't get why. I recognize the need for things to be reviewed by others, and we all can lose scope of what's important sometimes. I'm no exception. However, for things that are purely technical/scientific arguments, what's gained by me having to use the Official Template (tm) to propose an idea, and spending days messing with words and bullet points, rather than a demo that you can see with your own eyes? It also struck me as quite hypocritical. On the one hand, professing to have a "bias for action", then on the other hand harshing on people for preferring action over another TPS reports. See also: CIA memo "How to Infiltrate an Organization and Make it Dysfunctional" grin
  • bobthechef 5y ago
    As always, nothing in the world can take the place of prudential judgement. When proposals should be written up to avoid senseless action and short-term thinking, and when they should be avoided because they would constitute bikeshedding or overthinking or whatever, is a matter of prudence and competence gained through experience. There is no algorithm that will allow you to mindlessly come to the correct decision. A demo is no substitute for a written proposal and vice versa. The first is empirical, the latter is analytical and deliberative. Each has its proper place. Really, the demo is a way to corroborate the proposal, so it's a question of how rigorous the proposal needs to be. Some minor tweak might only require a quick discussion while a deep change will require deeper consideration.
  • cadamsau 5y ago
    > Management hated that There's a subtle but important thing to note here. My bet is management didn't hate that you did a POC. They hated that you DIDN'T also do a writeup. It's not about this vs that. Meet the minimum requirements before you go doing extra.
    • imoverclocked 5y ago
      It’s all about communication. I think of a POC as way to communicate what it is that needs to be created. I think a document is another way of communicating what needs to be done. Mandating one or the other seems like a fools errand to me since each one has strengths and weaknesses.
• bobthechef 5y ago
  Whom would it stop? If your argument is any good, then all this whitepaper would do is make a better case. Asking for a whitepaper is not a bad thing for ideas that require some careful consideration. They're overkill for trivialities that can be fully decided here-and-now and or for things that don't really matter. Too often have I seen developers running in circles chasing ideas that could have been ruled out with a little forethought and analysis. They'll respond superficially to some idea that tickles their fancy, waste a bunch of time implementing it only to either realize that it's a bad idea, that it has serious drawbacks, or better yet, leave everyone with a dreadful piece of garbage to maintain.
  • anders_p 5y ago
    > Whom would it stop? > They're overkill for trivialities ... and or for things that don't really matter. I think you answered your own question.