A Treatise on the
Importance of Hackathons:
Containing a Description of the Importance of
Engineering-driven Ideation, Building Bridges Within the Organization, and the External Benefits in Multinational Conglomerates With Shared Common Interests

Hackathons

These individual slices of our whole don't tend to overlap very much:
- In an ideal sense, we're all collaborating constantly, but...
- How often does back end collaborate with design?
- How often does sales collaborate with front end?
- How often does support collaborate with design?

What if we allowed members of all of these teams to form mini teams in an ad-hoc fashion in pursuit of a common goal?
Let the most entrepreneurial of our bunch post ideas up on some central board (e.g. Confluence, Slack, etc.)
Let those that are interested in tackling these perceived problem realms try to come together and hammer out a POC
Let others (devops and straggler engineers) have a support role in quick project scaffolding, allocation of resources, generic code monkeys, etc. to aid all of our various teams
Allow team members that don't normally work together, the chance to work together to push the company forward

Back end people may be concerned about request latency, or different database types, scaling strategies, etc.
Front end people may be concerned with slimming down our resource footprint, caching strategies, UI sluggishness, etc.
Design people may be concerned with interaction paradigms, data architecture, conversion funnels, split-testing, etc.
Product people may be concerned with streamlining workflows, feature-packing, their own dream pet projects, etc.
Sales people may be concerned with solidifying the most commonly-used features as rock-solid and fast, etc.
Support people may be concerned with technical aids that allow them to quickly and accurately diagnose problems, etc.