Bahtera is a Bitcoin treasury consultancy for companies and leaders across Asia, including Indonesia, Malaysia, Singapore, India and the Philippines, offering executive education, treasury policy, custody architecture, tax coordination and audit-ready reporting. https://rickymamansandbox.github.io/feed.xml 2026-10-22T08:52:27+07:00 Bahterahttps://rickymamansandbox.github.io/ https://rickymamansandbox.github.io/images/logo/logo-square.png https://rickymamansandbox.github.io/blog/preparing-the-treasury-conversation/ 2026-09-28T00:00:00+07:00 2026-09-28T00:00:00+07:00

A useful internal discussion starts with a shared question, a clear purpose, and the right people in the room.

<h2 id="start-with-the-question">Start with the question</h2> <p>An internal discussion becomes much more useful when everyone knows what it is meant to resolve. “Should we explore Bitcoin treasury?” is a different meeting from “Who will review our proposed operating process?” A short brief makes that difference explicit.</p> <p>Begin with one paragraph explaining why the topic is on the agenda. Describe the organisational question in your own words. Leave room for disagreement: the purpose of the brief is to make the discussion clearer, not to predetermine its conclusion.</p> <h2 id="identify-who-needs-to-contribute">Identify who needs to contribute</h2> <p>List the people whose work would be affected by the proposal. That might include leadership, finance, operations, technology, and external advisers. Give each participant a specific question to consider before the meeting.</p> <p>Someone responsible for daily operations may see a handover issue that is absent from a high-level proposal. A finance colleague may need a clearer description of the records the process would produce. Bringing these perspectives together early helps define the actual work.</p> <h2 id="separate-what-you-know-from-what-you-need-to-learn">Separate what you know from what you need to learn</h2> <p>A helpful brief has two short lists: existing information and open questions. Put current processes, internal constraints, and named owners in the first list. Put uncertainties and requests for specialist input in the second.</p> <p>Avoid treating an assumption as an agreed fact. If a point needs review, assign someone to follow it up and record the outcome. This turns uncertainty into a visible piece of work.</p> <h2 id="define-the-next-decision">Define the next decision</h2> <p>End the brief with the decision the meeting should enable. It could be agreeing an education session, appointing a working group, or commissioning a more detailed review. Keep that step proportionate to the information available.</p> <p>After the meeting, update the brief with the decision, its owner, and the questions that remain. The document then becomes a useful starting point for the next conversation.</p> <p><a href="/services/policy_design/">Explore our approach to treasury policy</a>.</p> https://rickymamansandbox.github.io/blog/planning-a-team-workshop/ 2026-09-28T00:00:00+07:00 2026-09-28T00:00:00+07:00

A practical structure for a team learning session that ends with useful next steps.

<h2 id="ask-before-you-teach">Ask before you teach</h2> <p>Before planning a team workshop, invite participants to share the questions they want answered. Some may be starting from the basics, while others are already thinking about implementation. Seeing those differences helps the facilitator shape the session.</p> <p>Group the questions into themes. Keep a separate list for topics that need input beyond the workshop, rather than squeezing every question into the agenda.</p> <h2 id="agree-a-learning-objective">Agree a learning objective</h2> <p>Choose an objective that participants can recognise at the end of the session. “Develop a shared vocabulary for our next internal discussion” is easier to assess than “Understand everything about Bitcoin.”</p> <p>A narrow objective also creates room for participation. The facilitator can spend time checking understanding instead of moving through too much material.</p> <h2 id="connect-the-discussion-to-the-team">Connect the discussion to the team</h2> <p>Use the team’s own questions to structure the conversation. Ask participants what a concept would mean for their role, which assumptions remain unclear, and what information they would need before taking part in a decision.</p> <p>Keep learning and decision-making distinct on the agenda. Attending a workshop does not imply agreement with a proposal. People should feel able to ask basic questions and challenge assumptions.</p> <h2 id="leave-with-a-short-record">Leave with a short record</h2> <p>Close with three lists: what became clearer, what remains unresolved, and what the team wants to do next. Assign follow-up questions to named owners where appropriate.</p> <p>Share that record with participants. It can become the starting brief for another learning session or a separate implementation discussion.</p> <h2 id="build-the-next-session-from-the-first">Build the next session from the first</h2> <p>Ask which parts of the workshop were useful and which need more explanation. Use that feedback to choose the next topic. A sequence of focused conversations can be easier for a team to absorb than one crowded presentation.</p> <p><a href="/contact/">Prepare a team enquiry</a>.</p> https://rickymamansandbox.github.io/blog/documenting-operational-responsibilities/ 2026-09-28T00:00:00+07:00 2026-09-28T00:00:00+07:00

How a simple responsibility map can make implementation discussions more concrete.

<h2 id="follow-one-task-from-beginning-to-end">Follow one task from beginning to end</h2> <p>A process document can sound complete while still leaving people unsure what to do. One way to review it is to follow a single task through the proposed workflow: who starts it, who checks it, who records the outcome, and who handles an exception?</p> <p>Write those steps in everyday language. A colleague who did not draft the document should be able to describe what happens next without guessing.</p> <h2 id="give-each-step-an-owner">Give each step an owner</h2> <p>A list of departments is less useful than a clear description of responsibilities. Identify the role that performs the task, the role that reviews it, and the person or group that resolves an unresolved question.</p> <p>The aim is to make accountability understandable. If two teams both think the other owns a step, the document needs another pass.</p> <h2 id="make-handovers-visible">Make handovers visible</h2> <p>For every handover, describe the information passed along and how the receiving person knows the task is ready. A completed action and a documented action are not always the same thing.</p> <p>Consider how someone joining the team would find the relevant records. Consistent names, an agreed location, and a clear version history make a document easier to use in practice.</p> <h2 id="walk-through-an-exception">Walk through an exception</h2> <p>A walkthrough should include an ordinary day and a day when something does not go as expected. Ask what happens if a required person is unavailable or a record is incomplete. Record the questions that emerge instead of resolving them through improvisation.</p> <p>These discussions are preparation for a reviewed operating process. They do not replace the technical or specialist review a particular system may require.</p> <h2 id="close-with-a-review-point">Close with a review point</h2> <p>Assign an owner for maintaining the document and identify when it will be revisited. A responsibility map is useful only while it reflects how the team actually works.</p> <p><a href="/services/custody_architecture/">Learn about custody architecture support</a>.</p>