- In this piece, you'll learn
- Why good notes are a competitive advantage for engineers
- Build meeting notes for transparent record keeping
- Create your database
- Add views for teams or projects
- Create templates for every meeting type
- Build a docs database for your processes, policies & plans
- Make a Docs list
- Views to visualize your workflow
- Templates that standardize quality
- See Meeting Notes & Docs in action
- Next steps
- Link to notes from your engineering homepage
- Connect your meetings to tasks & projects
- Get your whole team in the habit
High-output engineering teams make good documentation a habit. They take detailed notes in meetings so that every decision has context. They attack problems methodically in writing. They solicit feedback asynchronously to get to the best solutions.
The problem with documentation is that — in the absence of a system — it can be a lot. A lot scattered across multiple tools, folders, repositories, emails, and uncategorized Google Docs. What's lost can't be learned from. It can't make your team stronger.
That's why we're sharing these two tools. Our team uses them, as do dozens of others, to give notes structure, make them easy to find, and — most importantly — make them useful.
In this piece, you'll learn
Build a Meeting Notes database to give everyone time-saving, morale-boosting visibility
Build Docs to make all your specs, proposals, research, etc. collaborative and searchable
Customize both to your team's needs and workflows
Here's how your notes and docs could look:
Why good notes are a competitive advantage for engineers
What earns someone the coveted title of "10x engineer"? They ship with speed and quality. Not just sometimes — consistently. This requires repeatable systems for higher order thought.
Good notes help you go faster 🏎
They're easy to find so you don't waste time hunting for information.
They're structured so you can extract value with a quick skim.
They give you a record of what's been tried and what works — so you don't duplicate effort.
Good notes make your work better ⭐️
They capture your ideas so nothing gets forgotten.
They give you a place to think deeply about problems, implications, edge cases.
You can share to get clear feedback from the right people.
When note-taking is foundational to your engineering culture, you 10x your team's productivity. In a world where the fastest team that delights users wins, this is nontrivial.
Build meeting notes for transparent record keeping
Meeting notes make every standup, sync, and session impactful for your entire team when they follow these rules:
Good meeting notes are comprehensive and action oriented. They make it possible to go back and consult any conversation. And they surface to-do's that propel your team forward.
They're organized so anyone can reference them. New employees, teammates out sick, or people from marketing or support can understand them and why they matter.
They're open and central so no one is left in the dark. Engineers don't distract each other with questions that already have answers, and there are no politics around who knows what.
Ok, so they're helpful. But how do you build a good home for them?
Create your database
Here are best practices for setting up your meeting notes:
Create a list database — Add a new page in your sidebar and choose
Listfrom the menu. It's the most minimalist database view for easy focus. Every page inside it can be a meeting.
Add properties — For every set of notes, you can assign properties that show attributes like when the meeting took place, who was there, and what type of meeting it was.
Propertiesat the top right of your list, then
+ Add a property.
Choose the property type and give it a name, like Participants for a
Personproperty to tag who was there, or Date for a
Created timeproperty that adds a time stamp, or Type for a
Selectproperty to tag standup, weekly sync, sprint planning, post mortem, etc. You could even have a
Selectproperty called Team if you wanted to tag meetings by engineering sub-team — like mobile, desktop, internal tools, etc.
Create and customize as many properties as you want. Learn about all property types.
Hide/show properties — Only view the properties you want to see in your list. Maybe you only want to see date and time created. Click
Propertiesagain and switch on the ones you want.
Add views for teams or projects
Notion makes it possible to view the same database many ways — as a table, Kanban board, calendar, filtered by properties, etc. You can add multiple versions of your information in one place and switch between them instantly. No need to re-create content or re-apply filters.
+ Add a Viewat the top left of your meeting notes list.
Choose the type of view you want to add. For example, choose
Boardto see your notes grouped by meeting type or by sub-team.
Listagain and apply a filter. Let's say you want a list of only weekly syncs. Create a new list view, then hit
Filterat the top right and set the Type property to Weekly Sync. Now you can toggle between all meetings and just syncs. Do the same thing to filter out meeting notes from before a certain date (a nice way to archive old docs).
In this 4-minute video, we cover everything you need to know about database filters.
Create templates for every meeting type
A note-taking system is only as good as the notes it contains. The highest utility notes have clear sections with headings, record who said what, break out a checklist of action items, and provide enough context so anyone can understand what took place without asking.
In Notion, you can use database templates to generate the right format for every type of meeting:
To add a template, click the down arrow to the right of the blue
Newbutton at the top right.
+ New Templateand add the structure you want in the page that comes up — whatever headers or properties you want when you create a new meeting next time.
Next time you add a meeting, click that same dropdown and choose the template you want.
For engineering team meetings, here are some suggested templates:
Add all the usual participants in that property field — they'll appear there automatically
Add the Standup tag in the Type property
In the body of the page, add four
What did we do yesterday?
What are we doing today?
Action items (with a checkbox underneath)
Add the Sprint Planning tag in the Type property
Sprint Goal — What you want the sprint to accomplish
Sprint Backlog — Items you're committed to working on during the sprint
Teams & Roles — Scope of responsibility for each person
Notes — For the content of the meeting you capture
Consider adding one line of text under each explaining what the section is for in gray
To assign responsibility use
@to mention the name of the owner
Add the Post Mortem tag in the Type property
User facing impact — How did this incident affect users and how many?
Timeline — How did the project or issue unfold and who responded?
Relevant metrics - Paste in graphs, links to Slack threads, etc.
Notes — Actual discussion during the meeting
Cause analysis — Dig deep into why the incident happened.
Resolution — How was the incident resolved? What did we do well in response? What can we do better next time?
Future work — How do we prevent this incident in the future? If a short-term fix was implemented, what is the long-term fix?
Consider adding a table of contents with
/tocat the top. These notes can get quite long and this lets you jump to the part you need.
Add text under each heading to explain what that section is for so more people can use this system on their own.
Each of these setups is designed to push your team to think deeply, communicate regularly, stay aligned around goals, and help each other improve — as engineers and as a group.
Build a docs database for your processes, policies & plans
There's a second type of note taking we'll cover here. We'll call these as Docs — writing that codifies policies, proposes changes, specs out features, reviews tool options, sets rules for the codebase, provides guidance, and more.
Better error reporting — A proposal for a new process
Full stack engineer onsite interview — A rundown of questions to ask candidates
Testing for infrastructure team — A description of the testing framework
Architecture brainstorm — Evaluating all options to scale a feature
Engineering manager transitions — A doc about how promotions work
Just like an office is a physical environment that defines your work, these docs provide a digital environment that does the same. Reading through these can teach any newcomer how you operate, what's important to you, decisions you've made and why.
Now, here's how to build this open book for engineers past, present and future.
Make a Docs list
Just like you did for meeting notes above add a new list database to your workspace.
Your properties should be different. Use them to capture more metadata that will be helpful about each doc. We suggest:
Selectproperty labeling the document as a certain type, i.e. Technical Spec, Project Kickoff, Architecture Overview, Request for Comment (a.k.a. RFC - more on this soon), Planning, Reporting, Research, Data Analysis, etc.
Selectproperty indicating whether further action is needed on the doc. Tag options could be In Progress, In Review, Implemented, Open for Comments, or Archived
Created time — So you know when the doc originated
Last edited time — So you can see when it was last changed or updated (gives you a good sense of what's still important or stale)
Created by — Records the creator so you know the point person
Last updated by — So it's easy to track down who worked on the doc last
Reviewers — So the creator can tag stakeholders whose eyes they want on the doc
Selectproperty to give everyone the sense of urgency (or lack thereof)
You don't have to show all these properties in your list. Hide the ones that aren't important to understand at a glance.
With all this context, every doc is easy to find and understand immediately.
Use the search field at the top right of your database to jump to the information you need.
Shared documentation can make your team's output better. And it's even more powerful when you share a Docs database with your whole company — you'll get a variety of opinions that could open new perspectives.
Get more feedback more efficiently with an RFC practice
Views to visualize your workflow
There are a few database views that are especially helpful for engineering Docs:
By Type — Create a Board view grouped into columns by Type so you can see how many docs are in each category. Easily access all team policies, all specs, etc.
By Status — Board view so everyone can see where docs are in your process. Maybe something's been stuck in backlog forever, or you need one more round of feedback.
By Creator — See all the docs created by individuals across your team. Let's say you're coming up on annual reviews, you can get an instant sense of people's contributions.
Only my Docs — Create a new list view and filter it by the Creator property. Choose yourself to see only the docs that you created in one convenient spot.
Only Engineering — If your Docs database is open to your entire cross-functional org, you can add a filtered view that only shows docs created by and for engineering.
Customize your Docs views in ways that are helpful for completing a task and understanding information quickly.
Templates that standardize quality
Just like database templates can help you cover your bases during different types of meetings, they can enforce quality and comprehensiveness of thought in your Docs.
For instance, as you spec out a new product feature — it's tempting to jot down rough ideas and start building. The right template can force you to pause, carefully articulate the problem you're trying to solve, identify the metrics you want to move, support your hypotheses, and work through edge cases.
This is how you get to consistent quality of execution across a growing technical organization.
Here are some template recommendations for engineers:
Add RFC to the Type property
Problems — List all the problems that could be solved by this feature.
Research — Aggregate qualitative research from user studies and quantitative research from your dashboard tool.
Solution — Describe what you want to build and add images (or embed Figma files) of prototypes.
Process — Walk through the design thinking process that led to the solution.
Consider adding gray text underneath each heading with instructions for that section so people who are new the system can easily use it.
Whenever Docs are used to make decisions, it's always critical to capture the rationale for the choice made so that future reviewers can understand it, and new employees can pick up philosophies that shape how the team runs.
Add Technical Spec to the Type property
Summary — 1-2 sentences about the doc and its purpose
Background — What is the motivation for these changes? What problems will this solve? Include graphs, metrics, etc. if relevant.
Goals — What are the outcomes that will result from these changes? How to measure?
H3heading for Non-goals - What won't this proposal accomplish?
Proposed solution — Describe the solution to the problems outlined above.
Follow-up tasks — What needs to be done next for this proposal.
H3headings under Proposed Solution:
Risks — Highlight risks so reviewers can direct their attention here.
Milestones — Break down the solution into key tasks and estimated deadlines.
Open questions — Ask any unresolved questions about the proposed solution here.
Consider adding a table of contents at the top to jump to the right section fast.
Add Project Kickoff to the Type property
Add the following sections with
Overview — What is the project? Why are we working on this?
Success criteria — 1-3 sentences on what success for the project looks like. Include metrics and qualitative descriptors if relevant.
User stories — What will the user be able to do after the solution is shipped?
Scope — Define what will be done and what will not be done as part of this project.
Add Architecture Overview to the Type property
And create the following sections with headings:
Description — Describe the software component. What does it do?
Diagram — Include a visual if it's helpful.
Client — Describe relevant codepaths in the client codebase.
Server — Describe relevant codepaths in the server codebase.
Database — Describe relevant tables and views in the database.
We designed database templates to make it fast and simple to create content over and over again. But the real value is actually shaping your process. As you scale your team, nothing can give you more leverage than making it second nature for everyone to make good decisions on their own.
See Meeting Notes & Docs in action
Not specific to engineering, but this video can give you a basis to make your own systems.
Just 9 minutes of watching for a future of good note taking.
Now that you have these databases up and running. There are a few things you can do to make them more powerful.
Link to notes from your engineering homepage
One of the benefits of managing everything in Notion is that you can create homes for every team inside your organization. Engineering can have its own page organized exactly the way they want — here's how to build that kind of wiki.
Put your engineering team's meeting notes and docs a click away from the rest of your work by nesting them inside the same page.
Connect your meetings to tasks & projects
If you also have your engineering projects in Notion, you can create a relation between any one project and all the meeting notes about it, or all related docs.
In your meeting notes database, add a new property, choose
Relationfrom the type menu and call it
Project. Choose your projects database in the menu that pops up.
For every set of notes, click on that property field to add the project you discussed.
Now, when you open a project page, you'll see all the meeting notes neatly organized and accessible. It's a two-way, automatic sync.
Get your whole team in the habit
Bringing any new system onto your team takes time. But once routines are built, they'll have an outsized impact on how you all think and work together. Here are some ideas to ease the way:
Hover over the top of your database and click
Add Description. Create quick instructions for using any system for all to see.
Create database views relevant to your teammates in advance of sharing with them so they can see the value for their own work.
For example, you might create views for mobile or infrastructure sub-teams to see only notes from their meetings.
Demo the convenience of database templates. Whenever you start a new meeting, share your screen with the group, apply an instant template, and take notes in real time.
When your team sees how these tools eliminate busywork and help them focus, they'll come aboard and you can start reaping the compounding benefits of healthy documentation.
Something we didn't cover?