Remry is out. It’s a free, local notebook that Claude keeps for you. This post is the longer story of why it exists - the one I’ll point to when someone asks “why not just use Notion?”

I oversee six teams. That’s a lot of people, projects, goals and half-remembered 1:1 conversations to carry around in one head. And I’m terrible at planning ahead.

That combination is the whole reason Remry exists. Before a meeting I don’t have time to work out where a note should go according what I set up three months ago. I need to say the thing and have it land in the right place. Then, when review season comes round, I need it all to be there.

I tried the obvious tools first.

Starting with Notion

I started in Notion, and I still think it gets a lot right. I ran a Notion workspace for 300+ people, so I can say I was something of an authority.

For me, most of Notion’s value is in a few things:

• Databases: A person, a project and a goal are records with fields, and you can create, update and filter them like any other database.

• Relations and rollups: A project links to its owner, a team rolls up its projects, and you can see the whole thing from either end.

• Peek: Open a record in a side panel without losing your place in the list. It’s the feature I missed most when I left.

The trouble is that it needs to be built and maintained , and is meant for a team. For one person it’s too expensive and frankly, overkill.

Obsidian: local, but DIY

So I moved to Obsidian. A few things won me over:

• Local-first by default. Your notes are files that never leave your computer. This is important from an enterprise security perspective when selecting tools. And it matters more than it used to - more on that below.

• Markdown first. Everything is a plain markdown file, which any model can read and write. That’s why Obsidian has been the default for LLM wikis so far.

• The Excalidraw plugin. One of my favourite things about it. Although Excalidraw is available pretty much everywhere now.

But Obsidian is basic, even with all its plugins. A page is a markdown file, and seeing anything useful about a person or a project means hopping between files and hoping the links hold up. I don’t want to hop between pages to find all the relevant info.

It’s also finicky. You build everything yourself - the folder conventions, the templates, the Dataview queries, the plugin combinations that work until one of them updates. I don’t have time to maintain all that while running six teams.

And no, Confluence and Google Docs weren’t the answer either. Both are deeply awkward - fine for the team’s shared documents, painful for keeping your own structured view of things.

What I actually needed

By this point the list was pretty clear:

1. Batteries included: People, teams, projects, goals and docs, already there and already linked. No templates to design, no plugins to babysit.

2. A structure I already know works: Running that 300-person Notion workspace taught me which structures hold up - permanent docs vs. temporary plans, everything tied to an owning team, a snapshot view for leadership. Most businesses end up with something close to that pattern, so I built it in rather than making everyone rediscover it.

3. More on one page: A person’s page should show their lead, their teams, their todos, my dated notes and the docs that mention them. Plus side-peek - that was amazing.

4. Local-first: Security is tightening everywhere, and it’s strictest at bigger companies. Those are also the places where someone overseeing several teams needs a tool like this. Files on your own machine, no accounts and no sync is a much easier conversation with a security team.

5. A proper view of my reports: Goals can sync in from wherever the team tracks them, and they sit next to my own notes and observations. When review time comes, most of the digging is already done.

That last one is the one that saves me the most time. Writing reviews used to mean an evening of scrolling back through months of notes. Now it’s a prompt.

So I built Remry

We’re in a markdown-first world now. Every model reads and writes markdown well, and that’s a big part of why most LLM wikis so far sit on top of Obsidian. I wanted to keep that, and add a better way to organize and connect the files. Plenty of people have had a go at this - see any of the second brain wikis out there.

Remry is my take. It’s a local notebook with the structure built in, and Claude does the filing over MCP. Before a meeting I say “note that Dana wants to lead the migration, remind me to book a 1:1” and it lands on Dana’s page - dated, in my words, with the todo above it. I don’t have to remember where things go, that’s delegated out now.

So it’s Notion’s databases lovable UI, on Obsidian’s local markdown files, without the setup, using a format I know works for most organizations. Which is roughly what I’d have asked for two years ago, but now I can build fast, and exactly how I want it.

Summary

• Notion has the right ideas - databases, relations, rollups, peek - but it’s too expensive and too much for one person.

• Obsidian is markdown-first and local-first, and has Excalidraw. But it’s basic and very DIY.

• Confluence and Google Docs are awkward - enough said.

• Remry is a local, batteries-included notebook built for the classic org structure, and Claude is the one keeping it organized and up to date.

This is the first public release, so a few rough edges: the Mac build is Apple silicon only, Windows will show a warning because the installer isn’t signed just yet (incoming shortly!), and the code is source-available (FSL), not open source. If setup trips you up anywhere, open an issue on GitHub - that’s what I’m fixing first. For anything else, there’s the contact form.

If you carry a lot in your head too, download Remry. To follow along as it changes, subscribe to the newsletter.

This was originally published in 2024. A lot has changed since then.

As Director of Engineering, when we were fully remote at the height of Covid, I realized our documentation was woefully inadequate and in dire need of structure and direction. We’d see proposals that laid out four solutions, with options scratched out and critical information buried in comments - and this was what people were expected to reference when figuring out how something worked. According to DORA, good documentation is one of the foundations of better organizational performance, so we decided it was time to improve what we had.

We looked at Confluence and Notion, and happily settled on Notion for its cleaner UI and the incredible flexibility it provided. The ability to use databases to dynamically link content across the workspace while still preserving the source of truth proved invaluable. Also, the left navbar - being able to see everything from a centralized location is remarkably underrated, something not available by Google Docs or Confluence.

Our Notion workspace was a huge success, with 300 daily active users at a company of 600, and minimal complaints. There was feedback early on, but once we reorganized the workspace around our domains (more on that below), that feedback disappeared. Different groups had their own domains to work within, teams weren’t stepping on each other’s toes, and we were able to accomplish innovative things with the tools Notion provided, like building a software hygiene catalogue (similar to Backstage) for the different services our teams managed.

The workspace was built on a relatively simple foundation with two ideas: separate documents based on whether they are permanent or temporary, and tie every document back to the team that owns it. Through the power of databases, it scaled nicely with our growing organizational demands. Notion was eventually sunset in favour of Confluence, to bring documentation closer to the rest of our Atlassian tooling, but the ideas behind the structure apply whatever tool you use.

Sharing my learnings

Below, I’ll walk through a documentation template based on what I learned rolling out our workspace: the overall structure, each section’s purpose, and the gotchas I encountered. A small team can use it as a proof of concept and expand from there. See the Getting Started section for a more in-depth look at the structure and practices that made it succeed.

Along the way, I’ll point out five principles that made the system work: timeliness, feedback loops, reporting, audience and dashboards.

This template has a few bonuses, including:

• An area to measure and track projects

• Page templates with prompts for things you might not have considered

• A database to catalogue your internally built software. We had a similar database in place, which helped clarify ownership, add supplementary information, and manage our software’s hygiene

The structure

Getting Started

Getting Started was where the general guidelines (including what lived where), best practices and governing principles lived. Any good software project has a README that gives people a sense of how to work within its structure. This was the workspace’s README.

Wiki

This was where the meat of the information lived, and it required the most governance. It held the current policies, reference materials and diagrams: the state of the world as it related to the domain. It was important to have something centralized like this, because otherwise these docs got buried in team-specific pages or, worst case, in private pages.

We set the wiki up as a set of databases with the parents containing a relations to the owning teams and applied software services and products. Because pages can be infinitely nested, it became a well organized drill-down of all the documents needed relating to a specific service. This way, we could tag articles and sections with the relevant teams to provide backlinks to their team pages, with filters liberally applied as needed. Any other tags or categories could be added to make governance and visibility more straightforward.

One of the most important principles when deciding what lived in the wiki was timeliness: was it a permanent document or not? If it was a permanent doc (true today, tomorrow, and next year) and was relevant beyond a specific team, it probably belonged here.

Our first attempt didn’t organize the wiki by domain, and that’s where most of the early feedback came from. We work with white-label products, so we split the wiki into “conceptual” and “reality”. One area described our products, services and policies, with the product and architecture as designed. Another area covered the deployed instances, what we call storefronts: the reality. It made sense on paper, but to understand one product you had to piece it together from two places, and this model didn’t even apply to other products at all. Instead, we made it domain driven: here’s the product, and here’s all the information around it, from the architecture to each deployment.

Projects

Projects were the opposite of Wiki docs. They were speculative, used for planning, and only relevant for a short period of time. Remember those proposals with four solutions and critical information in the comments? That was fine for a project. It wasn’t fine as the place people went to understand how something worked. All information about the actual implementation belonged in the Wiki.

Anything in Projects was meant to be relatively short-lived. When a project was done, the team moved what was actually built into the Wiki. This was our feedback loop: documentation was part of the software lifecycle, not something written after the fact. Success depended on the team, but the teams who did it well reaped the benefits of clearer docs and better support flows.

Snapshot

This was where we could see the state of the organization at a high level: the health of services over time, the state of projects, and the capacity of projects. It was designed for a leadership point of view, and covered reporting for anyone not part of day-to-day operations. Some organizations would keep this private, but transparency was important to us. Keeping it publicly visible followed our “write in public” principle: unless something was sensitive, write it where everyone could see it.

People & Teams

The pieces above weren’t groundbreaking; methods like Tiago Forte’s PARA cover similar ground. People and Teams was where this structure set itself apart, by giving every doc an audience. With these two databases, we could break out projects and wiki items and associate them with their respective teams. People provided granular information about who was on a given team, and Teams tied any piece of documentation to its owner. In Projects, an Involved Teams field showed who was working on what. From there, we could filter projects to only the relevant teams, shielding them from the noise of the centralized structures.

The Teams database also gave teams a space for their team-specific docs: working agreements, code standards, support processes, team policies and onboarding guides. Some teams built comprehensive, complete dashboards to manage their product and software work.

The one gotcha was the tendency to use team pages for everything, including permanent docs that were relevant beyond the current team. This undermined the entire system, and it’s where our workspace architects spent most of their time, encouraging teams to put their docs in more widely observed spaces. The trick to tying this information back to the team page was dashboards: views on the team page that referenced those centralized documents (Projects and Wiki items). The docs stayed central, and each team still got its own dashboard.

Guiding principles

These were the foundations that made this documentation system work, and Notion made each of them possible.

Dashboards: We created dashboards everywhere, based on predictable, workspace-wide tagging. Documentation stayed central, and filters personalized it where each team would benefit most.

Reporting: We provided snapshots and reports for those who weren’t part of day-to-day operations, giving them a high-level view of progress across the org.

Audience: We used the Teams database to organize and tag groups as needed, and gave groups full ownership to work within their own domains.

Feedback loops: We integrated documentation into the software lifecycle. A proposal started in Projects, and once it was actioned, the parts that were still true moved out of Projects and into the Wiki. Because every stage of a document’s life lived in one place, nothing got lost moving between tools, and you could always trace a Wiki page back to the project that produced it.

Timeliness: We identified whether a document was temporary or permanent. Each was better served in a specific place (Projects and Wiki, respectively).

Takeaways

As you can see, it was a simple structure, but it accounted for everything we needed. Overall governance was restricted to a select few, but within a specific domain (product line, software, tooling, wiki sub-sections, team pages, etc.), permissions were granted liberally so teams weren’t held back and had the flexibility to create what worked for them.

Hope this helps with your documentation adventures! You can find the template here.

Update from just 2 years later, in 2026: with the rise of AI this year, documentation looks very different than it did in 2024 - some fundamentals stay, others are irrelevant.

More on that later.

Going into the new year, I’ve been giving goal setting some thought. As with most companies, growth is typically the number 1 concern. It makes sense - the point of a typical business is to bring in revenue and that usually happens through growth. I will dive into how these goals can be navigated by software engineering, a group whose work is often quite a few layers from a company’s typical commercial goals.

“Make it align with Product priorities” - No, the goals will be a balance of product priorities and engineering priorities.

The mandate to grow is usually driven by the commercial or product teams from directions on-high. However, in engineering it can be difficult to align priorities with that growth mandate. Engineering priorities don’t often directly relate to revenue generating activities, and are usually concerned with:

• Poor developer experience (DX)

• Tech debt

• Woeful test coverage

• Sunsetting legacy systems

• Minimizing the number of bugs created

These can be difficult to prioritize because at any company with a decent spread of functionality because the roadmap is relentless and unforgiving and engineering’s priorities don’t have visible impact on the end product.

The Big 3

As a general rule, there are 3 things that software engineering should care about: Business Value, Speed (Throughput), and Quality (Stability).

Business Value

AKA value-add to the user. This should always be the forefront of software and product teams. Engineers are sometimes lose sight of this end-goal: delivering value to the end-users. There are many books on this topic and it is why other departments often exist (i.e. Product). Product typically acts as the bridge between software and the business, or the end-users. They collect feedback, identify what works and what doesn’t, and use that information to strategize The Next Big Thing. Because value-add is directly tied with revenue and growth, it’s often the easiest to justify. However, in unbalanced orgs, the pendulum can swing too far in the direction of growth at all costs, and engineering’s priorities can fall behind.

When growth is covered by product or commercial teams, what is left for engineering to put on the table? That’s where you get to the meat of what engineering should be thinking of and prioritizing.

Speed (Throughput)

Speed can be articulated as “how quickly can this be validated”. This validation happens in a lot of different stages:

• local development

• test or staging environments

• end-user testing

• automated testing

• production deployments and releases

All of these culminate in the “developer experience”, but they’re actually saying: “how fast can I validate this change and deploy it”. It’s about getting the tooling and processes into a state where disruptions are minimized and out of the way of developing new functionality.

However, speed doesn’t tie directly into revenue initiatives and only has an indirect correlation: enabling quicker delivery. While important, this indirect relation makes it prone to being de-prioritized in the pursuit of high-growth.

The argument and measurements to getting tooling and process changes prioritized can usually be framed as: “Speed helps to deliver those revenue related items more quickly” and can be measured by however you measure velocity (pull request turn-around time, deployment speed, story points, etc).

Quality (Stability)

The third priority for engineering is quality: making sure the code is secure, resilient, maintainable and performant. The scope here includes (but is not limited to):

• Are appropriate security measures in place? i.e. holes found and addressed, outdated libraries updated, and code patched and hardened

• Is there sufficient monitoring and alerting for easy debugging and quick detection of issues?

• Is the service easy to deploy, scale and perform as needed? Does it have identifiable performance breakpoints?

• Is there documentation on how to use the service for all the relevant stakeholders?

• How often do pipelines or deployments fail (require remediation or result in service degradation)?

• What is the contextual load required to add functionality (code structure; systems architecture)?

These are all important things to consider, but it can be difficult to quantify their extent and impact. As far as I can tell, there is no universal way to measure quality; instead, there’s varied tooling for the different areas. When measuring quality, there are 2 important signals that arose from research in the area of engineering productivity: Production Change Failure Rates and Mean Time to Recovery (MTTR). They’re good signals for quality, but don’t tell you how to get there, so you’ll have to fill in the gaps along the way. Number of bugs can be useful as well - the average number produced should fall over a period of time if doing rudimentary software development and not making significant changes to the service, its infra or tooling.

I’ve seen internal self-assessments work to a small degree, but they’re largely qualitative, and lack effectiveness without appropriate business buy-in and consistent usage.

Industry Standards

Before going any further, I want to call out DORA metrics, as outlined by the Accelerate Book (video). DORA metrics represent the industry standard on how performant a software organization is. After extensive research, they boiled it down to these 4 primary metrics:

• Lead Time: The amount of time it takes a commit to get into production

• Deployment frequency: How often a group successfully releases to production

• Mean time to recovery (MTTR): How long it takes to recover from a failure in production

• Production change failure rate: The percentage of deployments causing a failure in production

What they’re really asking is, “How well are you doing continuous delivery”, the gold standard of software development.

As you can see, Quality and Speed are the main categories, as emphasized by DORA metrics. What’s needed is justifying those into roadmap planning. Notice that revenue and growth are missing? Those are in another domain altogether, which Product typically helps navigate and why engineerings should be advocating for Speed and Quality as the highest priorities.

Prioritizing these goals

How do you get these engineering priorities into the roadmap? It can be difficult since the number one priority is often revenue. Since it’s difficult to quantify revenue or growth with these goals, they need to be qualified in some other way. Here are some steps to help identify goals and break them down into attainable actions.

1. Quantify the current state of the world:

   • Quality/Stability: identify failure rates, time to recover from incidents, Uptime and Performance Service Level Agreements (SLAs), number and severity of issues through security audits (automated scans or pen-tests). It might help to use an assessment tool to identify the health of your services and what matters will vary.

   • Speed/Throughput: identify your lead time (or cycle time as a subset of lead time), deployment frequency, etc. From here you can break down what may slow down the team and any actions that may lead to improvements without compromising quality.

2. Size & Prioritize: Map out actionable chunks that will potentially improve the score and assign each item a size and priority. Story Mapping and Prioritization sessions are your friends here.

3. State your goal or hypothesis: declare that you want a % change in those areas. Chunk it into manageable tasks and goals so it feels more achievable. Create small steps of high priority items and outcome based goals.

Now that the goals are in place, they need to be advocated for and capacity needs to be allocated. This means selling these goals and metrics and getting buy-in. And know that revenue driven opportunities will typically take the front seat, especially when there’s the emphasis on relentless growth.

These are some strategies I’ve seen to get engineering efforts prioritized:

1. Use the Roadmap (obviously): With these established goals, don’t create them as long-running initiatives. Instead make them hypothesis driven with measurable outcomes. i.e. “If we do X, we can increase our lead time by Y,” or “If we patch this series of bugs, we’ll improve the health of the service by X%, thereby spending less time on support in this area.”

2. Continuous sub-group: Dedicate a portion of the team for support and engineering related activities. The size of this group is dependent on the extent of the effort required to bring about the necessary outcomes. This group can be rotated as needed.

3. DX Sprints: Dedicated quarterly Developer Experience focused (DX) Sprints - take the time to gather metrics and create a plan. As a group, consolidate items into a couple streams of work with achievable goals.

4. Project buffer: Buffer at the end of an epic to clean up any “architectural compromises” that were made. Software is famous for getting out of hand, quickly. As you go through, a better pattern might have emerged that was neglected for the necessity of “getting it done”. If there’s a buffer at the end of an epic, maybe these changes won’t be lost to the recesses of time. (call it an Epic buffer for the agile enthusiasts)

5. Campsite Rule: Work on these long-running engineering efforts alongside the roadmap stories as needed. (i.e. deliberately structure changes to conform to a new pattern and adhere to the campsite rule - leave it better than you found it). This isn’t the most efficient, may lead to fractured priorities, may also violate tightly scoped work and can compromise Lead / Cycle time as a result. Use it as a last resort if the roadmap is particularly relentless.

6. 20% (or 10%) Time: Use other dedicated engineering time - Google had its 20% days, where these items could potentially be accommodated. This is a system where 20% (i.e. every Friday) is set aside for whatever the engineers want to work on, within the realm of the business. It’s a welcome break for engineers from the typical day-to-day and provides the time to flex their creativity, or scratch any lingering itches. However, I’ve seen that these are too disjointed to accomplish much and end up being perceived as a pit of unaccountable time.
   I had a version of this called 10% days (1 day every 2 weeks). There was some hope that the team would prioritize the speed and quality based tasks, but they mostly prioritized their own learning and development, and work-related side-project. This time actually detracted from other engineering efforts that could have been used for the team’s DX and tech debt.

Also, a word of advice on addressing quality and speed: avoid system rewrites at all costs - see Joel Spolsky’s Things You Should Never Do. They rarely go well and put everybody in an awkward spot, for a long time. If something needs a massive overhaul, I’d recommend the Incremental Migration approach, as illustrated here.

While it isn’t the easiest getting your engineering goals prioritized, these are some strategies I’ve experienced, each with their own pros and cons. The trick is being persistent, yet adaptable. What works one year might not work the next.

In Summary

• Priorities will typically be given to projects directly related to revenue and growth. There are usually other teams that help navigate this terrain (i.e. Product)

• Engineering should be advocating for Speed (Throughput) and Quality (Stability). These can be difficult to prioritize because they’re indirectly related to revenue. You can use arguments along these lines: “Speed helps to deliver those revenue related items more quickly” and “Increased quality mitigates potential revenue loss”

• Figure out the metrics you care about, but lean on established best practices, like DORA metrics. Just know that DORA metrics are like the “draw the owl” meme in that they’ll tell you where you need to go, not how to get there.

• From the metrics you care about revisit them periodically. Create narratives and give them weight and accountability. Establish incremental goals and manageable action items.

• Negotiate them into the roadmap - what might work one year/quarter might not work the next. Be persistent, but adaptable in pursuit of these goals.