How we are organised

We have 9 functional teams:

A person can (and probably does) belong to multiple teams. The role they play in each team will be different.

Who is in each team?

💖😍💯👍🏼 Governance 🔭 Strategy 🔮 Revenue 💰 Data 📊 Product ⚗ Dev 💻 Comms 🎙 Org 👨‍👩‍👧‍👦🏢 Ops 🔨

How each team operates

Each team has a clear purpose and defines their own operating style. This covers the work they do, and also pays particular attention to how they interact with other teams and work together to achieve organisational goals.

Communications Team

Why this team exists

To get people in New Zealand to know we exist, what we do, and how we can be useful for them.

What are we responsible for

  • Engagement on social media channels and other channels such as our blog.
  • Managing relationships with those we’ve agreed to do comms with.
  • Managing advertising.
  • Managing PR.
  • Measuring and analysing engagement with our communications.
  • Ensuring external comms are aligned with our values, etc
  • Campaigns/events.
  • Helping everyone make the most of their 20 percent comms team time.

How do you know if we are doing a good job

  • Engagement with our communications increases.
  • More people are directed to our products.
  • More people are aware of Figure.NZ and see it in a positive light.

How we interface with other teams

  • Everyone is a comms team member!
  • We’re cool with feedback or questions at any time in #communications. We’ll consider all suggestions, and if we decide not to implement them, we’ll talk to you about why.
  • Please ping someone with communications in their job title if you spot a typo. Typos keep us up at night.
  • Before we make any promises to external partners, we talk to anyone who may be affected by new comms commitments.

Our outputs

  • Social media strategy and content.
  • Content strategy.
  • Ads.
  • Comms strategy.

Things we don’t do

  • We don’t micro manage.

Data Team

Why this team exists

We take disparate data and turn it into standardised and best-practice formats that everyone can use.

What we are responsible for

  • Processing data and prioritising content
  • Conducting research (scoping new projects, gaining knowledge on what’s available in the data landscape)
  • Liaising with partner organisations on data publishing projects, data research projects, and workshops
  • Preparing content for online news organisations to use in their stories
  • Responding to internal data queries and helping the Communications Team with external queries
  • Assisting in the design of Grace and testing functionalities
  • Building relationships between data so people can find it easily
  • Writing blog posts related to data and numeracy
  • Producing documentation on internal data processes

How you know if we are doing a good job

  • There are no errors in content posts
  • People can find the data they are looking for (shared with Product team)
  • Data is up to date and covers a good breadth and depth, as defined by quarterly objectives
  • We consistently deliver data projects on time and within budget

How we interface with other teams

  • Responding to data queries from the Communications team and other staff - via #data and #communications
  • Raising Grace bugs - via GitHub
  • Requesting Grace features - via Product Trello Board
  • Providing cost & time estimates for data projects to the Revenue team
  • Any feedback or suggestions for the data team are welcomed in #data at any time. Please make your comments publicly unless they are sensitive in any way, in which case private Slack or in person is welcomed. We are open to feedback at any time unless specifically stated otherwise. If you find a chart or table with a problem, please let us know immediately and we will deal with it as soon as we possibly can.
  • Please consider carefully and consult in #data with the data team about turnaround times before committing us to any deadlines.

Our outputs

  • Content posts on
  • Data Roadmap (including Data Discovery list)
  • Data Team Documentation
  • Blog posts
  • Enumerations and connections across data concepts (i.e. Business Figures)

Things we don’t do

  • Set priorities for other teams
  • Design user-facing elements
  • Sales
  • Write code

Development Team

Why this team exists

To implement, manage, and help design, the Figure.NZ software platform.

What are we responsible for

  • Software development: analysis, design, build, test, document, deploy, maintenance
  • Managing the software platform (largely comprised of the Grace application and the public website at
  • Ensuring the security and data integrity of our software
  • Providing technical advice

How do you know if we are doing a good job

  • The Data team can perform functions involving our software efficiently and effectively
  • The Product team feel sufficiently advised on technical aspects of product development
  • The codebases we manage are of a high quality. This has several axes in roughly descending order of priority:
    • We are not the victims of a hack, nor do we suffer negative publicity in relation to our software
    • Our codebases are secure, and this is verified by independent testing
    • We suffer no data loss as a result of software error
    • Our codebases are well tested
    • Our codebases have a well understood and appropriate level of technical debt
    • The general level of software defects does not significantly impact on other teams or the public
    • The software allows people to peform their tasks
    • Developers can add new features with relative ease
    • We are regularly shipping code (improvements, bug fixes, tech debt cleanup, and anything else required)
  • The Product Manager is not surprised by anything relating to development
  • The CTO is not unhappy with anything technical

How we interface with other teams

For most teams, we provide ad-hoc technical advice. We can do this through the #development channel in Slack, or by being pinged in your team’s channel. We’re not fussy about this and we’re here to help you.

Technical discussions often need to be high-bandwidth, and we are happy to jump into a call or meeting with you (although we may ask for the discussion to be later, due to the nature of our work).

We are not responsible for deciding what to build and when it is built. If discussions reveal a software requirement, we will redirect these to go through the Product team process.

On the other hand, we are responsible for the quality of the codebases we develop. Issues that we - or others - find with the quality can be raised by making a card in the Inbox on the Development board. If you think you have found an issue for us, but aren’t sure about it, we’ll be happy to hear from you in the #development Slack channel.

Work that is our responsibility (i.e. cards made on the Dev board), and work that comes from Product, needs to be prioritised. We collaborate on prioritisation with Product, and this is represented by the ordering of cards in the Backlog list. Note that sometimes, lower priority cards “jump the queue” if it is an intelligent use of time for this to happen.

For some specific teams, we have particular interactions:

  • Product team
    • Much of our work flows from the Product Trello board to ours, then back again when completed
    • Communication with the Product Manager (Amy) regarding prioritisation
    • Chats and meetings with the Product team to:
      • Verify requirements or get more detail on problems
      • Provide advice
  • Data team
    • Assistance with diagnosing and fixing problems with Grace that the Data team encounters
    • Assistance with more efficiently carrying out Data team work, such as making direct database changes on occasion
    • Discussions on software limitations and opportunities, which can flow into new Product work

Knowing a little about how software development works can be a great help if you’re unsure about something development related. We have prepared a helpful document about this.

Our outputs

  • Software
  • Documentation
  • Discussion documents/proposals regarding specific issues
  • Trello cards (largely on the dev board)
  • An absence of trello cards (largely on the product board)

Things we don’t do

  • We don’t have an SLA, therefore we do not commit to responding to out-of-hours service incidents in a given time period
  • We don’t implement software changes that are under the aegis of the Product team without using their process

Governance Team

Why this team exists

To make sure Figure.NZ delivers on its mission.

What we are responsible for

  • Agreeing the organisation’s mission
  • Agreeing the organisation’s strategy, goals, and budget
  • Monitoring progress against the strategy, goals and budget
  • Ensuring the organisation’s capability is fit for purpose
  • Identifying and mitigating risks
  • Ensuring the organisation is fiscally responsibility
  • Ensuring the organisation is legally and financially compliant
  • Ensuring the organisation is compliant with health and safety requirements
  • Providing perspective, guidance and support to the CEO
  • Development of the CEO

How you know if we are doing a good job

  • The organisation has clear direction
  • The organisation is in good shape financially
  • The organisation is meeting its commitments
  • The organisation is compliant in all areas
  • The CEO feels supported and confident

How we interface with other teams

  • Work closely with the Strategy team
  • Respond to any questions from any other teams
  • Seek informal engagement with people thoughout the whole team from time to time

Our outputs

  • Board minutes
  • Board papers
  • Annual Report submitted to the Charities Commission
  • Approved annual/monthly budget

Things we don’t do

  • Manage or interfere with the day to day operations

Organisation Team

Why this team exists

We deliver a delightful working environment and make sure our systems and tools support us in getting the job done.

What we are responsible for

  • Setup and smooth running of the office
  • Health and safety
  • Hardware and software and systems that you need to do your thing or that we need as an organisation
  • Basic employment systems (like job descriptions and employment agreements and annual leave)
  • Running fortnightly check-ins with individual team members

How you know if we are doing a good job

  • The office is a safe and welcoming place for all of us: a delightful haven of peace and productivity

  • (In the near term) all the things for the office setup on Trello are done

  • You have the tools you need to do your job and you do not spend time on small details that you should not have to worry about

How we interface with other teams

  • Any input directed at the #organisation channel will be welcomed, and anything to be brought to our attention should be posted in there.

Our outputs

  • Health and Safety Policy

  • A smoothly-running office environment

  • Six million small technical things that make your life better

Things we don’t do

We are not solely responsible for day-to-day running of the office, like refilling hand soap or paper towels. These are a team responsibility. Do your own dishes people.

  • Annual Report submitted to the Charities Commission
  • Approved annual/monthly budget
  • Manage or interfere with the day to day operations

Product Team

Why this team exists

We gather requirements, analyse, design, create graphics and test ideas

What we are responsible for

  • Enabling people to find and use the data we have

  • Gathering requirements from users

  • Gathering requirements from other teams

  • Designing products

  • Designing graphics

  • Testing ideas

  • Providing a cohesive set of products

  • Managing projects

  • Ongoing measurement and improvement of our products

  • Prioritising product development

  • User research

  • Artefacts that need to be maintained

  • The product

How you know if we are doing a good job

  • People can find the data they are looking for (shared with Data team)

  • Projects are delivered on time and on budget

  • The Development team knows what to do

  • Everyone in the organisation is clear about what is coming up and why

  • People are using our products more and more

  • Our analytics measure and reflect how well we are doing

How we interface with other teams

  • Anyone can tell us about their problems or dreams
  • Anyone can attend our weekly team meeting and ask questions

  • Anyone can ask a question in any channel, mention the Product Manager (Amy) in your queries to ensure you recieve a response. She may refer to others in the Product team to help answer your question.

  • Work in progress is discussed in our Slack channel and we post things into #general when it is ready for team feedback

  • Anyone can put a card in our product inbox, only the Product Manager can move things out of the inbox into the backlog and only a Product team member can move it out of backlog. Not doing a card has to be agreed with the person who made the card

  • We seek the expertise of others when we are defining things that impact them

Our outputs

  • Bug backlog (shared with Development team)

  • New Feature backlog

  • Product map

  • Product vision

  • Prioritisation list (this may be a combo of bug/new feature list)

  • Products

  • Documentation for these products

Things we don’t do

  • We don’t make unilateral decisions without seeking input and considering needs of the other teams

  • We don’t tell the Development team how to build

  • We don’t expect the Development team to perform miracles with limited resources

  • We don’t neglect operational requirements in favour of new features

Revenue Team

Why this team exists

We are here to bring in enough revenue to enable the organisation to keep working towards the mission.

What we are responsible for

  • We identify, contact and establish relationships with new patrons, partners and customers that could lead to revenue.

  • We run a simple process to track, prioritise and advance opportunities.

  • We negotiate and finalise contracts with confirmed patrons, partners and customers.

  • We keep track of what we have committed Figure.NZ to do.

  • We keep the other teams informed of what is looming

How you know if we are doing a good job

  • Revenue is growing over time measured on a 12 month rolling basis

  • Our runway is at least [four] months long (enough that it does not cause day-to-day anxiety for anyone other than the Revenue team)

  • We have a strong sales pipeline

How we interface with other teams

  • We ask the Data team for cost/time estimates for work on potential data projects.

  • We ask the Product team for guidance on how potential project ideas fit with Product priorities.

  • New ideas for projects, partners or patrons, questions or comments are welcomed at any time in #revenue or by putting a card in the Inbox on the Trello board.

  • We work with the strategy team to understand ideal revenue targets and timelines, as well as ideal partners/revenue streams

Our outputs

  • View of sales pipeline, runway and 12-month rolling revenues updated each month [link to come].

  • Check in the Trello board (soon to be Salesforce) for the status of any relationship that might generate revenue.

  • Canonical record of all Figure.NZ contracts and committments [link to come].

Things we don’t do

  • We don’t decide how revenue gets spent

  • We don’t commit Figure.NZ to data projects and deadlines without agreement from the Data team

  • We don’t commit Figure.NZ to providing new products or services to patrons, partners or customers without agreement from the Product team

Strategy Team

Why this team exists

To help the organisation understand our environment, define our goals and make important decisions about how to achieve them in line with our [mission] (link to mission).

What we are responsible for

  • We develop, document and share our organisational strategy
  • We make high-level decisions about how to allocate our people and our money, and track progress against our mission
  • We run the process to set goals and priorities
  • We help teams check that their priorities will progress us towards our overall organisational goals
  • We advance projects that are important for our long-term success but that do not fit well in other teams
  • We share priorities and expected outcomes with the board, and how well we are doing
  • We regularly review the priorities and goals

How you know if we are doing a good job

  • There is a clear, documented strategy for how we will make progress towards our overall mission in the next [3-24 months].
  • Everyone internally knows the key elements of the strategy and the top organisational priorities
  • Teams use the strategy when setting their own priorities
  • There is a common sense of purpose and direction amongst the organisation
  • We know if we’re winning

How we interface with other teams

  • We provide useful direction for teams so they can coordinate their activity to achieve our organisation goals
  • We rely on all other teams to make progress towards the strategy
  • We run a cross-organisational prioritisation process every quarter
  • We run an informal monthly check-in on our goals and priorities
  • You can check our progress by looking at the strategy Trello board at any time
  • Feedback, questions or comments are welcomed at any time in #strategy

Our outputs

  • A documented strategy inlucding our big goals, quarterly goals, and actions the organisation has committed to
  • Clarity around decisions we have made and why we have made them
  • A budget
  • Quarterly goals document as a result of the prioritisation process, which includes any update to the main goals and measures

Things we don’t do

  • We don’t dictate team priorities
  • We don’t dictate organisational priorities

Operations Team

Why this team exists

To create, manage, and ensure the smooth and secure operation of, the technical infrastructure for the Figure.NZ platform.

What are we responsible for

  • The technical infrastructure that hosts, Grace, Tohu, and any other software we may produce, particularly:
    • Platform security
    • Preservation of service
  • Aspects of information security for Figure.NZ not covered by the Organisation team
    • Management of operations-related secrets
    • Incident response
  • Providing advice to ensure the scalable, smooth running of Figure.NZ-produced software

How do you know if we are doing a good job

  • The public can use at any time, with minimal technical problems caused by Figure.NZ
  • The data team can use Grace at any time, with minimal technical problems caused by Figure.NZ
  • We respond quickly and appropriately to failures of service
  • Confidential information we hold (secrets etc), remains secret
  • We are not the victims of a hack, nor do we suffer negative publicity in relation to our infrastructure
  • Databases and data stores we run maintain their integrity
  • Our infrastructure has a well understood and appropriate level of technical debt
  • The monthly cost of running our services is predictable and not overly excessive
  • The Development team feels they have the support of the Operations team in the design and timely provisioning of resources to run Figure.NZ software
  • The CTO is not unhappy with anything technical
  • Our team is considered around the organisation to be friendly, approachable, inclusive, and supportive

How we interface with other teams

We may be reached for questions through the #operations channel in Slack, or by being pinged in your team’s channel. We’re not fussy about this and we’re here to help you.

#operations contains secrets, and sometimes discussion will often be about issues with our systems, occasionally serious ones. It is important that information from #operations is not reported publicly. Do not share anything from #operations with anyone outside Figure.NZ.

Technical discussions often need to be high-bandwidth, and we are happy to jump into a call or meeting with you (although we may ask for the discussion to be later, due to the nature of our work).

We are not responsible for developing software. If discussion reveals a software requirement or defect, we will assist you in ensuring you know what to do next to get the problem resolved, which will normally mean having a discussion with the Product team, creating an Issue, or creating a card in the Product team board.

We are responsible for, and highly interested in, anything to do with the security of our software (Grace, etc.). If you think you have found a security vulnerability, please talk to someone in the team right away.

We work closely with the Development team, to ensure the smooth and secure operation of Figure.NZ software, and to ensure they have what they need to deliver software. There are no formal processes for this interaction yet because the teams are both small.

The operations team may sometimes go into incident response mode, to deal with a security problem or outage. Incident response happens in the #operations Slack channel. People from other teams may need to join and take part in the channel for the purposes of resolving the incident. During this time, we will report status or conclusions in the #general channel.

Our outputs

  • Provisioned infrastructure (servers and other things required to run our software)
  • Documentation
  • Discussion documents/proposals regarding specific issues
  • Trello cards on the Operations board

Things we don’t do

  • We don’t have the budget or staff for an SLA, so outage recovery is limited to best effort during business hours
  • We do not develop Grace,, Tohu, or other software which is the responsibility of the Development team
  • We do not provide technical support for in-office equipment, or problems with people’s computers (this responsibility lies with the Organisation team)
  • We do not provide information security support or training for staff (this responsibility lies with the Organisation team)

Our risk register

Why we have a risk register

Being exposed to risks is a normal part of doing business. Managing our risks well is important to Figure.NZ, and we consider it a core activity.

By maintaining a risk register and processes to identify and mitigate risks we:

  • Provide a secure and delightful working environment for our team.
  • Equip our board with all they need to help us navigate risks as we embrace opportunities.
  • Give our partners confidence in our sustainability and focus.
  • Make sure that people who use Figure.NZ can continue to rely on us.

What is included in the risk register

We have identified 7 areas of risk:

  1. Team
  2. Technology
  3. Legal
  4. Money
  5. Relationships
  6. Reputation
  7. Physical

Each identified risk is assigned the following:

  • Owner: Who is responsible for the current state of the risk.
  • Likelihood: 1 (Rare), 2 (Unlikely), 3 (Possible), 4 (Likely), 5 (Almost certain).
  • Consequence: 1 (Insignificant), 2 (Minor), 3 (Moderate), 4 (Major), 5 (Extreme).
  • Mitigation: Action/s we will take to reduce the seriousness or existence of the risk.
  • Progress: Where we are up to in taking the mitigation action/s.

How things are added to or addressed in the risk register

One week before board meetings Lillian will ask all team members to review the risk register and provide:

  • Updates on progress for all risks they own.
  • Thoughts on other risks listed and any inaccuracies in the register.
  • New risks they have identified.

The risk register will then be updated. A link to it will be included in board papers, with review and discussion of risks being a standing agenda item for all board meetings.

Where a risk has an added Likelihood + Consequence value of 7 or more, there will be a weekly check-in between Lillian or Ngapera and the risk owner until the risk is reduced.

Updating the risk register

To ensure the risk register is maintained, we are incorporating it into our quarterly objective meetings.

At beginning of objective quarter:

Review the risk register when setting objectives. Note that objectives don’t have to mitigate risks, but we want to know if they do.

Questions to ask:

  • Are there any new risks that should be addressed? If yes, provide these as noted above.
  • Do any objectives work to mitigate recorded risks? If yes, reference the risk number where relevant (i.e. “See RR: Row 3”)

During objective quarter:

  • If an objective works to resolve or mitigate a risk, update the risk register.
  • During our monthly objective meeting, update the team on the related risk and any progress on mitigating it.

At end of objective quarter:

  • Review any updates to the risk register during our quarterly objective meeting.
  • Also at this meeting, discuss any changes to the risk register and confirm the team’s agreement on these.

The risk register can be viewed here by Figure.NZ staff and board members.

How do we communicate with each other?

Each of us has a different communication style. To help understand how we communicate, we do a communication style questionnaire. This allows us to reflect, and our team to work together to find good ways to communicate.

Communication style questionnaire


  • How do I do dreaming?
  • How do I prefer to work on new ideas?
  • How do I like to ask for input on ideas?

General office work

  • How do I respond to interruptions?
  • What’s the best way to ask me for feedback?
  • How do I prepare for meetings?
  • What’s the best way to give me feedback on something I’ve suggested?
  • What things do I find challenging?
  • What’s my day-to-day Slack style?
  • What’s my style when giving feedback?
  • How does information need to be structured for me to get the most out of it? (Context etc, ideas, purpose etc)
  • What’s the best way to get an update on work?
  • What’s the best way to get hold of me in a hurry?


  • How do I write?
  • What sort of editing do I prefer and when?

When things go wrong

  • How do I express frustration?
  • What’s the best way to check in on me if you’re concerned?
  • What’s the best way to provide help?

Lillian’s communication style


How do you do dreaming?

I like to dream by myself. This could be sitting at home looking at the tress, or it could be sitting down with a stack of A3 paper and some black ink pens and just letting my mind wander without interruption. I don’t like to share my dreams before I’m ready.

How do you prefer to work on new ideas?

I follow my nose and sense who I want to involve in different parts of my thinking at different stages in the process, and then often informally pull them into a conversation. This could be internal or external to the team. It may feel like I’m excluding people because I seemingly randomly pull in different people rather than formally sharing, but it’s really important for me to be creative with my process and not feel I have to follow a set path.

How do you like to ask for input on ideas?

I tend to ask without warning when I’ve suddenly realised you’re the person I next need input from. I realise this can be jarring for others’ style preferences and interrupts people so I do try not to do this, but totes tend to fail when I get excited about the idea which, let’s face it, is always 🙃. I’m very happy for you to remind me that this makes it harder for you to help me.

General office work

How do I respond to interruptions?

Completely depends what I’m working on. If I’m concentrating on something important or complex I find it really frustrating to be interrupted, and if I’m not then I’m really happy to be pulled into informal or formal conversations on the fly. The best way to know is to ask and clarify the importance, for example “Lillian, are you interruptable for something fun?” or “Lillian, it’d be useful to get your input on something sooner rather than later, do you have time?”. Given my role, I often feel like I need to let myself be interrupted so you know I’m always here for you, so unless you ask me it’s unlikely to be clear if I’m actually in a good place for being interrupted or not.

What’s the best way to ask me for feedback?

Ask me directly with context and desired time frame. For example – whether you just want me to sense-check something you’ve done and need it that day, or if it’s in general you need more feedback from me in which case booking in a session so my brain can focus on you is best.

How do I prepare for meetings?

I don’t really prepare for meetings, I just give my full attention in the moment and ask lots of questions to get up to speed.

What’s the best way to give me feedback on something I’ve suggested?

Be direct in any format and at any time (i.e. fine to reflect and come back to me if you weren’t able to do it in the moment). I love feedback, I love getting robust thinking by working together and having things pointed out to me that I can’t see.

What things do I find challenging?

I’m a very active listener so I find it really hard when it isn’t clear to me that you’re just needing to talk to think (in which case I’ll dial down my active listening a few notches), rather than talking to convey something specifically to me. I’m totally fine with either, but it’s just good to know the context up front.

What’s my day-to-day Slack style?

Haphazard. Genuine. Open. Emotive.

My frequency of engagement changes massively depending on what my day is like. I try and read everything at some point, but it’s not always near the time it was written. I will sometimes write things while I’m on the run without having read everything that’s come before it. I like to be completely me in how I communicate, so I often share personal feelings or thoughts and very often tell the team how much I love them, because it’s true 😍.

What’s my style when giving feedback?

Sometimes I really struggle giving feedback when I’m trying to juggle how I think someone will emotionally receive what I want to convey. I tend to ask questions to get a better understanding and to try and come to conclusions together. If you want direct feedback on something I am very happy to give it, just make it clear to me that direct is what you’re after. I find it a lot easier to give feedback in person or verbally than to find time to write it up.

How does information need to be structured for you to get the most out of it? Think about ideas, context, purpose, detail etc.

I need to be anchored in what space the topic sits first, and why we’re talking about it - but aside from that I’m largely sweet with however someone wants to talk through something.

What’s the best way to get an update on my work?

Ask me directly, either in person or in Slack, and be clear about what you’re asking. For example asking ‘how’s it going with x’ is harder for me because I don’t know if it’s just a friendly question out of curiosity or if there’s a pressing need for you to know. The most useful way to get effective engagement from me is to help me understand if you need something and especially if I’m blocking you, as then I will prioritise answering as best I can.

What’s the best way to get hold of me in a hurry?

If I’m in the same place just ask me, if I’m not then text me on +64 21 234 2374.


How do I write?

Haphazardly. Usually by throwing down lots of ideas and words in a non-linear fashion, then going back to it as I have more ideas until I suddenly feel like it’s all come together in my head and I can sit down get it out. It can take me ages to express early thinking in writing clearly.

What sort of editing do I need and when?

Once I share something I’m happy for editing of any sort – structure, style, grammar, content, and I’m happy for you to take the pen and just make changes directly.

When things go wrong

How do I express frustration?

I often don’t, for 2 reasons: my style tends to be to process my frustration internally and think about how to solve things so it doesn’t happen again; and also I feel like given the power inherent in my role I need to be very aware of the impact my frustration could have on someone else.

What’s the best way to check in on me if you’re concerned?

Just ask me directly in any form – in person, in Slack, whatever’s at hand.

What’s the best way to provide help?

Written or verbal words give me the biggest sense of being cared for and appreciated. Often it’s hard to give me practical help, but it’s always nice to be asked.

Amy’s communication style

You can read Amy’s communication style on Slack.

Anoushka’s communication style

You can read Anoushka’s communication style on Slack.

Kimberley’s communication style

You can read Kimberley’s communication style on Slack.

Nat’s communication style


How do you do dreaming?

I need quiet time and space. It’ll take me a while to wind down and empty my brain from all the smaller things that have been occupying my brain, and then start to ponder. I’ll normally go away and read a bunch of articles on new tech or social changes to help form how I’m thinking, and then start to draw those together and overlay them with what we do. Sometimes, I’ll want to bounce off one or two other people to shape or sound something out that touches on their expertise, but I’ll normally then go away and dive deep again.

I prefer to not be doing other tasks simultaneously as I’ve lost the knack of getting into and out of that space quickly.

How do you prefer to work on new ideas?

At the beginning of the product cycle, I like to get an understanding of the moving pieces first. What are we trying to achieve and for whom? I’ll then read technical docs and standards. I’ll try to get an understanding of the current platform and issues from Andrea and devs. I’ll take these pieces away and turn them over in my head, mushing them against the goal we want to achieve. I’ll ask more questions - of Rob, of dev, of data. They’ll probably seem like strange questions, but they’ll help to resolve the muddle and bring clarity. I’ll probably feel frustrated and worried and a bit lost, and go down several routes that are dead ends before finding the right one. As the path becomes clearer, I’ll start to test out concepts with other members of the team - with product, dev, data etc.

The same roughly applies for non-product work. I need to start by understanding the scope of the work - the goals and audience. I’ll then push around pieces until a potential structure or approach presents itself. Often, this will be several iterations in.

How do you like to ask for input on ideas?

I tend to ask for guidance at the start the clarify the inputs and set the right framework. I then ask for specific domain expertise as I go through the exploration phase. I’ll normally specify that I need help on a specific aspect of a problem. I’ll then ask for wider verbal feedback from people as I start to talk through ideas, and finally feedback on more formalised written explanations.

I can get frustrated at general brainstorming unless there’s a clear purpose because it can feel very aimless to me.

General office work

How do I respond to interruptions?

It depends what I’m working on — if it’s something where I’m holding a lot of context in my head, I have space to answer quick, low-cognitive load questions, like availability for meetings or if somethings completed. But if it’s a more complex question that requires me to stop what I’m doing and think about an answer, I get agitated because I don’t want to let you down, but also I don’t want to lose what’s in my head because it’ll take me a long time to get it back. If it’s something that’s not urgent, or that can’t be answered quickly, it’s better to ping me via Slack than verbally interrupt me.

Of course, if it’s urgent, I’ll happily ditch what I’m doing. I may ask for a couple of mins to round out a thought, however.

What’s the best way to ask me for feedback?

Taking into account the interruptions thing, the best way is to ping me a message in Slack, either privately or in the relevant channel. Let me know what type of feedback you are looking for. Do you want to test out an idea or bounce concepts around, and need a safe space to do that? Is your idea more fully formed and you want to critique it or probe it for flaws? Do you need help identifying a technical solution? Is it administrative, like where something should live in one of our platforms? Do you need proof-reading for spelling and grammar?

It doesn’t need to be a fully-formed request, but giving me an idea of what type of help you need makes sure that I can pitch it correctly and be prepared, especially if you want to book in a meeting to discuss it. Otherwise, I tend to feel like I’m flailing in the dark, trying to understand whether you want help with your idea or whether you’re asking me about a tool to implement it or something else. This can trigger feelings of anxiety because I don’t want to let you down!

It’s also useful if you can let me know when you need the help by, and what form—writing or a talky or an in-person meeting, for example.

How do I prepare for meetings?

If your meeting is a working session that requires feedback or digging into a specific topic, it’s really helpful for me to know roughly what areas we’ll be looking at before the meeting. Ideally, at least the day before. This means I can tuck it away in the back of my head and start to think about the topic and load up all the context into my head. Otherwise, the first 10-15 minutes of the meeting, I’ll seem distracted because I’m trying to rapidly load this information, and you’ll often find that later that day, or the next day, I’ll come back to you with important feedback once enough context has loaded to assess your question.

If it’s just a catch up or an initial briefing, then just booking it in is ka pai.

What’s the best way to give me feedback on something I’ve suggested?

I’ve worked in environments where questions are used as weapons to tear down ideas. I’m working to unlearn my responses to that, but in the meantime, there’s some techniques that help.

It’s super helpful if you can start by giving me an indication of whether, overall, you think the piece you’re giving feedback on is broadly in the right or wrong direction. If it’s in the wrong direction, I can align my expectations, and seek to understand where I’ve misunderstood the requirements, and how that’s impacted the results. If it’s in the right direction, then I’m in a good mental place to hear specific feedback on targeted improvements. There are some small things, like prefacing questioning with ‘I’m trying to understand a few things, could you clarify…” that seem to disproportionately help also.

What things do I find challenging?

I’m not a fan of surprises. They’re very anxiety inducing for me. Ditto for confrontations.

I’m also partially deaf, so if the room is noisy, I find verbal discussion quite difficult.

In general, I find it really difficult to concentrate in a noisy environment.

What’s my day-to-day Slack style?

A lot of emoji and a lot of abbreviations, but also a lot of sarcasm. I am not being serious most of the time in general conversation.

When it switches to discussion on a technical or serious topic, it tends to activate a different part of my brain which changes my Slack style. It becomes more verbose, and I use far less emoji. This is not a sign that I am upset or angry or anything. It’s just a sign that I’m focussing on the topic at hand. I tend towards reflective and quite in-depth explanations that draw on expertise either in design or other topics. That part of my brain is super bad at detecting tone, so totally DM me and tell me to shut up if you need to.

What’s my style when giving feedback?

This really, really depends on the type of feedback someone has asked for. Typically, though, I’ll ask a lot of questions to try and understand what type of feedback they need, and then their thought process and goals. I know this can be a bit frustrating, but otherwise the feedback I give tends to be superficial and not as useful.

If it’s technical feedback, it tends to be direct and to the point. If it’s about ideas, it tends to be more exploratory, because it’s hard to communicate ideas and intentions, especially in early phases.

How does information need to be structured for you to get the most out of it? Think about ideas, context, purpose, detail etc.

I am so lost without context. I need the structure and background to hang ideas on, otherwise I forget things (or tune out, I know, it’s bad, but I have a terrible attention span). For me, the context includes the purpose too—motivation is so important when understanding information.

Once I have that background, I can fill in detail quite quickly.

What’s the best way to get an update on my work?

Ping me on Slack and let me know how much detail you need and by when.

What’s the best way to get hold of me in a hurry?

I am 100% not a fan of phone calls, but if it’s a technical emergency (site is offline), or a human emergency (I care about our team!) call me. I’m not sharing my number here for privacy reasons, but it’s on my Slack profile.

Otherwise, DM me in Slack, and prefix your message with ‘Important’ or ‘Urgent’. I tend to see most notifications as they come through unless it’s after 10 PM and that will get me to take notice (unless I’m genuinely unavailable)


How do I write?

I tend to start by jotting down a bullet list of ideas and half-formed sentences. Typically, I add to this over a day or two, and will end up mulling over it while walking to and from work, or driving the car. When I eventually start writing, it’ll be these thoughts that form the basis of what I write, pulling from the bullet list for structure.

Once I start, I tend to write in a linear fashion, with the possible exception of an introduction, and briefly jotting down concepts I think link in further down the piece.

I have a very different style for technical writing and blog writing.

What sort of editing do I need and when?

If I share an early/first draft, I generally want feedback on the ideas and structure of the piece. Does it make sense? Does it flow? Is the level of detail appropriate. I’m not typically ready for spelling/grammar corrections at this stage. However, sometimes I’ll state ‘any/all feedback welcome’. In this case, feel free to give that detailed feedback, because it means I’ve already done a run through for that myself.

When things go wrong

How do I express frustration?

Early on, I’ll try and ask questions and explain how I’m thinking. If that doesn’t work or help, I get anxious, and emotionally I shut down. Often, I’ll go quiet, and I’ll need to take time away to make sure that anxiety doesn’t escalate into panic. Sometimes I’ll tell you I don’t have the spoons for this discussion right now. That doesn’t mean I don’t ever want to talk about it–it just means I can’t right now.

What’s the best way to check in on me if you’re concerned?

If you’re worried about me, DM me on Slack. I find impromptu in-person conversations to be distressing, other than from a couple of people. Don’t touch me without warning, because if I’m struggling, I’m hypersensitive to touch.

What’s the best way to provide help?

Offer to talk (but don’t be offended if I don’t want to). Send cute cat pics.

Andrea’s communication style


How do you do dreaming?

I don’t allocate a lot of time for dreams. When I do, I enjoy drawing on the whiteboard at a time when the Auckland office is empty. This puts me in the comfort zone to just write whatever, erase, move things around without feeling self-conscious about the whole process.

How do you prefer to work on new ideas?

In the context of data team work, I enjoy structuring the idea’s framework into a Google Sheet (or Excel if it needs proper formulas), and then share it as the starting point for feedback. After having used Trello for a couple of years now, I prefer using a Trello card as a the “meeting point” for the idea to grow. I’m conscious of the geographical distances in our team as well as the time that typing requires, so I often insist on discussing on Talky to get things moving along.

How do you like to ask for input on ideas?

I tend to ask for input quite spontaneously if it’s something that is either exciting or bugging in the moment. On Slack, I generally add a couple of sentences prefaced with the word “Context:”.

General office work

How do I respond to interruptions?

I’m perfectly fine with interruptions at any time, unless I’m talking on the phone or I’m attending a meeting. What’s the best way to ask me for feedback? If it’s something you think requires less than 5 minutes, it is OK to just grab me in person or @mention me on Slack (preferably in a public channel so the response can be seen by other team members). For anything else that requires more time, the best way is to provide context by pointing me to the Trello card for that particular task and give me an expected timeframe on when you need the feedback by. I struggle to keep an eye on Trello cards that are not on the #data board, so chances are I will either move that card to #data, or I will create a temporary card for my feedback task and merge them later.

How do I prepare for meetings?

I enjoy being prepared for meetings. Knowing the agenda and/or the overall objective of the meeting beforehand is very helpful. Whenever I need to meet with someone who doesn’t work for Figure.NZ, it is important for me to know a bit about them (e.g. what interests them? how can I be most helpful to that person?)

What’s the best way to give me feedback on something I’ve suggested?

I love detailed-oriented feedback. Any channel is fine. I tend to feel bad if you have to spend too much time writing feedback, so if my output is completely off-the-mark, it’s better to just have an overall chat in person.

What things do I find challenging?

On Slack, I find it hard to balance ambient chit-chat with work-related conversation (mostly in favour of the latter). I also struggle to pick up queues on whether to check on someone’s emotional wellbeing or just leave it.

What’s my day-to-day Slack style?

I tend to avoid direct messages (DMs), unless it’s inappropriate for the conversation to appear in public. I’m conscious of making sure that people who are not in the same room as me can absorb and respond to what’s going on and what we’re working on. I use Trello-Slack integration to vicariously narrate the progress of what I’m doing, but I also use the check-ins/outs. I’m a slow writer. Sometimes I need to edit my Slack messages for tone and grammar after they’ve been posted. I’m not cool enough for acronyms / Internet slang. :sweat_smile:

What’s my style when giving feedback? I tend to use bullet points. Sometimes I forget to provide an initial overall reaction, so please do remind me to do so. :please:

How does information need to be structured for you to get the most out of it? (Context, ideas, purpose etc)

  • Background
  • Ideal outcome
  • My role in achieving that outcome
  • Timeframes

What’s the best way to get an update on work?

Just ask me in any format. If you were expecting me to have something ready for you at that point, please do let me know so we can figure out together whether I’ve missed a piece of the conversation and how I can sort out the situation ASAP. :runner:


How do I write?

Do we really need to open this can of worms? :smile: I use lists as aids to get the content out of my head. Ever-evolving documents (such as how-to guides) are closer to my comfort zone as I feel I can improve on them over a long period of time. In external communications I tend to be factual, however I use smiley faces and a friendly tone (that’s where my customer service experience pays off).

What sort of editing do I prefer and when? Being quite a sterile writer, I’m happy for anyone to jump in and improve on the style and grammar after I’ve laid out the key concepts I need to get across. If I’m struggling to get something written coherently, I will kindly ask for help and not take any offence regardless of the nature of the edit. I appreciate being asked for a final sense-check near completion to make sure the intended meaning hasn’t been lost in the process.

When things go wrong

How do I express frustration?

My facial expression tends to reveal whether I’m upset/frustrated or generally happy. I believe Slack is a pretty poor medium to let any work-related frustration out, so in the rare instances of frustration I would distance myself from Slack and focus on productive work instead.

What’s the best way to check in on me if you’re concerned?

Ping me on a Slack message and offer to talk the next day, when the frustration is likely to have been subsided.

What’s the best way to provide help?

I appreciate hearing another person’s point of view in relation to that particular situation.

Nigel’s communication style

You can read Nigel’s communication style on Slack.

How do we manage passwords?

Figure.NZ uses 1Password for Teams to securely store and share logins and password information. As a Figure.NZ employee, we will pay for a 1Password account for you to use.

When you join Figure.NZ, you will receive an invitation to sign up for 1Password for Teams. By creating an account, you gain access to the services we use.

The signup process works as follows:

  • You receive a 1Password invitation.
  • You create your 1Password account.
  • You install 1Password apps on your computer and phone.
  • We share some password vaults with you.

Password vaults at Figure.NZ are divided by team, in the same way that we use Slack and other tools. Depending on your job, you will receive access to vaults such as Communications, Product, Development, etc. If you need access to another service, just let us know.

Your 1Password for Teams account includes a private password vault, and we encourage you to use this for your personal logins, even if you don’t intend to share them with us. Improving your personal security reduces the risk of your computer or accounts being compromised, which in turn improves our organisational security as well.

When you leave Figure.NZ, we will remove your access to work-related items, but we will not restrict your access to your personal items. We will continue to pay for your 1Password account for three months after your leaving date, to give you time to export your personal data.

How to suggest ideas to Product

Yay for ideas! We want and need new ideas. The Product team should be always be trying to understand and find out more about what is bugging a particular team, or what new things they have been thinking about from their perspective. For example, what ideas the Data team has to help them excel and make them happy, and also the Comms team, understanding what they need to be able to best achieve the objectives they have.

It is super important to us that we understand why these ideas are coming from various teams. Sometimes we need to pick your brains a bit to fully understand what the core intention is of your request. That is because sometimes in describing the problem or idea, it can be easier to describe how you would solve it - but we may need to ask more questions to get to the core of what you are trying to do.

When we’re building software, there’s lots of underlying and hidden complexity that drives the things you see on the surface. This means that what might seem like an obvious solution isn’t always so great. Most of the time, it means we have to unpack what the problem you’ve seen is.

That doesn’t mean we don’t want to hear from you. What it does mean is that we’d like to understand more about the problem you’re seeing or want to solve.

We want to know why you want to change something. What’s the opportunity? What can’t you do that you want to be able to do, and why. The more specific you are with examples, the better. In fact, generalisations aren’t very helpful at all, because we need to be able to get into your world and understand exactly what you’re trying to achieve.

We really, really value your perspective on the problems you see, and your stories about what you were trying to do, and what got in the way.

We also love hearing about long term dreams of the ‘wouldn’t it be cool if we could do space-pyramid-unicorn-trips?’ type.

We’ll be a bit less enthused about suggestions like ‘you should change sprocket to work this way’. Partly because it means we need to unpack the why and figure out what problem you’re experiencing, and partly because it feels like you don’t respect our expertise. We’d much prefer it if you didn’t do this because it’s a happier time for everyone.

Jump into our Slack channel and ask us questions and tell us problems you’ve noticed at any time. Or, create a card in our inbox on Trello explaining the problem you’ve noticed and how to replicate.

How do we do remote-first working?

We aim to work in a remote-first way, i.e., one where your choice of working location does not impact on how much you know about what is going on, or how effective you can be. This requires us all to think about how we are working, and to do things a little differently from normal. We encourage everyone to work remotely some of the time, and we all do.

The direction and guidance here is designed to minimise the amount of effort we need to spend on figuring out how we want to coordinate our work together. By operating in consistent and predictable ways, we can devote more energy to the things that matter. This guidance is about the processes (i..e, the way we work) and not the content (i.e., what we do).

Our main working tools are Slack (for communication) and Trello (for task management).

  • You can generally expect your co-workers to be available on Slack during normal business hours or to let you know if they won’t be. Look for the green dot. Replicate what you would do if you were in the same room in writing. Say hello. Tell us you are heading out for an appointment. Show us photos of your outlook, or your cat (or horse).
  • Each team does things slightly differently. You can find a definition of what they do and don’t do, how their Slack and Trello work, how they accept feedback and how they report back to the rest of the organisation here.
  • Know your workmates! Each employee has done our communications style survey to explain how they work and like to be worked with. You can find these here.
  • We prefer to write in public channels in Slack rather than using DMs. Individuals choose exactly where they draw the line, but the idea is that everyone benefits from being able to hear the chat of people going about their work and joining in if that is useful. That said, you don’t need permission to DM someone, so if that is what you need to do, go right ahead.
  • For the same reason, we prefer typing over talking in the office. It isn’t easy to imagine when working remotely, but sometimes the office has five people in it but is silent (apart from all the tapping and the occasional laugh/snort).
  • Anyone can raise a paddle at any time if they are concerned about the direction of something, regardless of whether it’s in their domain or not, and everyone available will stop and address the problem (we’ve had about three of these to date).

Slack and Trello specifically

  • Slack is the operating system for our business. It’s where we communicate and where we get notified for everything.
  • There is a channel for each team (#governance is a private channel for the Board) plus #general for general discussion and #announcements for announcements.
  • Trello is our main workflow tool. Each team has a Trello board, which represents a Kanban board for that team, filled with cards representing the work the team is doing. Each board also has a manager, responsible for keeping it shipshape.
  • The purpose of the board is to:
  • 1/ Enable the team to work together effectively with a minimum of “can you tell me what is happening with that” conversation, and
  • 2/ Enable anyone in Figure to see what your team is up to and the status of those things by looking at the board.
  • Teams have different approaches to exactly how they set up and use their Trello board so that it works for them. But they must always enable those two purposes.
  • We are averse to creating new boards because prioritising and visibility across boards is hard. We have had special boards in the past for temporary processes (like recruitment).
  • Trello is just a workflow tool. It is a good place to record and track what is agreed as the way to proceed, but less good as a place for debating what to do. Related: there is no need to justify why a task is being pursued on a card.
  • Trello is integrated into Slack. Changes to Trello cards are summarised automatically into the relevant Slack channel so that people can see what is changing and follow up if they want to.

Tell me the general remote-first setup


  • You should be in at least the Trello boards and Slack channels for the teams you are in, plus #general and #announcements.
  • You should have Slack alerts set for at least your name or nickname (if it is not the same as your username), for your Trello username (if it is different), and for “paddle”. Some people have notifications for their initials too.

Checkin and checkout

  • Check in in #general at the start of the day with what tasks you expect to be doing and where you’ll be. At the end of the day, check out and update everyone with what you did.
  • The purpose of the checkin is to communicate to others the things that you are aware need to be done by you in the next day or so. And the purpose of the checkout is to let others know what has been advanced.

A list of tasks for a person, mostly marked as incomplete

  • Checkin is intended to cover a single day and be an aspiration, i.e., a helpful guide to what you plan to get up to at the time that you make the list. It is not a die in a ditch promise that these things will definitely happen. If some things carry over or don’t get done, it is no drama.
  • If there is anything you particularly need from others, feel free to mention it too. Are you waiting on any answers, do you need feedback, are you blocked from making progress on anything? You can mention people in checkin to provide a low-stress reminder too, e.g., :white_medium_small_square: Talk with Amy about priorities at 10am.
  • There is no requirement to construct your checkin from your Trello cards, but feel free to if it works for you. Please avoid saying “:white_medium_small_square: Do the cards with my face on them”: it doesn’t tell others what you will be up to.
  • If you do things that were not in your checkin through the day, just pop them in your checkout. There is no need to identify that they were unexpected at the beginning.
  • Checkin and checkout isn’t how we measure productivity or track tasks. So don’t think that a long list is better than a short one, or that if you get side-swiped by the world and end up doing none of it, that that is a problem.

A list of tasks for a person, many checked as completed but some incomplete

  • You might want to star your checkin message or use your personal Slack DM channel to create it so that you can re-use it when creating your checkout at the end of the day.
  • Another pro-tip: you can create the checkin in your personal Slack DM channel and add items or change ::white_medium_small_square: into :white_check_mark: as you go through the day. Then you can just copy and paste the completed checkout into #general at the end of the day.

Alert, alert

  • It is helpful to respond to mentions as soon as you can.
  • If you are online, it is also helpful to set expectations about when you expect to get to things either in Slack or in Trello if you can not get to them straight away or by the requested time. One easy method for casual requests is to react with :eyes: to something that you have seen in Slack so the requester knows you will get to it.
  • There is no expectation you should interrupt what you are doing for someone else’s request if it is not urgent.
  • And if you are offline, mentions are just an FYI until you are back. This will probably take a while to get used to when you first start. You don’t need to be always looking at your phone to see what new requests have arrived: if folks know you aren’t there, then they can wait until you are.
  • Everyone is responsible for managing their own notifications, e.g., you might find that some people snooze them outside of their work hours. If you need to get hold of someone in a hurry and you aren’t sure, consult the communication survey for their preferred method.
  • To minimise distractions, you might want to mute Slack channels that you don’t actively follow. That way you can minimise any FOMO from the way it highlights channels with new messages.
  • Please do not use R-ob as a way to refer to Rob without notifying him. Even if you are really sure that Rob already knows about the thing you are mentioning him for or you don’t want his attention. The practical implication of this is that you will sometimes be mentioned for something you already know about.
  • If you see someone raise a paddle, you’re expected to stop immediately and listen and help. This is an all-hands on deck, pay attention right now situation. As a group, we’ll decide what immediate action needs to be taken, and form a plan for next steps, which might involve making Trello cards for new tasks.
  • If you are not on Slack right at the time and miss the paddle, check in once you see it. If the issue is not resolved, stay with it until it is.


  • Mention upcoming internal or external meetings or calls in your checkin, e.g., :white_medium_small_square: Data team meeting 10am. Afterwards briefly summarise meetings or calls and list their actions. Do this even if you think it does not affect anyone else internally. Sounds weird but it helps.
  • The best place for a meeting summary is Slack (either inline, with threads, or as a Post, depending on how much detail you need). You can put links to the Slack conversation or Post on a relevant Trello card if that is helpful too.
  • If you are in an office conversation in-person, then mention what is being said in Slack at the time or write a short note afterwards. This is always important but especially if something happens on Slack that people working remotely would have no context for.
  • If you call a meeting, the default expectation is that you will write up the results for everyone. Do be sure and schedule enough time to cover both your meeting and the writeup (because otherwise your life is going to be filled with suckful historic meeting writeup tasks and no one wants that).
  • Same with Slack meetings as with meetings in person. Whoever calls a meeting by default makes cards for agreed new tasks. If you think something is important to turn into actions but the person running things does not seem action-oriented enough, then do feel free to raise it at the time. “So, what are the actions out of this?”.
  • If that does not happen and you think that someone other than you should do something, you can make a card in an another team’s Trello inbox that will then be considered within their processes.

Here is a simple meeting report structure you might like to use:

Meeting with whom to discuss what

Attendees from Figure
Attendees from other places

Any relevant background
What was discussed
What comes next
Anything else of note

Fill this out then add it to Slack as a post.

Other communications

  • Anyone can post in #announcements, but that channel is just for announcements. Emoji reactions are welcome but do not reply to messages posted there. Use #general for responses instead.
  • Recognise when it’s time to go higher bandwidth. Sometimes conversations can be better resolved with a video call than by all the typing. Noticing these situations and jumping on a call is important. One rule of the thumb that might help, if you think that it would take more than ten minutes of Slack chat to discuss something or you perceive a high risk of confusion or complexity, then go high bandwidth sooner. Practise saying the words too in random situations just to get used to it: “I think we need to take this to higher bandwidth”. Kinda has a sci-fi feel.
  • If there are several of you in the office on a video call with others who are out of the office, split up into different rooms. That way everyone gets a similar experience.
  • Never use email except for calendar invites, unless an external person is included. If you want to share an email with the team, post it in Slack or on the relevant Trello card.
  • If you have a DM conversation for whatever reason, and it ends up being a thing that could have been public, then say something about it in Slack.
  • There is no expectation that anyone is reading back in the Slack conversation unless they have been mentioned or there is a paddle. Feel free to read back, of course, but don’t rely on someone having seen something if they have not indicated that they have seen it. Linking to a previous Slack message and mentioning someone can be super helpful if you think that they have missed something.
  • Anyone in a Slack channel has access to the full message history, i.e., they can go back to before they joined and read old messages.
  • It can be a bit tricky if more than one conversation is going on simultaneously in the same channel. You can use threads to reply to a particular message in Slack and that will keep replies together. You can also use threads for more persistent content that you want to be easily found, e.g., collecting suggestions on a topic.
  • If you want to chat in a smaller group about something that you’d rather keep out of a public channel, then you can make a multi-person DM channel with up to eight people in Slack. If you are in a DM with someone, and then add another person, that creates a new channel, i.e., the new person cannot see the conversation that the two of you were having before.

Okay, tell me about Trello in more detail


Tasks are represented by a card that moves from left to right across the board. The column represents the current state of the work on the card. Workflows can have many stages, and each team is free to discover and implement their own most effective workflow, but at a minimum each board needs to have:

  • Inbox: A place for ideas. Anyone can request work by adding cards to this column. Typically, only the manager of a board moves cards out of the Inbox.
  • Backlog (or To do): For cards that have all of the required information and are ready to be worked on. They represent work the team intends to do.
  • In Progress (or Doing): For tasks that are being actively worked on. These cards are kept up to date with checklists and comments.
  • Blocked: For work that cannot progress, perhaps because we are waiting on someone externally or because only one team member can action it. “Blocked” is not a criticism, just a description. It is up to each team, but one approach is for the board manager to move cards to blocked if they have not changed state within some reasonable time period.
  • Completed (or Done): For finished work. Experience the joy of watching it pile up. Each team reviews and then archives cards done in the previous week early the following week. To avoid creating a situation where team members feel pressured to work late, we avoid reviews at the end of the week.

In every column cards are sorted in order of approximate priority, with important things towards the top of the column and less important things further down.

Effective cards

  • An effective card has a short simple title and a description that clearly states an action, is assigned to a person (by adding them as a member). If necessary, it may also have a checklist that lists at least the next two or three expected steps.
  • If the card is a complex task, it may have a link to a document or Slack discussion that explains the background as well. You do not need to justify the existence of the task or provide full context. The idea is just that someone outside of your team can get a sense of what is being done and how it is going.

An incomplete checklist of items on a Trello card

  • Generally, any card that is missing any of those things is improved by the board manager before it leaves the Inbox.
  • All cards not in the Inbox or Completed column must have at least one person’s face on them at all times. Team members add and remove each other’s faces as work progresses, and as cards progress they may accumulate comments, links, attachments and checkboxes as tasks are completed.
  • You can look at the example cards on the Product board in case that helps (and copy them over to your board).

A sample Trello card with a title, description and checklist


  • We use members (faces) to quickly show who has current actions on a card. You should work on cards that have your face, and remove your face when you no longer have current actions. Make sure you then add the next person’s face and mention them in a cheery comment before you leave the card. If you are not sure whose face is next, use the board manager’s face to hand it back to them.
  • If you need some assistance from someone else on a task, add their face to a card. No other notification is required (although if your task is urgent, you’d be well advised to get in touch some other way as well). If someone adds your face to a card, treat it as a polite request to help out.
  • The exception to this is the Dev team: if you need help from them, go via Amy, who holds the budget for their time.
  • Bear in mind that some team members may use a different Trello username to their Slack username (but they will have alerts for both setup in Slack).
  • Also bear in mind that tag-teaming faces on a card might not always be the best way to get something done. Especially if what you want to do is have a conversation about something and decide together what to do. Stop, collaborate and listen, peops.

Due dates

We use due dates to indicate when the next step of a task needs to be completed by.

  • When a task also has a set date for completion of all the steps, we note this in the description, and pay special attention to keeping the due date for the next step up to date.
  • Use due dates, for example, where you have made a promise to someone externally. But don’t add arbitrary due dates to internal work (because that reduces the overall urgency of tasks with real due dates). Rely on the prioritisation system to get these things done.
  • Remember that dates are not necessarily priorities: the order of the cards in the pile is the priority.


You can use labels to classify cards by type in your team. For example, the Product team has Feature cards (describing some new functionality to add), Defect cards (describing a bug to remedy), and Enhancement cards (describing an improvement to an existing feature).

  • Labels are not used to indicate state. For example, a card that is blocked should be moved to an appropriate column, not labelled as a “Blocked” card. Likewise, don’t use labels to communicate value, e.g., “Urgent” or “Important.”
  • There is no significance to the label colours, other than to provide a quick visual overview of the card distribution. Remember some of your team mates are colour-blind, so ask for advice if you find yourself wanting to use more than just a few standard colours.

Repetitive tasks

There are some tools to make managing repetitive tasks easier.

  • For tasks you do often and already understand the required process, you can create template cards. These cards hang around in the Inbox with an underscore in front of their name. To create a common task, just duplicate the template card and rename it.

A Trello card with placeholder data in the title, description, and checklist

  • For identical tasks need to be done regularly (e.g., once a week), there’s a Trello powerup that creates recurring tasks. So handy.

A menu of Trello powerups with the Card Repeater highlighted

  • Our organisation Trello account lets anyone use powerups for free, even if your personal Trello account doesn’t have them.

The Trello settings menu with Power-Ups highlighted

Thoughts for board managers

  • You are responsible for regular tending of the board. Be bold. Ask questions. Assign faces. Rewrite descriptions. Engage in discussions about priority. Move cards around.
  • OMG all the cards! An easy way to detect if expectations are getting out of line with delivery is to limit the number of cards permitted in some columns on your board, e.g., no more than five cards in Blocked or no more than 10 in In Progress. Exceeding these “choke” column limits should stop ongoing work and cause a review of outstanding cards and workload.
  • Like a fecund garden, your board will not always be perfect and the amount of time available for tending is limited. It is better to have one list for random cards that need to be sorted at some point than to have random cards spread throughout the workflow. Don’t design your approach that way, but it might be helpful if the team is digging itself out of a hole.
  • It is helpful to remove faces from the Completed column (so that when people look at all their cards, they don’t have the Completed ones cluttering things up).

How can I get emoji-literate?

Here are some conventions you might see in Slack or Trello

In Slack

:white_medium_small_square: for an item in your checkin :memo: an item in your checkout that has been advanced but not completed :white_check_mark: an item in your checkout that is completed :white_check_mark: Also used for budget approvals :eyes: when you want to communicate that you have seen something and will respond, but not right away. :tophat: “sample size of one”: this is just my personal opinion :troll: when you are trolling and want to make it obvious :palm_tree: for your status when you are not working (and folks should not expect you to respond). Don’t use status other than this because who knows what that icon means and it is easy to forget to update it :thumbnotyellow: i support this, i like this, this looks good to me, sweet as :airplane_departure: i am on a plane! :airplane_arriving: i am safely back in the grip of gravity :ie: When you are coming in late to a conversation but want to add something :sassy: Is our way of cheekily delegating work :point_up_2: I agree with the point made above :slack::play: at start of checkin - indicates you are starting the day :slack::pause: When checking out - indicates you are finished for the day

Shortcuts to get colour ids ?Blurple ?Slate

In Trello

Some teams use symbols to communicate other things about their cards, for example:

:whale: Whale. A whale card represents a lot of work, like a major project. :hatching_chick: Quick win. Quick win cards are the opposite: A small task with obvious benefits. :sparkles: New data being processed :rainbow: Data is being updated

Also note that “hats-off” means asking people to consider an issue from the wider organisational point of view, rather than hats-on from the perspective of their own job or team

What documents types should I use?

The tools that you can expect everyone else to have access to are Slack, Trello, a markdown editor, Dropbox and Google Docs plus a web browser (which can view lots of basic file formats including PDF, PNG and JPG).

The basic rules for sharing with others are:

  • Use Slack for everything you can. If you want to write offline, then markdown pasted later on into a Slack post makes for a nicely formatted document that is easily read, shared and searched-for. Think of the historians!
  • Use something else if you have a reason to. Google Docs are great for simultaneous editing and for revisions or feedback on particular words (whereas Slack posts only have one editor at a time, only allow general comments and do not show revisions). Word is no good for internal collaboration, but is helpful for publishing and essential for external bods. Be sure and make Google Docs from your Figure.NZ account.
  • For tabular data, we like CSV format for sharing, but in the real world Google Sheets and Excel are also great.
  • Documents coming from outside will obviously be in a wider variety of formats.

If you are not sharing with others, then by all means use any tool that makes sense to you.

Give me some advice on my specific situation

This is our best accumulated advice on how to use our remote-first approach for some specific situations. We add to this list overtime as we learn more. If you have a question you think needs an answer here, put it on this thread. We will periodically review the documentation and answer new questions.

How do I figure out what to do next?

  • In Trello, all the cards are the same size, and getting a view of actions across boards is not super easy. The best solution: click ‘Show Menu > Cards’. This will show you all the cards with your face on them and you can order the set by board. It is helpful for seeing what is depending on you across all of Trello.
  • On any individual board, you can filter just to show cards with your face on them by pressing Q.
  • Check the Blocked columns for cards with your face before you check anything else.
  • If you have a choice, take a more urgent card from the top of a column rather than a less important card from further down. And bear in mind the quarterly objectives as well, for cards that are related to those.
  • It is up to you to choose amongst the tasks with your face on them. If you are in doubt about priority or think things could be better done another way, ask.

How do I know when my thing will get done?

  • The corollary of the fact that people set their own priorities within the stack of things allocated to them, is that you can’t always know when something will be done by someone else.
  • If there is a defined end-date that you have to meet, make sure it is on the card. If you want to define an internal date, then do it in discussion with those involved in the work. Within your team you might want to give more guidance on how folks should prioritise between cards.

How can I convey tone?

  • For Trello, ensure your card wording is positive and constructive. Board managers are encouraged to revise the wording on cards to improve tone and clarity.
  • In Slack, we have a general principle of assuming good intentions from your workmates. But if you are concerned that your friendly inquiry or request will be misunderstood, you could try directly communicating your tone. Emoji are your friends.
  • Bear in mind in general that remote working means a lot of disembodied interactions. Following these conventions is not a substitute for being kind or for getting to know your workmates.

How can I deal with ongoing tasks in Trello?

  • There is no special behaviour for ongoing tasks. A task does not have to be done quickly, so if it takes time, it takes time.
  • Cards are always in some state (reflected by the column that they are in), have some priority (reflected by where they sit in the pile), and have some level of completion (reflected in updates on the card).

How do I deal with a card that requires multiple actions from different people?

  • One approach is to make a card with a check list for each action that includes the owner of that action in the text. Order the checklist roughly by the order that things need to be done in. Make sure the face of any person with current actions to do is on the card.
  • You could also make multiple lists on a card, with a top checklist to track progress on the overall task and other checklists on the card for more detailed or subsidiary pieces.

Should I make one card or lots of cards?

  • There is a sense of achievement in moving things to Completed, so you might want to keep your cards small enough to be mobile over some reasonable timeframe.
  • One potentially helpful rule is to make cards for tasks that will take more than a few minutes, but don’t make them so big that it takes more than a couple of hours to make any reportable progress on them.
  • There is also a logic in keeping discrete pieces of work as separate cards.
  • Sometimes it can be helpful to make meta-cards to track overall progress on a project, with each step having its own cards create separately. Product tracks progress on a bigger task by using checklists that show the steps to completion.
  • Try to avoid using these meta-cards if you can think of a better way, just because the updating of multiple cards gets tricky, but it can be helpful especially to enable an at-a-glance view of overall project progress.
  • Same story for parallel tasks that are being progressed on more than one board at once, i.e., you can do it, but it can easily be more trouble than it is worth.

What if I want to set different dates for different tasks on a card?

  • You can’t do this directly, although you can always write in text on the card the relevant dates.
  • Our convention is to set the card date as the deadline for the next task.
  • You can also write in the description any final date that a whole card needs to be done by. (You can achieve the same effect by using the custom fields Power Up and creating a custom field for the overall card due date. To get into this magic, click ‘Show Menu > Powerups’.)

What if my task really just involves me?

  • You’d be surprised at how often that little thing that you are doing is of interest to others.
  • If you create cards even for things that only you are working on, other people can see where things are at. This sounds laborious right now, but once you get good at this stuff, it will seem weird to do it any other way.
  • Bonus remote-first points if you write notes to yourself as you go in open Slack channels.

Should I use Trello or Slack?

  • If your update changes something in the workflow, then put it in Trello. If you want to ask a question or check on something or know more, use Slack. If in doubt, use Slack. Remember that Trello card updates go into Slack too, and that you can put a link to a Slack conversation, thread or post on a Trello card.