Skip to content
Digit's Guide to Making Decisions
Share
Explore

Digit's Guide to Making Decisions

Durable, Documented, and Reliable Decisions

Copy this doc and use our
to make great decisions!

Copy doc

Introduction to Digit

Most Americans don't have enough money put away for a rainy day. At
, we're working to change that. We want to eliminate the stress and anxiety people feel about their finances so they can focus on what’s most important in their lives. We first mastered saving for people's near-term goals, helping our members automatically save over $5 billion. Now, we are harnessing our groundbreaking technology to give our members an automated smart financial assistant to manage all of their personal finances.

Making Decisions

We believe in making good, durable decisions at Digit. Durable decisions should remain unchanged unless key inputs or assumptions change. We may get some decisions wrong; that is okay as long as we understand the context behind our decision, what we got wrong, and how we could do better in the future.

We also believe in transparency and rigor. We achieve these goals, with the aim of making durable decisions, through written documents, asynchronous debate, and public posts about decisions and their follow ups.

We are believers in the
. In particular, this document is aimed at Drivers of a decision.

The short process of making a decision at Digit:

The driver writes a decision document and shares with stakeholders.
We review the decision asynchronously through slack or in “office hours”: a meeting with key stakeholders and our executive team.
We either reach a decision or ask for follow-up information. In the latter case, we repeat.

image.png

Not all decisions require this degree of rigor. We want to empower individual teams to make their own calls, especially for reversible decisions. We
require
this degree of rigor for Irreversible decisions and expect to spend time on them as a company.

This document is aimed at detailing out all the steps that enable decision making at Digit.


1. Write a ‘good’ decision document

Digit has a strong documentation culture. We use documents as our primary communication tool for recording facts, laying out options, driving decisions. Writing a good document requires thinking about 3 main components:

A. Document structure
B. Document substance
C. Document formatting


A. Document structure

Jump to the


Start with a clear and succinct recommendation.

This lays out where you stand on a particular decision and does not leave the reader hanging.

image.png


Have a “goal/ non-goal section” upfront

A goals section makes it clear what the meeting or review is about. This helps us maintain focus and keep things on track.


image.png

Make the DACI explicit

Upfront DACI aids in decision making and helps participants know their roles. Read more in
.

image.png

Explain the What, Why, and How

What
is a factual understanding of the world. We lay the groundwork by bringing everyone up to speed on what we know.

Why
are the reasons that explain the what.

How
is our methods or alternatives to fix the problem.

Mindmaps are a great tool for a visual representation of complex problems.

image.png

Further reading: [
,
]


Have a feedback section in the end for questions/ discussion

Long debates in comment threads are difficult. Our way of having these discussions is to create a section at the end of the document where people can put in their questions, get them answered, or comment on others’ questions and have a right, asynchronous discussion. This also helps record all the viewpoints in one place to be reflected later incase of a change in decision.

image.png

You can copy the template to make your own decision documents


B. Document substance

Present all the options considered

Bring your audience along by showing all the options considered. Tables are a good way of representing two dimensional data. Narrative form is an acceptable form as well.

image.png


Add supporting data and analysis to back-up the recommendation

Any recommendation should be followed by data and analysis that went into making that recommendation. Analysis can be quantitative or qualitative (e.g. reference checks, industry benchmarking, user feedback, and user studies.)

image.png


Key stakeholders should have vetted the recommendation

For example, if your decisions needs engineering to implement something, relevant engineers should not be surprised in an office hours review or find out about your recommendation is made. Additionally, when decisions require work from other teams, do the homework of estimating the time or complexity of the demand. As a simple rule of thumb make sure that all the “contributors” from your
have vetted the recommendation.



C. Document formatting

Use heading hierarchy and sections and separate out a large document

Using proper H1, H2, H3 formatting creates automatic indexes in Coda. It makes our documents consistent and easier to read.


Use colors judiciously

Colors can help highlight complicated tables or parts of dense documents. However, remember that the focus is on making a
good
decision, not on selling
your
option.

A good use of colors is to highlight cells in a table that are positive, neutral, and negative.

A poor use of colors is highlighting entire paragraphs so that they stand out in contrast to others. This significantly reduces readability.


Use tables, miro charts, images

The goal is to help people understand what you know and your reasoning. Visual aids can make a significant positive difference. Use all the tools at your disposal to easily grasp the document.



2. Sharing and Review

Once you have written out a decision document, the next step is sharing it with the decision makers and contributors, soliciting feedback, and making a decision.

All decisions require async sharing. Some decisions may need a live meeting. We leave it to the Driver’s judgement to request a live meeting. A lot of back and forth commenting and feedback in your doc is a good sign that you should probably do a live meeting to get everyone on the same page.

We prefer doing things async. The general rule of thumb if the decision is simple, doesn’t require a lot of discussion and there is already stakeholder buy-in for the recommendation then use the async route for document review.

While there are multiple styles of running office hours, some common do’s and don’ts of running a successful outline are presented below

Send your decision document at least 1 day before your meeting

This gives people ample time to read and internalize the doc, and activate their slow brain. If you’re not seeing sufficient feedback, nudge key participants to add feedback and questions ahead of the meeting. We use a simple text feedback section at the bottom of the doc.


Prepare

Answer as many simple questions as you can async. Read through the more complex questions and focus on the contentious or difficult feedback and questions in the live meeting.


Keep the meeting focused

In any live meeting, people will bring up ancillary points and the discussion may meander toward things that are tangential or are non-goals. Your job is to keep the discussion focused on the goals of the meeting.


Push the ‘approver’ to come to a decision or ask for clear follow-ups/ action items

Ensure you don’t leave the meeting without a clear decision or a clear set of follow up tasks.


Don’t be married to your recommendation

Set your ego aside to reach the best decision for Digit, even if the decision is different from what you initially suggested.



3. Record the decision

Outcome of an office hour or async review is usually either a follow-up request for more information or a final decision.

Once you reach the stage of final decision, update your document with the final decision. Share a summary of the final decision in the #officehours slack channel for broader visibility.



Author

is the Head of Product Operations at Digit. She has spent most of her professional life helping increase access to financial services through technology. She is interested in all things FinTech innovation and strategy.

Acknowledgements

This work would not have come together without the contribution and guidance of
(Chief Product Officer @ Digit),
(General Counsel @Digit) and
(Product leader at Coda). Thank you for your all your edits, suggestions and review.





Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.