[actionscripted]

> You must implement a prototype. This prototype doesn't need to be "ready to merge", but it does need to be a basically complete solution to the problem at hand. You can't have a meeting to propose a big piece of work that you'll only do if the team agrees. You are basically producing a demo. Demos can cut corners on certain things (tests for one), but the main goal is to prove that the idea is a viable one and will work within your codebase. It's not useful to suggest a solution that is done outside of the context of your technology stack.

> Where can you find time to create this demo? You'll want buy-in from your supervisor (if they're a good one hopefully they'll encourage you!) Otherwise (to steal a line from Hunter S. Thompson), I hate to advocate nights and weekends, but they've always worked for me. (I do understand this isn't how it works for everyone...)

Having to work nights and weekends to build a working prototype to get in-house buy-in on new functionality makes little sense to me. If your team cannot work together well enough to agree on new features without them being built first then perhaps the issue isn't feature adoption.

[spigoon]

The author first suggests getting supervisor buy-in as a means for allocating resources towards a demo. It doesn't sound like he's mandating that you work nights and weekends to prototype.