5 to 8 minute read
Playbooks by Program Type
Scroll down to explore more, Scroll down to explore more
Part 1: Awards
01
Planning an Awards Program
The many names these programs go by, and the single shape they almost all share.
5–8 min read
If you're reading this, chances are someone in your organization has recently said some version of "we should really recognize the best of what we do." That instinct, wanting to spot, celebrate, or fund the best work in a field, is the starting point for every award, competition, grant, or evaluation program that has ever existed. Before we talk about software, timelines, or judging panels, it is worth pausing on what these programs actually are, because the label changes far more than the substance.
In plain terms: An awards program recognizes excellence rather than distributing funding, so planning centers on categories, judging criteria, and how winners get announced, not on financial due diligence or eligibility documentation the way a grant program requires.
- Start with what you’re actually recognizing. Before naming categories, write down, in a sentence, what “winning” is supposed to mean for your program. A “Most Innovative” category and a “Best Overall” category aren’t different labels for the same judgment, they ask judges to weigh completely different things. If you can’t articulate the distinction in a sentence, your judges won’t be able to either, and you’ll get inconsistent scoring as a result.
- Decide one-time versus annual early, it changes the whole structure. A one-time program can build a bespoke process. An annual program benefits from locking a consistent structure entrants come to recognize and trust year over year, changing your category names or judging criteria every year erodes the credibility you’re trying to build. If you’re not sure yet whether this becomes annual, design it as if it will, it’s easier to simplify a repeatable structure than to retrofit consistency later.
- Budget real time for the announcement, not just the judging. Organizers consistently underestimate this. A winners’ ceremony, a press release, a social media rollout, a printed certificate, these take longer to plan than the judging round itself in most programs, and they’re usually the part entrants and sponsors actually remember. If you’re planning any kind of public announcement, start that planning in parallel with judging, not after it.
- Decide your sponsor structure before you open entries, if you’re using one. Sponsored categories change what you can promise entrants (visibility, specific prizes) and what you owe sponsors (logo placement, category naming rights). Retrofitting a sponsor into an already-designed category structure is a common source of late scrambling.
Recap
- Write down what each category is actually judging before naming it, vague categories produce inconsistent scoring.
- Decide one-time vs. annual early, and design for consistency if there’s any chance it becomes annual.
- The announcement and ceremony often take more planning time than judging itself. Start that work in parallel, not after.
- Lock your sponsor structure before entries open, not after.
Quick check
Regardless of what a program is called, the design questions behind it are mostly the same:
1. What is the most common planning mistake described in this section?
2. Why does an annual program benefit from a consistent structure?
3. It is fine to add a sponsored category after the rest of the category structure is already designed.
02
Why Organizations Run These Programs
Four recurring motivations — and why the dominant one shapes every decision downstream.
5–8 min read
Section 1 covered what these programs are. Before we get anywhere near software, it's worth spending one more section on why an organization decides to run one in the first place, because the reason behind a program quietly shapes almost every decision that follows it: who you invite to judge, how public the process is, even what "winning" is supposed to mean.
In plain terms: Organizations run award, grant, and evaluation programs for one of a few recurring reasons: to build visibility for their brand or community, to identify and support talent or work worth funding, or to hold their own field to a shared standard. Most programs are really pursuing more than one of these at once.
The same shape, many names
Despite the different names, most of these programs share the same underlying shape: someone submits something, someone else reviews it against criteria, and a decision gets made. Once you see that shape, the different labels start to look like variations on a theme rather than separate categories:
- Visibility and brand building : An industry association running an annual excellence award is also creating a reason for the whole industry to pay attention to them once a year. The program becomes a marketing asset as much as a recognition exercise.
- Community and engagement : A photo contest or an internal employee recognition program usually optimizes for participation itself, the entries matter less than the fact that people showed up and took part.
- Talent and work identification : Grants, scholarships, hackathons, and talent searches exist to find something specific and back it, so the review process carries real weight because the decision has consequences beyond a certificate.
- Setting or defending a standard : Peer-reviewed abstract programs and accreditation-style evaluations exist to hold submissions to a bar, not to generate excitement. The goal is making sure whatever gets approved actually meets the standard.
Most real programs blend two or three of these. A scholarship program is clearly about identifying talent, but it's also a visibility and engagement play for the foundation funding it. A corporate awards program is community-building on the surface, but the winners often become case studies used for external marketing later.
Why the reason matters for everything downstream
Once you know which of these four an organization is actually optimizing for, a lot of design questions answer themselves. A program built for visibility usually wants a public gallery of entries and a splashy announcement. A program built for funding decisions usually wants confidentiality and a much stricter judging process. A program built for engagement can tolerate looser judging criteria, since the goal is participation, not precision. A program built to defend a standard cannot.
Getting this wrong is a common early mistake: organizations borrow the judging structure of a prestige awards program (multiple expert rounds, strict confidentiality) for something that was really meant to be a fun, high-participation engagement exercise, and end up with a slow, over-engineered process that discourages the very participation they wanted.
Recap
- Organizations run these programs for one or more of four reasons: visibility, community engagement, talent or work identification, and standard-setting.
- Most real programs pursue more than one motivation at once.
- The dominant motivation should drive decisions about confidentiality, judge expertise, and how public the process is.
- Borrowing the wrong program’s structure for the wrong motivation is a common and avoidable early mistake.
Quick check
Regardless of what a program is called, the design questions behind it are mostly the same:
1. A corporate program built mainly to generate case studies and press coverage is optimizing for which motivation?
2. Which motivation typically demands the strictest confidentiality?
3. Most real-world programs pursue only one of the four motivations at a time
4. What is the most common mistake described in this section?
03
The Manual Way, and Why It Breaks Down
Spreadsheets and inboxes work — until volume, judges, rounds, or accountability arrive.
5–8 min read
Every program in Section 1's list can be run without software. Award programs existed long before online submission forms did, and plenty of smaller programs still work off email and spreadsheets today. This section is about why that approach works fine at a small scale, and why it reliably breaks down as a program grows, since that breaking point is usually the exact moment an organization starts looking for software in the first place.
In plain terms: The manual way means collecting entries by email or shared drive, tracking them in a spreadsheet, and coordinating judges by sending files back and forth. It works because it's flexible and free. It breaks down because none of those tools were built to manage many people doing the same structured task at once.
What "manual" actually looks like
The strain doesn't show up gradually, it tends to show up all at once, usually tied to one of four pressure points:
- Volume : Fifteen entries is a spreadsheet. Three hundred entries is a full-time data entry job, and every manual retype is a chance for a score or a name to get mistyped.
- Number of judges : Coordinating three judges by email is an inconvenience. Coordinating twenty judges across different time zones turns into a second job just to track who has and hasn’t responded.
- Multiple categories or rounds : The moment a program adds a shortlisting round before a final round, or splits entries into ten categories each with different judges, a single spreadsheet stops being able to represent the process without a dedicated person maintaining it constantly.
- Accountability and fairness : As a program gains a reputation, “we track conflicts of interest by remembering who knows whom” stops being good enough. Manual processes have no built-in way to prove, after the fact, that a judge didn’t see an entry they should have been excluded from.
None of these are software problems at a small scale. They're organizational strain problems that software happens to solve well, because software is built to do the same structured task correctly at any volume, without a person having to hold the whole system in their head.
The real trigger, in practice
Organizations rarely go looking for software because they woke up one day wanting new technology. They go looking because something specific broke: a judge scored the wrong batch of entries, a winner was announced with a typo in their name because a spreadsheet cell got miscopied, or a program simply outgrew what one coordinator could track manually before a deadline.
Recap
- The manual way works well for small, simple programs.
- It breaks down at four pressure points: volume, judge count, rounds/categories, and accountability.
- These are organizational strain problems, not technology problems.
- Most organizations start looking for software after a specific, concrete failure, not a general upgrade impulse.
Quick check
Regardless of what a program is called, the design questions behind it are mostly the same:
1. A manual process working fine at 15 entries most commonly starts to strain at which point?
2.What is described as the real, practical trigger for most organizations to look for software?
3. Manual processes have no reliable built-in way to prove conflicts of interest were handled correctly
4. Why does software help at scale, according to this section?
Part 2: Competitions
01
What Is an Award, Competition, or Evaluation Program?
The many names these programs go by, and the single shape they almost all share.
5–8 min read
If you're reading this, chances are someone in your organization has recently said some version of "we should really recognize the best of what we do." That instinct, wanting to spot, celebrate, or fund the best work in a field, is the starting point for every award, competition, grant, or evaluation program that has ever existed. Before we talk about software, timelines, or judging panels, it is worth pausing on what these programs actually are, because the label changes far more than the substance.
In plain terms: An award, competition, or evaluation program is any structured process where people submit work, ideas, or applications, and a group of reviewers assesses those submissions against agreed criteria to select winners, recipients, or approved entries.
The same shape, many names
Despite the different names, most of these programs share the same underlying shape: someone submits something, someone else reviews it against criteria, and a decision gets made. Once you see that shape, the different labels start to look like variations on a theme rather than separate categories:
- Awards and competitions. Recognition-focused programs, from industry excellence awards to creative contests, where the prize is prestige rather than funding.
- Grants and scholarships. Funding-focused programs where applicants compete for financial support against a defined set of criteria.
- Abstracts and papers. Academic or professional submissions reviewed by peers before a conference presentation or publication.
- Tenders and bids. Procurement-focused processes where businesses compete for a contract by submitting a proposal.
- Talent and speaker selection. Programs that choose people, not just projects or ideas, for a stage, a role, or an opportunity.
- Hackathons. Time-boxed team competitions built around creating something new within a fixed window.
- Public voting. Recognition decided partly or fully by open audience input rather than a private panel alone.
It is common for one organization to run several of these at once. A professional association might hold an annual awards program, manage a scholarship fund, and open a call for conference abstracts, all in the same year, often with the same small team behind all three.
Why the label matters less than the process
Regardless of what a program is called, the design questions behind it are mostly the same:
- Who is allowed to participate?
- What are they asked to submit?
- Who reviews it, and what are they reviewing it against?
- How is a final decision reached?
- How does someone find out the result?
These five questions apply whether you are running a Fortune 500 employee recognition program or a regional student science fair. In the next section, we will look at why organizations choose to run these programs in the first place, since the reason behind a program shapes almost every decision that follows it.
Recap
- An award, competition, or evaluation program is any structured process where submissions are reviewed against criteria to reach a decision.
- The names differ but the underlying shape is usually the same.
- Some programs are decided by an appointed panel, some incorporate public voting, and some use both.
- One organization can run several types of programs at the same time.
Quick check
Regardless of what a program is called, the design questions behind it are mostly the same:
1. Which of the following is NOT one of the shape elements shared by award, grant, and competition programs?
2. A university collecting short research summaries before accepting full conference papers is running what kind of program
3. True or false: a single organization can only run one type of recognition or evaluation program at a time.
4. Which of these is NOT one of the five core design questions from this section?
02
Why Organizations Run These Programs
Four recurring motivations — and why the dominant one shapes every decision downstream.
5–8 min read
Section 1 covered what these programs are. Before we get anywhere near software, it's worth spending one more section on why an organization decides to run one in the first place, because the reason behind a program quietly shapes almost every decision that follows it: who you invite to judge, how public the process is, even what "winning" is supposed to mean.
In plain terms: Organizations run award, grant, and evaluation programs for one of a few recurring reasons: to build visibility for their brand or community, to identify and support talent or work worth funding, or to hold their own field to a shared standard. Most programs are really pursuing more than one of these at once.
The same shape, many names
Despite the different names, most of these programs share the same underlying shape: someone submits something, someone else reviews it against criteria, and a decision gets made. Once you see that shape, the different labels start to look like variations on a theme rather than separate categories:
- Visibility and brand building : An industry association running an annual excellence award is also creating a reason for the whole industry to pay attention to them once a year. The program becomes a marketing asset as much as a recognition exercise.
- Community and engagement : A photo contest or an internal employee recognition program usually optimizes for participation itself, the entries matter less than the fact that people showed up and took part.
- Talent and work identification : Grants, scholarships, hackathons, and talent searches exist to find something specific and back it, so the review process carries real weight because the decision has consequences beyond a certificate.
- Setting or defending a standard : Peer-reviewed abstract programs and accreditation-style evaluations exist to hold submissions to a bar, not to generate excitement. The goal is making sure whatever gets approved actually meets the standard.
Most real programs blend two or three of these. A scholarship program is clearly about identifying talent, but it's also a visibility and engagement play for the foundation funding it. A corporate awards program is community-building on the surface, but the winners often become case studies used for external marketing later.
Why the reason matters for everything downstream
Once you know which of these four an organization is actually optimizing for, a lot of design questions answer themselves. A program built for visibility usually wants a public gallery of entries and a splashy announcement. A program built for funding decisions usually wants confidentiality and a much stricter judging process. A program built for engagement can tolerate looser judging criteria, since the goal is participation, not precision. A program built to defend a standard cannot.
Getting this wrong is a common early mistake: organizations borrow the judging structure of a prestige awards program (multiple expert rounds, strict confidentiality) for something that was really meant to be a fun, high-participation engagement exercise, and end up with a slow, over-engineered process that discourages the very participation they wanted.
Recap
- Organizations run these programs for one or more of four reasons: visibility, community engagement, talent or work identification, and standard-setting.
- Most real programs pursue more than one motivation at once.
- The dominant motivation should drive decisions about confidentiality, judge expertise, and how public the process is.
- Borrowing the wrong program’s structure for the wrong motivation is a common and avoidable early mistake.
Quick check
Regardless of what a program is called, the design questions behind it are mostly the same:
1. A corporate program built mainly to generate case studies and press coverage is optimizing for which motivation?
2. Which motivation typically demands the strictest confidentiality?
3. Most real-world programs pursue only one of the four motivations at a time
4. What is the most common mistake described in this section?
03
The Manual Way, and Why It Breaks Down
Spreadsheets and inboxes work — until volume, judges, rounds, or accountability arrive.
5–8 min read
Every program in Section 1's list can be run without software. Award programs existed long before online submission forms did, and plenty of smaller programs still work off email and spreadsheets today. This section is about why that approach works fine at a small scale, and why it reliably breaks down as a program grows, since that breaking point is usually the exact moment an organization starts looking for software in the first place.
In plain terms: The manual way means collecting entries by email or shared drive, tracking them in a spreadsheet, and coordinating judges by sending files back and forth. It works because it's flexible and free. It breaks down because none of those tools were built to manage many people doing the same structured task at once.
What "manual" actually looks like
The strain doesn't show up gradually, it tends to show up all at once, usually tied to one of four pressure points:
- Volume : Fifteen entries is a spreadsheet. Three hundred entries is a full-time data entry job, and every manual retype is a chance for a score or a name to get mistyped.
- Number of judges : Coordinating three judges by email is an inconvenience. Coordinating twenty judges across different time zones turns into a second job just to track who has and hasn’t responded.
- Multiple categories or rounds : The moment a program adds a shortlisting round before a final round, or splits entries into ten categories each with different judges, a single spreadsheet stops being able to represent the process without a dedicated person maintaining it constantly.
- Accountability and fairness : As a program gains a reputation, “we track conflicts of interest by remembering who knows whom” stops being good enough. Manual processes have no built-in way to prove, after the fact, that a judge didn’t see an entry they should have been excluded from.
None of these are software problems at a small scale. They're organizational strain problems that software happens to solve well, because software is built to do the same structured task correctly at any volume, without a person having to hold the whole system in their head.
The real trigger, in practice
Organizations rarely go looking for software because they woke up one day wanting new technology. They go looking because something specific broke: a judge scored the wrong batch of entries, a winner was announced with a typo in their name because a spreadsheet cell got miscopied, or a program simply outgrew what one coordinator could track manually before a deadline.
Recap
- The manual way works well for small, simple programs.
- It breaks down at four pressure points: volume, judge count, rounds/categories, and accountability.
- These are organizational strain problems, not technology problems.
- Most organizations start looking for software after a specific, concrete failure, not a general upgrade impulse.
Quick check
Regardless of what a program is called, the design questions behind it are mostly the same:
1. A manual process working fine at 15 entries most commonly starts to strain at which point?
2.What is described as the real, practical trigger for most organizations to look for software?
3. Manual processes have no reliable built-in way to prove conflicts of interest were handled correctly
4. Why does software help at scale, according to this section?