How we’re organised

We have 8 functional teams:

• Governance
• Partners
• Data
• Product
• Development
• Communications
• Organisation
• Operations

A person can belong to multiple teams. The role they play in each team will be different.

Who’s in each team

💖😍💯👍🏼	Governance 🔭	Partners 👫	Data 📊	Product ⚗	Dev 💻	Comms 🎙	Org 👨‍👩‍👧‍👦🏢	Ops 🔨
Andrea			✅
Karolina			✅
Lillian	✅
Miekes			✅			✅
Nat				✅		✅	✅
Ngapera	✅	✅					✅
Nigel					✅			✅
Rob				✅	✅		✅	✅
Robett	✅
Stephen	✅
Vic	✅

How each team operates

Each team has a clear purpose and defines their own operating style, which we document in the team templates below. Each team’s template covers the work they do, and also pays particular attention to how they interact with other teams and work together to achieve organisational goals.

Governance team

Why this team exists

To make sure Figure.NZ delivers on its mission.

What we’re 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 responsible.
• 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’re doing a good job

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

How we work with other teams

• We respond to any questions from any other teams.
• We 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 and monthly budget.

Things we don’t do

• Manage or interfere with the day to day operations.

Team coordinator

Ngapera.

Partners team

Why this team exists

To secure revenue and build relationships that will help us achieve our mission. This includes helping the organisation understand the wider environment we operate in.

What we’re responsible for

• Identifying, contacting and establishing relationships with new partners that could lead to revenue or outreach opportunities.
• Running a simple process to track, prioritise and advance opportunities.
• Negotiating and finalising contracts with confirmed partners.
• Keeping track of what we’ve committed Figure.NZ to do and ensuring engagement with partners.
• Communicating commitments to other teams, and in particular any requirements we have of them.
• Engaging broadly to maintain a good understanding of what other people and organisations are doing and to share what we’re doing.

How you know if we’re doing a good job

• Revenue is growing over time, measured on a 12-month rolling basis.
• Our runway is at least 6 months long — enough that it doesn’t cause day-to-day anxiety for anyone other than the Partners team.
• We have a strong sales pipeline.
• We have strong and positive relationships with our partners, and can quickly identify and respond to any concerns.
• Our team has a good understanding of our relationship with partners and broader external conversations.

How we work with other teams

• We communicate data publishing commitments to the Data team, ideally engaging before formal commitments are made.
• We share outreach commitments and opportunities with the Communications team, ideally engaging before formal commitments are made.
• We communicate with the Product team to get guidance on how potential project ideas fit with product priorities.
• New ideas for projects, partners or patrons, questions or comments are welcome at any time in the #partners Slack channel or by putting a card in the Inbox of the Partners Trello board.
• We work with the Organisation team to understand ideal revenue targets and timelines.

Our outputs

• In Solve CRM, we document:
  • the view of our sales pipeline
  • records of the Companies and Contacts we interact with
  • our interactions with partners and others.
• Documentation and management of committed actions with partners.
• Secure files of all Figure.NZ’s contracts.

Things we don’t do

• Decide how money gets spent.
• Make external commitments without agreement from the relevant teams.

Team coordinator

Ngapera.

Data team

Why this team exists

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

What we’re responsible for

• Processing data and prioritising content.
• Conducting research, including scoping new projects and building our knowledge of what’s available in the data landscape.
• Meeting data-related commitments to partners, like data publishing, consulting, 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.
• Producing documentation for internal data processes.

How you know if we’re doing a good job

• There are no errors in content posts.
• People can find the data they’re looking for (shared with the Product team).
• We’re on track with our data update timeline.
• We consistently deliver data projects on time and within budget.

How we work with other teams

• We respond to data queries from the Communications team and other team members in the #data and #communications Slack channels.
• We raise Grace bugs (through GitHub) and request Grace features (through Trello), to be discussed with the Product and Development teams.
• We provide time estimates for data projects to the Partners team.
• Feedback or suggestions for the Data team are welcome in the #data Slack channel at any time, unless we’ve specifically said otherwise. Please make your comments publicly unless they’re sensitive in any way, in which case a direct message in Slack or an in-person chat are both good options.
• If you find a chart or table with a problem, please let us know immediately and we’ll deal with it as soon as we can.
• Please consider turnaround times carefully and consult with us in the #data Slack channel before committing the data team to deadlines.

Our outputs

• Content posts on figure.nz.
• Data roadmap (including data discovery list).
• Data team documentation.
• Blog posts.
• Enumerations and connections across data concepts (as in Business Figures).

Things we don’t do

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

Team coordinator

Andrea.

Product team

Why this team exists

The product team supports and manages the creation of Figure.NZ products. This includes technical, non-technical, internal, and external products, as well as any research, analysis, testing, and design related to these.

A product is anything we put in front of audiences, and the systems that support that. This could be one of our websites, a presentation, a survey, a form, a business card, a poster, or something else.

In a nutshell, the product team researches, identifies, and manages the creation of the best products to serve Figure.NZ’s mission.

What we’re responsible for

• The experience and design of Figure.NZ products.
• Helping our teams create the right products to serve New Zealand’s communities, our organisation, and our long-term goals.
• Assessing cost and viability of proposed product and development work to ensure Figure.NZ spends money on the best things. This means sometimes we have to say no to ideas or proposed work.
• Understanding the needs of New Zealand’s communities.
• Understanding the needs of other Figure.NZ teams.
• Understanding the needs of our partners.
• Helping all teams identify the right solutions and products to meet their needs.
• Balancing the long-term Figure.NZ vision with short-term team requirements.
• Supporting and driving the creation and maintenance of products, including https://figure.nz, Grace, Tohu, community engagement resources, surveys, presentation templates, email templates, and more.
• Managing our visual brand implementation.
• Tracking and measuring the effectiveness of our products.

How you know if we’re doing a good job

• People can find and use data we’ve published.
• The Figure.NZ team can get the products they need to deliver their goals.
• Everyone in the organisation is clear about what we’re working on and what comes next.
• The Development team knows what to do.
• Everyone knows how to request product help.
• People use the products we create.
• The Figure.NZ team understands the overall product vision and how this relates to day-to-day work.

How we work with other teams

Getting work done

You should get product involved with your work when:

• You’re creating something that will impact or be experienced by our public audiences. This includes https://figure.nz, Tohu, our blog, and non-web content like training, surveys, question forms, and presentations. Product will help ensure a consistent and great experience.
• You’re working on our internal technical tools, like Grace.

We can also help you if you’re trying to figure out the best process for your internal team work, but this isn’t required.

If you have a suggestion for the our website, Grace, or Tohu, follow this process.

When you need any other design work done, start by filling in the design brief form.

The purpose of this form is to collect all the key info before getting started. It’s a huge help for you and for us, as it makes sure everyone’s clear on what’s needed and what to expect. If you’re not sure what you want (which is totally fine) we can talk through it with you and then complete the form ourselves for you to review, or complete the form together with you.

In general

• Anyone can tell us about their problems or dreams at any time.
• Anyone can ask a question in any channel — mention Nat in your queries to ensure you get a response. If you remember, we’d prefer you ask these in the #product channel so the whole team sees them. We may redirect your query to there.
• We seek the expertise of others when we’re defining things that impact them. This especially applies to the data team when we’re planning and working on Grace and https://figure.nz.
• We discuss work in progress in the #product Slack channel and we post things into the #general channel when they’re ready for wider team feedback.
• We work with the development team on technical products.
• We work with the CTO on identifying appropriate tools and processes, and security and privacy risks.
• We work with the Communications team. They define messaging and rule the words. We look after the overall experience, format, and visuals.
• We know that when you have an exciting product idea, it can be disappointing to hear we’re not going ahead with it. We’re sorry about that, and we’ll do our best to explain why we’ve come to that conclusion.

Our outputs

• Issue trackers in GitHub (shared with Development team).
• Product Trello.
• Product work request form.
• Products.
• Documentation for these products.

Things we don’t do

• Make unilateral decisions without seeking input and considering needs of the other teams.
• Tell the Development team how to build.
• Expect the Development team to perform miracles with limited resources.
• Neglect operational requirements in favour of new features.
• Ignore the communication team’s language guidance.
• Ignore the financial constraints of the organisation.
• Ignore partnership needs.

Team coordinator

Nat.

Development team

Why this team exists

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

What we’re responsible for

• Software development. This includes analysing, designing, building, testing, documenting, deploying, and maintaining our software.
• Managing the software platform, which is largely made up of the Grace application and the public website at figure.nz.
• Ensuring the security and data integrity of our software.
• Providing technical advice.

How you know if we’re 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, listed below in roughly descending order of priority.
  • We aren’t the victims of a hack, and we don’t get 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 doesn’t significantly impact on other teams or the public.
  • The software allows people to perform their tasks.
  • Developers can add new features with relative ease.
  • We’re regularly shipping code — improvements, bug fixes, technical debt cleanup, and anything else required.
• The Product team isn’t surprised by anything relating to development.
• The Chief Technology Officer isn’t unhappy with anything technical.

How we work with other teams

• We give most teams ad-hoc technical advice. We can do this through the #development channel in Slack so everyone in the team can see. We may redirect your question from another channel there if you tag us somewhere else.
• Since technical discussions often need to be high-bandwidth, we can jump into a call or meeting with you — although we may ask for the discussion to be later (rather than immediately), due to the nature of our work.
• We aren’t responsible for deciding what to build and when it’s built. If discussions reveal a software requirement, we’ll redirect these through the Product team process.
• We are responsible for the quality of the codebases we develop. If we — or others — find quality issues, these can be raised by making a card in the Inbox of the Development Trello board. If you think you’ve found an issue for us, but aren’t sure about it, we’re happy to hear from you in the #development Slack channel.
• Work that is our responsibility (defined as cards made on the Development Trello board or assigned in GitHub) and work that comes from the Product team need to be prioritised. We collaborate on prioritisation with the Product team, and this is represented by the ordering of cards in the Backlog list. Note that sometimes lower priority cards “jump the queue” if it’s an intelligent use of time to do this.
• Our interactions with the Product team are as below.
  • Much of our work flows from the Product Trello board to ours, then back again when completed.
  • We discuss prioritisation of work.
  • We have meetings and chats to verify requirements or get more detail on problems, and to provide advice.
• Our interactions with the Data team are as below.
  • We help with diagnosing and fixing problems with Grace that the Data team comes across.
  • We help the Data team do their work more efficiently, such as by making direct database changes on occasion.
  • We discuss software limitations and opportunities, which can flow into new Product work.

If you’re unsure about development-related things, knowing a little about how software development works can be a great help. We’ve prepared a handy document about this.

Our outputs

• Software.
• Documentation.
• Discussion documents and proposals about specific issues.
• Trello cards, largely on the Development board.
• GitHub issues in our GitHub repositories.
• An absence of Trello cards, largely on the Product board.

Things we don’t do

• Commit to responding to out-of-hours service incidents in a given time period, as we don’t have a service-level agreement.
• Implement software changes that should involve the Product team without using their process.

Team coordinator

Nigel.

Communications team

Why this team exists

To drive the long-term behaviour change of New Zealanders understanding our country through figures. We do this through strategic communications, including work with Figure.NZ’s partners.

What we’re responsible for

• Setting communications goals for the organisation.
• Creation of communications content, including campaigns.
• Ensuring our communications are aligned with Figure.NZ’s values.
• Engagement on Figure.NZ’s communications channels, including social media.
• Handling enquiries that come through Figure.NZ’s communications channels. This may involve gathering information from other team members before responding.
• Managing relationships with those we’ve agreed to do communications work with. This is mainly Figure.NZ’s partners, but may include others from time to time.
• Communications and brand guidelines.
• Managing advertising, including Google Ads.
• Public relations.
• Measuring and analysing engagement with our communications, in line with our communications goals.
• Events.
• Print design and production.

How you know if we’re doing a good job

• Meaningful engagement with our communications increases.
• More people know they can understand our country through figures, and they feel enthusiastic and confident about doing so.
• We’re achieving our communications goals.

How we work with other teams

• We throw ideas around in the #communications Slack channel. They’re usually in their early stages, and not yet ready for feedback. When we’re ready for input, we’ll either post things in the #general channel, or tag the relevant people in #communications.
• Sometimes communications things happen that we have limited or no control over — for example, a media article or social media post that uses Figure.NZ charts to present views that are different to our own. One such view could be that dogs are not great. It’s part of our job to handle instances like this — if they need to be handled at all — and we need space to talk about these situations in the #communications channel. Please respect our sandpit.
• We’re open to questions in the #communications channel, and just ask that you respect our sandpit here also.
• If you have an idea for a communications activity, put a card in the Inbox of the Communications Trello board. We’ll consider all suggestions, and decide whether to act on them based on how they line up with our communications goals. If we decide not to act on them, we’ll talk to you about why.
• Please ping one of us if you spot a typo in any of our communications. Typos keep us up at night.
• Before we make any promises to our partners, we talk to anyone who may be affected by new communications commitments.
• We often call on the Data team for help with enquiries from the public, including the media.
• We work with the Partners team on partner communications requirements.

Our outputs

• Communications strategy.
• Communications content.
• Support to partners.
• Media content.
• Print collateral.
• Ads.
• Events.

Things we don’t do

• Communications activities that don’t align with our communications goals.
• Provide expert commentary on figures, say whether occurrences or trends in data are good or bad, or share other’s uses of Figure.NZ data. Read our guidelines on how we talk about data if you’d like to dig further into our reasoning for this.
• Control how Figure.NZ content is used once it’s out in the world.

Team coordinator

Nat.

Organisation team

To deliver a delightful working environment and make sure our systems and tools support us in getting the job done. This includes facilitating the objectives setting process and overseeing risk and compliance for Figure.NZ.

What we’re responsible for

• Reviewing and revising our high level organisational goals and how we measure our impact in relation to them.
• Facilitating the annual objectives setting process and regularly reviewing priorities and goals with the team.
• Working with other teams to ensure the actions and responsibilities that come out of the team objectives process are clear and well-structured.
• Sharing priorities, expected outcomes, and progress with the board.
• Managing budget and cashflow.
• Documenting how things work in the organisation.
• Establishing and maintaining our health, safety and wellbeing processes.
• Running processes to ensure we’ve documented risks on our register and are addressing them.
• Running team processes including regular one-on-one sessions, annual reviews, professional development, and monitoring and addressing team satisfaction.
• Setting and administering our team payroll and leave systems, job descriptions and employment contracts.
• Managing our virtual facilities, including equipment and software systems.
• Facilitating access to shared workspaces as needed.
• Maintaining Tohu content.

How you know if we’re doing a good job

• Team members feel happy and well taken care of, with the equipment and systems they need to be effective and productive.
• There’s a common sense of purpose and direction amongst the team, and we know if we’re winning.
• Team objectives and actions are clearly documented.
• The board is well-informed.

How we work with other teams

• We facilitate an annual objectives setting process with everyone in the team, and monthly sessions to discuss our progress towards those objectives.
• We have regular one-on-one meetings with individuals, as well as other regular engagement to check how people are doing.
• We’re happy to have input in the #organisation Slack channel or the Inbox of the Organisation Trello board at any time.

Our outputs

• Documentation of:
  • clear organisational goals and measures of success
  • processes for how the organisation runs
  • internal systems, including setup guides.
• A published health, safety, and wellbeing policy.
• Risk and incident registers.
• Board reports.
• Required documentation for:
  • Charities Commission compliance
  • accounting standards and fiscal responsibility.
• Tohu content.

Things we don’t do

• Dictate team or organisational priorities.
• Take sole responsibility for organising or managing access to shared spaces Figure.NZ uses.

Team coordinator

Ngapera.

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 we’re responsible for

• The technical infrastructure that hosts figure.nz, Grace, Tohu, and any other software we may produce, particularly:
  • platform security
  • preservation of service.
• Aspects of information security for Figure.NZ that aren’t covered by the Organisation team, including:
  • management of operations-related secrets
  • incident response.
• Providing advice to ensure the scalable, smooth running of Figure.NZ-produced software.

How you know if we’re doing a good job

• The public can use figure.nz 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 remains secret.
• We aren’t the victims of a hack, and we don’t get 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 our support in the design and timely provision of resources to run Figure.NZ software.
• The Chief Technology Officer isn’t unhappy with anything technical.
• Our team is considered around the organisation to be friendly, approachable, inclusive, and supportive.

How we work with other teams

• Anyone can ask us 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.
• Since technical discussions often need to be high-bandwidth, we can jump into a call or meeting with you — although we may ask for the discussion to be later (rather than immediately), due to the nature of our work.
• The #operations channel contains secrets, and sometimes we discuss issues with our systems in there. Occasionally, these issues are serious. Please don’t share anything from #operations with anyone outside Figure.NZ — this is very important.
• We aren’t responsible for developing software. If discussions reveal a software requirement or defect, we’ll help you work out what to do next to get the problem resolved. This usually means talking to the Product team, raising an issue in GitHub, or putting a card in the Inbox of the Product Trello board.
• We are responsible for, and very interested in, anything to do with the security of our software (figure.nz, Grace, Tohu, and any other software we may produce). If you think you’ve found a security vulnerability, please talk to one of us 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 aren’t yet any formal processes for this interaction, because the teams are both small.
• Sometimes, the operations team may 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’ll report status or conclusions in the #general channel.

Our outputs

• Provisioned infrastructure, like servers and other things we need to run our software.
• Documentation.
• Discussion documents and proposals about specific issues.
• Trello cards on the Operations board.

Things we don’t do

• Commit to responding to out-of-hours outage recovery. We don’t have the budget or staff for service-level agreement, so outage recovery is limited to our best effort during business hours.
• Develop Grace, figure.nz, Tohu, or other software — this is the responsibility of the Development team.
• Provide technical support for Figure.NZ equipment, or problems with people’s computers — this is the responsibility of the Organisation team.
• Provide information security support or training for staff — this is also the responsibility of the Organisation team.

Team coordinator

Nigel.

How 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 helps our team work together to find good ways to communicate.

Communication style questionnaire

Planning and research

• 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? For example, do I need to know context, purpose, big picture ideas, or something else entirely?
• What’s the best way to get an update on work?
• What’s the best way to get hold of me in a hurry?

Writing

• 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?

Ngapera’s communication style

Planning and research

How do I do dreaming?

Usually alone and usually late at night is when I feel I am most creative or open to dreaming, but sometimes ideas hit me after a conversation or after reading articles and the like, and I find I need to go and write random thoughts down. Then I like to mind map or draw out my thoughts so it makes sense to me visually. Once I have gathered my thoughts then I tend to read up on it and I also like to talk through them informally with people I trust.

How do I prefer to work on new ideas?

It depends on what the new idea is, but I tend to like working with others on new ideas and hashing out solutions and/or creative ideas. I am fairly open to feedback and input. I do like to formulate a plan, but mostly just to keep from being sidetracked.

How do I like to ask for input on ideas?

I try to be respectful of others time and set up a time to sit down and have a discussion. I find myself that I need to be focussed when helping others on ideas (as opposed to being asked on the fly). But I do tend to find a discussion platform works well as it gives me context or the ability to ask further questions.

General office work

How do I respond to interruptions?

I am pretty malleable by nature, so don’t tend to mind being interrupted — also I am very used to it! The only time I would get mildly upset is if I had a major deadline, in which case I would probably let people know anyway.

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

Just ask me! And let me know when you need feedback by so I can make sure I get it done in a timely fashion.

How do I prepare for meetings?

Depends on the nature of the meeting, but I always read up on the person I am meeting with to try and understand their role and which company they are from. I like to try and find common ground which I find helps with relationships. If I have requested the meeting, I always try and send a brief overview of why I want to meet and any info that may be helpful to them.

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

I am very open to feedback, and even criticism, so don’t have any preference as to how I receive it. I’d rather have honest feedback than proceed with something that isn’t up to scratch or wanted.

What things do I find challenging?

I find it challenging to work in an environment where the team isn’t working well together. I am pretty good at finding wrinkles early on, and my intuition is to want to iron out wrinkles, sans conflict. When a team is working well together and is productive it’s such a great feeling, so anything that upsets that flow is important to me to sort out.

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

Using Slack on the daily is fairly new to me as I have only really used in a project management sense prior to this role. I am learning the ins and outs of Slack, and am actually really enjoying learning how to use it as tool for remote learning and communication. I love emoji and wit so I enjoy the Slack banter.

What’s my style when giving feedback?

Open and honest. Sometimes I like to write my feedback as opposed to giving it right away. I always find I err on the side of caution with written feedback as I have found in the past people can be offended easily. I always try to give feedback constructively rather than critically.

How does information need to be structured for me to get the most out of it? For example, do I need to know context, purpose, big picture ideas, or something else entirely?

I will generally take in information any way it comes and I am not afraid to ask questions if I don’t understand things. But I do really appreciate context and knowing the purpose etc. I really appreciate when information is presented simply, even when it is complex!

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

Ping me via Slack or book in a 10 minute catch up.

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

Text message me.

Writing

How do I write?

Depends what I am writing and who I am writing to! Though I tend to sketch out a plan and try and work within that. I generally tend to write the way I speak and I aim for simple and clear. I can tend to get a bit wordy and fluffy descriptively, so I always edit and see if I can cut things back or ensure that the tone and message are right.

What sort of editing do I prefer and when?

Any! I just really appreciate any editing feedback and input, and especially when it comes to things like grammar. I tend to be more concerned with the overall piece of work and not worry about the finer details. Unless I really need to be across the finer details in which case I will focus energy on that.

When things go wrong

How do I express frustration?

Usually with a big grrr or a loud sigh! I am quite an animated being so it’s not too hard to tell when I am frustrated. It takes quite a lot for me to lose my cool, though. Sometimes I may let an f-bomb slip, woops! But not that often.

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

DM me.

What’s the best way to provide help?

Just ask and I will be sure to let you know. Most of the time a simple “Are you okay? Is there anything I can help with?” will suffice.

Andrea’s communication style

Planning and research

How do I do dreaming?

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

How do I 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 video calls to get things moving along.

How do I 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 me 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 okay 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 — for example, what interests them and how I can be most helpful to that person.

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

I love detail-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 cues 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 😅

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.

How does information need to be structured for me to get the most out of it? For example, do I need to know context, purpose, big picture ideas, or something else entirely?

• 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 as soon as possible 🏃

Writing

How do I write?

Do we really need to open this can of worms? 😄

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 subsided.

What’s the best way to provide help?

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

Karolina’s communication style

You can read Karolina’s communication style on Slack.

Miekes’ communication style

You can read Miekes’ communication style on Slack.

Nat’s communication style

Planning and research

How do I 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 I 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 — like product, dev, and data.

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 I 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 something’s 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 minutes 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 call, 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 also seem to disproportionately help.

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 me to get the most out of it? For example, do I need to know context, purpose, big picture ideas, or something else entirely?

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 10pm and that will get me to take notice (unless I’m genuinely unavailable).

Writing

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 or 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.

Nigel’s communication style

You can read Nigel’s communication style on Slack.

Rob’s communication style

You can read Rob’s communication style on Slack.

How we do remote-first working

We aim to work in a remote-first way — one where your choice of working location doesn’t impact how much you know about what’s going on, or how effective you can be. Read more about why we work like this.

A remote-first approach means we all need to think about how we’re working, and be open to doing things a little differently from other places we’ve worked.

We’ve written down the following information to make it easier to coordinate our work together. By working in consistent and predictable ways, we can devote more energy to the things that matter. It’s important to note this guidance is about the way we work, not the content of our work.

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

Getting started

• You should be in at least the Trello boards and Slack channels for the teams you’re in, plus the #general and #announcements Slack channels. You can be in all the channels and boards, if you want!
• You should have Slack alerts set for at least your name or nickname (if it’s not the same as your username), for your Trello username (if it’s different), and for “paddle” (read more about raising a paddle). Some people have notifications for their initials too.
• Each team does things slightly differently. Read the team operating styles to find out what each team does and doesn’t do, how they use Slack and Trello, how they accept feedback, and how they work with the rest of the organisation.
• Know your workmates! Each of us has written about our communication style to explain how we work and like to be worked with.

How we use Slack

Introduction

• Slack is effectively our office. It’s where we communicate and where we get notified for everything.
• There’s a channel for each team plus #general for general discussion and #announcements for announcements. You’ll be added to all of these when you join, and you can choose to mute the ones you don’t need to pay particular attention to.
• If someone posts something in the #announcements channel that you want to comment on, post your comment over in #general. It seems a bit roundabout, but it keeps #announcements nice and uncluttered, so it’s easy to find things in there. That said, go wild on the emoji reactions in #announcements.
• You can generally expect your workmates to be available on Slack during normal business hours or to let you know if they won’t be. Look for the green dot next to their name. Pro tip: if you don’t have people in your Direct Message (DM) list, you can find them in the Workspace Directory.
• Replicate what you’d do if you were in the same room in writing. Say hello. Tell us you’re heading out for an appointment. Show us photos of your outlook, or your cat (or horse).
• If you’re going to be offline for awhile — say, going to an appointment or for a walk around the block — set a status. This lets everyone else know they shouldn’t expect to hear from you until you’re back. You might also see people type “afk” (meaning “away from keyboard”) in the #general channel when they’re popping out — this is a hangover from when we hadn’t yet discovered the joys of status messages.
• We also use the status settings to remind each other when we’re on holiday 🌴
• Anyone can raise a paddle at any time if they’re concerned about the direction of something, whether it’s in their domain or not, and everyone available will stop and address the problem. We’ve had about 5 of these to date.
• There’s no expectation that any of our team is reading back through all our Slack conversations unless they’ve been mentioned or there’s a paddle. Feel free to read back, of course, but don’t rely on someone having seen something if they haven’t indicated that they’ve seen it. Linking to a previous Slack message and mentioning someone can be super helpful if you think they’ve missed something.
• Anyone in a Slack channel has access to the full message history — that means they can go back to before they joined and read old messages.
• It can get tricky if more than one conversation is happening at the same time in the same channel. You can use threads to reply to a particular message in Slack — this will keep replies together and can make the conversation easier to follow. You can also use threads for content that you want to be easily found later — for example, collecting suggestions on a topic.

Check in and check out

• Check in in #general at the start of the day with the tasks you expect to be doing. If you’re somewhere different than you usually are — maybe at a shared workspace or a different town or city altogether — include that, too.

• At the end of the day, check out and use emoji to update everyone with what you did. Below are the common emoji we use to show where tasks are up to in our check ins and check outs.

  ◻️ = “I’m planning to do this task today.”
  📝 = “I’ve done some of this task, but not all of it.”
  ✅ = “I’ve finished this task!”
  ➡️ = “This task has been moved from today to tomorrow or later in the week.”

• The purpose of the check in is to tell others what things you need to do (that you know about) in the next day or so, and the purpose of the check out is to tell others what’s been advanced.

• Check in is intended to cover a single day and be an aspiration — that is, a helpful guide to what you plan to do at the time that you make the list. It’s not a die-in-a-ditch promise that these things will definitely happen. If some things carry over or don’t get done, it’s no drama.
• If there’s anything you need from others, you can mention it in your check in and tag them in that item. This is especially helpful if you’re waiting on answers, need feedback before going ahead, or are otherwise blocked from making progress on something.
• You can mention people in your check in to provide a low-stress reminder, too — for example, if you have a meeting with someone, you can tag them in that item on your check in.
• You don’t need to construct your check in from your Trello cards, but you can do so if it works for you. Avoid saying things like “◽️ Do the cards with my face on them” — this doesn’t tell others what you’ll actually be working on, unless they go and find all the Trello cards with your face on them.
• If you end up doing things that weren’t in your check in, just pop them in your check out. You don’t have to note that they were unexpected at the beginning, unless unexpected things sent your whole day sideways and you want others to know why you haven’t progressed your planned tasks as much as you’d hoped to.
• Check in and check out isn’t how we measure productivity or track tasks. So don’t think a long list is better than a short one, or that it’s a problem if you get side-swiped by the world and end up doing none of what was on your check in.

• You might want to star your check in message or use your personal Slack DM channel to create it so you can reuse it when creating your check out at the end of the day.
• Another pro-tip: you can create the check in in your personal Slack DM channel and add items or change ◽️ into ✅ 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’s helpful to respond to mentions as soon as you can, but that doesn’t mean you have to respond to them immediately.
• If you’re online, it’s worth setting expectations about when you expect to get to things if you can’t get to them straight away or by the requested time. One easy method for casual requests is to react with 👀 to something that you’ve seen in Slack so the requester knows you’ve seen it and will get to it.
• There’s no expectation you should interrupt what you’re doing for someone else’s request if it’s not urgent.
• If you’re offline (which others will know either because your green dot is off, or because you’ve set a status that tells them so) mentions are just an FYI until you’re back. This can take awhile 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 come in: if folks know you aren’t online, then they can wait until you are.
• Everyone’s responsible for managing their own notifications — for example, you might find some people snooze them outside of their work hours, and this is totally okay. If you need to get hold of someone quickly and don’t know how to, check their communication style for their preferred method of contact.
• Please don’t use “R-ob” as a way to refer to Rob without notifying him — even if you’re really sure that Rob already knows about the thing you’re mentioning him for or you don’t want his attention. The practical implication of this is that you’ll 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’re not on Slack when someone raises a paddle, check in once you see it. If the issue isn’t resolved, stay with it until it is.

Direct messages (DM)

• We prefer to write in public Slack channels rather than using DMs. Each person chooses exactly where they draw the line, but the idea is that we all benefit from being able to see the chat of people going about their work and joining in if that’s useful. That said, you don’t need permission to DM someone, so if that’s what you need to do, go right ahead.
• If you have a DM conversation that ends up being about a thing that could have been public, mention it in a public Slack channel.
• 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’re in a DM with someone, and then add another person, that creates a new channel — that is, the new person can’t see the conversation that the 2 of you were having before.

How we use Trello

Introduction

• 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 (this is usually the team coordinator, as noted in our team operating styles), who’s responsible for keeping it shipshape.
• The purpose of each board is to:
  • enable the team to work together effectively with a minimum of “can you tell me what’s happening with that” conversation, and
  • 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 2 purposes.
• We’re averse to creating new boards because prioritising and visibility across boards is hard. We’ve had special boards in the past for temporary processes, like recruitment.
• Trello is a workflow tool. It’s a good place to record and track the agreed way of completing a task, but it’s not the best place for debating what to do — Slack, video calls, and in-person meetings all work better for this. Related: there’s no need to justify why a task is being pursued on a card.
• Trello is integrated into Slack. Changes to Trello cards appear automatically in the relevant Slack channel so people can see what’s changing and follow up if they want to.

Layout

In Trello, tasks are represented by a card that moves from left to right across the columns in a board. The column a card is in represents the current state of the work on that card.

Workflows can have many stages, and each team can use the workflow that’s most effective for them, but each board needs to have the following.

• Inbox: A place for ideas. Anyone can request work by adding cards to this column — you don’t need to be a member of the team you’re requesting work from. 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 can’t progress, maybe because we’re waiting on someone externally, or because only one team member can action it. “Blocked” isn’t a criticism, just a description. It’s up to each team how they use this column, but one approach is for the board manager to move cards to Blocked if they haven’t 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 situations where team members feel pressured to work late, we avoid doing 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
  • has a description that clearly states an action
  • is assigned to at least one person, by adding them as members.

  If necessary, it may also have a checklist that lists at least the next 2-3 expected steps.

• If the card is for a complex task, it may have a link to a document or Slack discussion that explains the background. You don’t 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’s being done and how it’s going.

• Generally, any card that’s missing any of the above 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 collect comments, links, attachments and checkboxes as tasks are completed.
• You can look at the example cards on the Product board if that helps. You’re also welcome to copy them over to your team’s board as a starting point for your own cards.

Members

• We use members (faces) to quickly show who has current actions on a card. You should work on cards that have your face, and take your face off the card 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’re not sure whose face is next, use the board manager’s face to hand it back to them.
• If you need someone else’s help on a task, add their face to a card. It’s also helpful to comment on the card and tag them, so they know why they’ve been added and what they need to do. If your task is urgent, ping them on Slack, too. If someone adds your face to a card, treat it as a polite request to help out.
• The exception to this is the Development team: if you need help from them, go through the Product team.
• Bear in mind that some team members may use a different Trello username to their Slack username, but they will have alerts for both set up in Slack.
• Also remember 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, peeps.

Cards that need multiple actions from different people

• The best way we’ve found of approaching this is to make a checklist that lists each action as a checklist item, and then tag the person who needs to do each action in the checklist item. 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.

Due dates

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

• When a task also has a set date for all the steps being done, we note this in the description, and make sure to keep the due date for the next step up to date.
• Due dates are most useful when you’ve made a promise to someone externally. Avoid adding arbitrary due dates to internal work, as that reduces the overall urgency of tasks with real due dates. Rely on the prioritisation system to get these things done.
• Remember that dates aren’t necessarily priorities: the order of the cards in the pile is the priority.

Labels

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 fix), and Enhancement cards (describing an improvement to an existing feature).

• Labels aren’t used to indicate state. For example, a card that’s blocked should be moved to the “Blocked” column, not labelled as “Blocked”.
• Likewise, don’t use labels to communicate value, like “Urgent” or “Important.”
• There’s no significance to the label colours, other than to provide a quick visual overview of the card distribution. Remember some of your workmates are colour-blind, so ask for advice if you want 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 for, 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.

• For identical tasks need to be done regularly (say, once a week), there’s a handy Trello Power-Up that creates recurring tasks.

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

Ongoing tasks

• We don’t do anything special for ongoing tasks. A task doesn’t have to be done quickly — if it takes time, it takes time.
• You might like to use checklists on cards for tasks that will take awhile. It helps others to see how the work is progressing, and lets you feel like you’re achieving something as you tick off the items.

Common Trello questions

Should I make one card or lots of cards?

• There’s a sense of achievement in moving things to “Completed”, so you might want to keep your cards small enough that you can complete them in a reasonable timeframe.
• A helpful rule of thumb 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’s also logic in keeping discrete pieces of work as separate cards.
• Sometimes it’s helpful to make meta-cards to track overall progress on a project, with each step having its own cards created 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, because the updating of multiple cards can get tricky. That said, meta-cards can be especially helpful for enabling an at-a-glance view of overall project progress.
• The same goes for parallel tasks that are being progressed on more than one board at once — you can do it, but it can become more trouble than it’s worth.

How do I know when my thing will get done?

• Because we all set our own priorities within the stack of things allocated to us, you can’t always know when something will be done by someone else. If you need to know, ask the people involved directly.
• If there’s a due date you have to meet, make sure it’s on the card.
• If you want to set an internal date to make sure tasks keep moving, do this together with others who are involved in the work.
• Within your team, you might want to decide between yourselves how to prioritise between cards.

Can I set different dates for different tasks on a card?

• Not directly, but you can always note the relevant dates in text on the card.
• Our convention is to set the card due date as the deadline for the next task.
• You can also write in the card 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 > Power-Ups”.

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 isn’t super easy. The best solution is to 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’s helpful for seeing what is depending on you across all of Trello.
• On any individual board, you can filter to just 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.
• It’s up to you to choose amongst the tasks with your face on them. If you’re in doubt about priority or think things could be better done another way, ask.

What if my task really just involves me?

• You’d be surprised at how often that little thing that you’re 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 like overkill at first, but once you get used to it, it’ll seem weird to do it any other way.

Thoughts for board managers

• You’re responsible for regular tending of your 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 know if expectations are getting out of line with delivery is to limit the number of cards allowed in some columns on your board — for example, you might restrict your “Blocked” column to no more than 5 cards, or your “In Progress” column to no more than 10 cards. Going beyond these limits should cause a review of outstanding cards and workload before any more cards are added.
• Like a fecund garden, your board won’t always be perfect and the amount of time available for tending is limited. It’s 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.
• Make sure to take people’s faces off cards once they reach the “Completed” column — then when people look at their cards, they’ll only see current ones.

Meetings

• Because we’re a remote-first team, a lot of meetings happen by video or phone call — these still count as meetings, and are run and documented the same way as in-person ones.
• Mention upcoming internal or external meetings or calls in your check in — for example: ◽️ 10am Data team meeting
• Afterwards, briefly summarise meetings or calls and list their actions. Do this even if you think it doesn’t 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’s helpful too.
• If you’re part of an in-person work conversation that isn’t a formal meeting, mention what’s 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’ll write up the results for everyone. Make sure to allow enough time to cover both your meeting and the write up, because otherwise your life is going to be filled with suckful historic meeting write up tasks — and no one wants that.
• As the caller of the meeting, you’re also the default maker of Trello cards for agreed new tasks, unless it’s agreed that someone else will do this.
• If you’re in a meeting and you think something’s important enough to turn into actions, but the person running things doesn’t seem action-oriented enough, raise it at the time with a friendly “So, what are the actions out of this?”
• If you realise after the meeting that you should have asked that question, and you think someone else needs to do a task, make a card in their team’s Trello Inbox. This will then be considered within their processes.
• Here’s a simple meeting report structure you might like to use.
  • Meeting with whom to discuss what.
  • Date.
  • Attendees from Figure.
  • Attendees from other places.
  • Any relevant background.
  • What was discussed.
  • What comes next.
  • Anything else of note.

  Complete this, then add it to Slack as a post, tagging in anyone else who was in the meeting.

Getting emoji-literate

Here are some emoji conventions you might see in Slack or Trello, and what they mean.

Slack

In check ins and check outs

= “I’m starting my work day.”
◻️ = “I’m planning to do this task today.”
📝 = “I’ve done some of this task, but not all of it.”
✅ = “I’ve finished this task!”
➡️ = “This task has been moved from today to tomorrow or later in the week”
= “I’m finishing my work day.”

Elsewhere in Slack

👀 = “I’ve seen this and will respond, but not right away.”
🎩 = “This is just my personal opinion” (also known as “sample size of one”).
👍🏽 = “I support this, I like this, this looks good to me, sweet as.”
🛫 = “I’m on a plane!”
🛬 = “I’m safely back in the grip of gravity.”
👆,☝🏽, 💯, or ➕ = “I agree with the point made above.”
= “I missed this conversation when it happened, but I have something to add.”

Trello

Some teams use emoji to communicate information about their Trello cards, as shown below.

🐳 = Whales, for cards that represent a lot of work.
🐣 = Quick wins, for cards that represent small tasks with obvious benefits. The opposite of whales.
✨ = New data being processed.
🌈 = Data being updated.
⚒ = Data being reworked.

How to convey tone

• For Trello, make sure 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 each other. If you’re concerned that your friendly inquiry or request will be or has been misunderstood, you could try directly communicating your tone. Emoji are your friends 👯‍♂️
• Bear in mind that remote working means a lot of disembodied interactions 👻 Following these conventions isn’t a substitute for being kind or for getting to know your workmates.

Which document types to use and when

The tools you can expect everyone else at Figure.NZ to have access to are:

• Slack
• Trello
• G Suite, which includes Gmail, Calendar, Google Docs, and Google Sheets
• a markdown editor, like Typora
• a web browser (which can view lots of basic file formats including PDF, PNG and JPG).

The basic rules for sharing documents with others are as follows.

• Use Slack for everything you can. We’re all there on most workdays, so it’s the easiest place to read and share things for feedback. If you want to write offline, then markdown pasted later on into a Slack post makes for a nicely formatted document that’s easily read, shared and searched-for. Think of the historians!
• Use something else if you have a reason to. Google Docs is great for long documents, simultaneous editing, and revisions or feedback on particular sections. While Slack posts are handy in many ways, they can only have one editor at a time, only allow general comments (rather than comments on specific sections), and don’t show revisions. Word is no good for internal collaboration, but is often needed when working with external people.
• If you’re using Google Docs, make sure to create documents 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 people outside of Figure.NZ will obviously be in a wider variety of formats.
• If you’re not sharing a document with others, then you’re welcome to use any tool that makes sense to you!

Other communications

• We use Slack for video calls, too — their help centre has some useful background on how Slack calls work. You can start calls in public channels (anyone who’s in the channel can join these), or directly with one or more people in your DM channel with them. If you see a little telephone icon next to someone’s name, it means they’re on a Slack call.
• Recognise when it’s time to stop typing and start talking — sometimes conversations are better resolved with a video call than by tapping away in Slack. Noticing these situations and jumping on a call is important, so always keep it in the back of your mind. A good rule of thumb is that if you think (a) it would take more than 10 minutes of Slack typing to discuss something, or (b) there’s a high risk of confusion or complexity, it’s probably worth jumping on a call.

• Sometimes, it’s nice to talk about work rather than type about it, whether or not the situation fits the criteria above. It can help make our relationships stronger and more connected even though we’re not often in the same place. If you have an impromptu work call, summarise it into the #general Slack channel using the clapper emoji 🎬, including who was on the call (in italics) and a brief summary. For example:

  🎬 Ngapera, Nat: Discussed how to proceed with MVP and objectives work and now have a working session booked for this tomorrow.

• If there are several of you in the same place on a video call with others who elsewhere, 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 we ask people to consider an issue with “hats-off”, this means considering it from the wider organisational point of view — rather than “hats-on”, which is from the perspective of their own job or team.
• Sometimes, it’s hard to know whether you should share updates or ask questions in Slack or Trello — here’s a quick guide.
  • If your update changes something in the workflow, put it in Trello.
  • If you want to ask a question, check on something, or find out more about something, 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.
• We use a team Google calendar for booking in all-team meetings and holidays (so others know when we’re not going to be at work). You’ll have access to this through your Figure.NZ Google account. When you create a calendar event, click the dropdown menu next to the calendar icon (it’ll show your name by default) and select “Figure.NZ” to add the event to the team calendar. Calendar events on the team calendar show up in our #general Slack channel as a reminder to everyone.
• For any other calendar events — like internal meetings that don’t include the whole team, or meetings with external people — use your individual work calendar.

Raise a paddle

“Raise a paddle” is our way of saying “tell the team something’s wrong”.

Sometimes, you’ll get that uneasy feeling in the pit of your stomach — something’s going wrong. You’ve noticed a thing that others might not have, or you’re in too deep and if you don’t get help soon, you’ll be in trouble.

Don’t worry, we’ve got a process for that.

For some background, you can read Lillian’s blog post, but the main thing you need to know is it’s called “raising a paddle”.

Get ready

For this to work across our whole team, we all need to have “paddle” set up as a highlight word in Slack. This is so that when you type “paddle”, everyone else will get a notification, and when someone else types “paddle”, you’ll get a notification.

Follow these instructions to make sure you’re all set up.

1. Open Slack preferences.
2. Choose “Notification Settings”.
3. Click to open the Notification Settings panel.
4. Scroll down to find “Highlight Words”.
5. Add “paddle”.

Then, you’re all ready for when you or someone else needs help.

Raise your paddle

When you notice something going wrong or you’re badly out of your depth, say in Slack “I’m raising a paddle” and tell everyone why.

What happens next?

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 team, we’ll decide what immediate action needs to be taken, and form a plan for next steps.

What if it’s not as big as that?

Sometimes, you notice something that isn’t quite right, but it’s not an “oh gosh drop everything” raise-a-paddle moment. It’s the quiet, uncomfortable feeling when you see something and start to worry. You think “Am I the only one who sees it?”. You fret about what will happen if it’s not fixed.

Often it’s bad process that’s built up over time and suddenly seems to be a thorn in our side. Other times it’s an impromptu process we’ve put in place to test something out in a hurry, and you can just see how it’s going to go wrong as we grow.

So, what do you do about it?

1. Don’t keep it to yourself. If you’re worried about something, we want to know.
2. Write out your thoughts. Create a Slack post, and note down the following.
   • What the problem is.
   • Any background information you think will help us see the problem.
   • Why this problem is worrying you.
   • What, if any, solutions you can see to mitigate the problem, both in the short and long-term. If you don’t have solutions, that’s also fine. We don’t expect you to solve the problem by yourself, but we do want to know about your worries.
3. Share your post with the team in Slack.

We won’t always be able to fix everything right away, but we can have a look at something and decide to act in a way that will cause the least pain in the future, while still allowing us to get stuff done.

Once your post has been shared in Slack, we’ll create a Trello card with any actions we need to take for it.

Our policies

Health and safety

Figure.NZ cares about the physical, mental, and emotional health and safety of our team and our guests. We want you to be safe and thrive in our workplace.

The safest environment is created when we’re all aware of our surroundings and our behaviour. Everyone is responsible for looking out for each other, identifying and managing risks, and making sure we have a safe and healthy working environment.

These are our health and safety policies. Everyone in our team reads them; if you’re new, this is part of your induction.

Physical health and safety

We keep a register of hazards that exist and accidents that happen in our workplaces. This includes your home if that’s where you work from, and any shared workspaces you use.

If you notice a hazard or have an accident while you’re working, you’re responsible for adding it to the register. This is especially important since we’re a remote-first team and each of us could be working from anywhere. You’re responsible for being super-duper careful and keeping yourself safe. This includes taking plenty of breaks.

We’re here to help you and we care about you being comfortable. Tell us if there’s anything you need to accommodate your physical needs, and we’ll do what we can to make it happen. If you’re a bit shy at first, you can tell someone later when you’re more comfortable.

If you work from home, make sure you have a first aid kit available; if you work from a shared space, make sure you know where the first aid kit is stored.

If you need to go to medical appointments, that’s no problem — our hours are flexible.

Mental and emotional health and safety

We care about your mental and emotional health and safety just as much as we care about your physical health and safety. We know that society can stigmatise mental health and that can make it hard to talk about, so you absolutely don’t have to tell us if something’s going on for you. If you choose to tell us, we’ll be supportive. We won’t judge. We’ll do everything we can to support you, just like we would with physical health and safety.

We’ll work with you to build a strategy to keep you safe and supported without the need for you to tell everyone the details. We’re used to working to avoid or mitigate triggers. When things are hard, we try to create a supportive environment. Whether or not you’ve talked to us about anything specific, we’ll make sure to check in regularly and see what’s going well and what’s not.

Sometimes, it can be hard to tell when someone needs space, or if they’re really struggling and need help — and if they need help, what type of help is needed. As a small team, we’re often really busy and we try and strike a balance between productivity and supportiveness. However, we will always make space if you let us know that you’re drowning, not swimming 🏊🏽.

We’re human. We all make mistakes and say or do things that may cause distress even when we’re doing our best to get it right. Talk to someone else in the team if someone’s said something upsetting or offensive. They’ll listen, and help you figure out the best way to manage it.

If anyone (whether it’s a team member, one of our partners, or a stranger) does or says anything that makes you uncomfortable — and particularly if it makes you feel unsafe — please raise it with the person you feel safest talking to. Then, let Ngapera know. If you want to talk to someone else, Vic or Stephen from our board also welcome hearing from you.

Your responsibilities

I’ve seen something wrong

This includes everything from chairs or keyboards causing you pain, to spills, to bullying.

We’re all responsible for health and safety in our workplaces. This means you need to do the following.

1. If you see something amiss, report it to Ngapera or raise a paddle in Slack.
2. Then, make sure you fix, minimise, or isolate the risk. You don’t need to do this by yourself — make sure to ask for help if you need it.

Workplace hazards

Being a remote-first team means we all work in different places, and each of our workplaces may have its own hazards.

So you’re all set to keep yourself safe, take some time to 👀 look around 👀 your workplace and identify any hazards. You can (and should) also read the hazard and accident register to see if there are any hazards noted there that also apply to your workplace.

I’m not feeling well

If you’re feeling unwell 😷🤒, and especially if you might be infectious, stay home. This particularly applies to those of us who need to commute or who work in shared spaces, as we don’t want germs to spread.

If you feel well enough to work, then work from home. If you don’t, rest up and get better. Your health is the most important thing.

There’s been an accident

Any accidents (or serious near-misses) must be recorded in the hazard and accident register.

Our first aiders are:

• Nat Dudley (St. John Level 2, 2017-11-06)
• Rob Isaac (St. John Level 2, 2017-11-06)

Serious incidents must be reported to Worksafe by Ngapera.

Someone’s asking me for help

Sometimes you’re busy, or you don’t feel like you’re equipped or have enough emotional capacity to help someone else. That’s okay. Don’t leave them hanging, though. Help them find someone else to talk to, either by video call, phone call, or Slack.

Be considerate

Slack is effectively our office, and in its virtual way, it’s open-plan unless you’re direct messaging. Not everyone is comfortable talking about all topics, and people might prefer to talk about some topics privately rather than publicly. Think about everyone around you before you start typing.

By the same token, not everyone feels comfortable asking for help — check in with your team mates if you’re worried about them.

When you’re planning an event or a meeting, think about other people’s needs. Some people need more prep time, to be properly hydrated, are temperature or light-sensitive, or need to monitor their energy levels. Our communication styles are a wealth of information about this kind of thing 💎 You can also check our guide to team events. If you’re still not sure that what you’re planning works for everyone, you can discreetly ask people if they’re comfortable, and check they have what they need. This goes for guests, too!

Who this applies to

This policy applies to all of us. New starters will be provided with a link to read when they join our team. This includes contractors.

If you have visitors to your workplace, make sure you point out any hazards to them.

Confidentiality

While we have a policy of being transparent within our team, there are times when we’re unable to share information until a certain date.

It’s generally fine to talk about any project within Slack or to other team members. However, until these projects are publicly announced by Ngapera or on our own channels, please don’t talk about which partners we have or are about to have. The confidentiality part of our employment agreement applies here, and it’s super-duper important we all stick to it.

Team events

Anyone can throw a team event 🎉 at Figure.NZ. There are 2 types:

1. Informal fun events: hanging with some or all of the team on an opt-in basis.
2. Official events: ones where we’d like everyone to participate.

Informal fun events

If you’re throwing an informal fun event, just clearly state it’s informal (so people don’t feel obliged if they’re not into the activity) and have fun!

Official events

If you’re throwing an official event, it’s important that it’s as inclusive as possible. This means there are some things to consider and communicate to the team ahead of the event.

• Purpose of the event: for example, team building, celebration, or something else entirely.
• How different dietary needs will be catered for.
• Options for drinks, noting that not all of our team drink alcohol.
• Location.
• Transport to and from the location. Keep in mind that some of our team won’t be in their home town or city for events.
• Cost, including what the cost will be, and whether we’ll pay for ourselves or Figure.NZ will cover the cost.
• Accommodation for out-of-towners.
• Childcare options.
• Whether it’s okay to bring partners, family, or friends.
• Ability to opt out of activities if you want, and leave at any time.
• Sound levels: hearing difficulties mean it’s best to avoid loud and busy spaces.
• Temperature: spaces that are too hot or too cold can make people feel uncomfortable, and/or can have unexpected health impacts.
• Performance-based activities: some people are uncomfortable being the centre of attention, which makes activities that involve getting up in front of a group unenjoyable.
• Physical exertion: mandatory sporting activities or physical exertion can make people with physical limitations feel unwelcome or uncomfortable.

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’s included in the risk register

We’ve 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 details.

• Owner: Who’s 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’ll take to reduce the seriousness or existence of the risk.
• Progress: Where we’re up to in taking the mitigation action/s.

How things are added to or addressed in the risk register

We have 3 notifications set up in our #announcements Slack channel:

• First day of the month: “Please review and update the risk register in the next 7 days”.
• Fifth day of the month: “Reminder you have 2 days left to update the risk register”.
• Seventh day of the month: “Ngapera, the risk register is ready to be reviewed”.

Follow these steps to review and update the risk register.

1. Click the link in the Slack notifications to access the register.
2. Look down the column labeled “Owner” and identify all the risks you’re assigned to. Check this every time, as there may be new risks with your name next to them. If you’re assigned to a risk you think would be better suited to someone else, raise this with Ngapera.
3. Review in detail all the cells for each risk you’re assigned to, engaging with any other team members you need input from.
4. If there has been progress since last month, update the “Last changed by staff” column to today’s date, then update the “Progress” column with the information, overwriting any previous content. Otherwise, clear the “Progress” cell. This is so it’s easy for other people to see just what has changed from month to month.
5. When you’ve finished reviewing the information about a risk, enter the date you did the review in the “Last reviewed by staff” column.
6. Scan the rest of the register and think about whether there are any new risks that should be added. If yes, add a new row and fill out the details you can, including who it should be assigned to. If you don’t know all the details of a new risk, raise this with Ngapera.
7. If there are any risks you think need more attention than we’re currently planning to give them, highlight this cell in red. Ngapera will then talk with you about this.

How to suggest ideas or report issues

The Product and Development teams always want to know your ideas and issues with Grace, the Figure.NZ website, and Tohu.

When you have an idea about something new and cool, or encounter something in Grace, the Figure.NZ website, or Tohu that is wrong, not working as you think it should be, we want to know.

Reporting an issue or idea

Urgent issues

If the issue is stopping you doing your job right now, we want to know about it immediately. We don’t want to delay you if you can’t get any work done. This includes things like not being able to publish data, complete an extraction or a migration, Grace or the website crashing, and more. Tell us in the relevant Slack channel below.

• Grace: #development.
• Website: #product.
• Tohu: #organisation.

It’s important you discuss your issue in these channels, rather than by DMing a Development or Product team member. This is because we need to make sure everyone in Development, Product, and Operations is aware of the issue.

If we decide it’s an urgent bug, we’ll start working on it straight away. If it turns out it’s less urgent, we’ll create an issue report for you in GitHub following the process below.

Other issues or ideas

If your issue isn’t stopping you from doing your job, or you want to suggest an idea, please report the problem by going to one of these pages.

• The main Figure.NZ website.
• Grace, our data extraction system.
• Tohu, our documentation repository.

Choose the right page for the system you’re reporting a problem with. You can report any kind of problem: it’s the right place for spelling mistakes, feature suggestions, and even serious bugs.

If GitHub gives you an error, log in and try again.

These pages only have 3 things you need to provide:

1. The name of the problem
2. What’s wrong
3. Suggestions for fixing it (optional)

We’ve worked hard to make this very quick and simple. We don’t need to know your lawnmower serial number to get things fixed.

As soon as you fill out that form, the people in the right channel will be notified. They’ll take responsibility for the problem you’ve found and manage it. Depending on what you found or suggested, they may assign it back to you for feedback, or ask you for more information.

All of the known problems are periodically reviewed by the Development and Product teams, and the “OK to fix” tag will be applied. Any problems that have this tag will get fixed in our scheduled maintenance time.

Very occasionally, a problem may not get this tag. This means you’ve found something that’s already a part of some larger piece of work. The Development or Product team can withhold the “OK to fix” tag for this reason, but someone will tell you this has happened.

More about suggesting ideas

We want to hear all about your ideas, especially the middle-of-the-night brainwaves and the things that make you scream into your pillow.

The thing that helps us solve your problems and bring your ideas to life the most is understanding why you care about this. We want to understand the problem you’re trying to solve or the opportunity you’ve seen. This can sometimes be easier and more helpful than trying to describe a solution!

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.

Sometimes we’ll need to pick your brains a bit to fully understand the core intention of your request. 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 the solution that seems to be obvious might not always work.

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.

How we manage external relationships

We use 2 tools for managing our relationships with partners and other external contacts.

• Solve CRM
• The Partners Trello board.

We use each one for different things.

Solve

• Holding contact details of Companies and Contacts (note: we use the word “Companies” to be consistent with Solve’s language, but in reality we’re talking about a mix of companies, government agencies, NGOs and other organisations).
• Tracking interactions with Companies and Contacts. This is done by adding interactions manually, and by bcc’ing Solve with related emails.
• Tracking and managing tasks we’re doing for partners and other Contacts that don’t meet the specifications below for the Partners Trello board. Some examples of tasks we have in Solve are:
  • sending a reminder email to a Contact to follow up on their action
  • noting when to do a regular check in with a Contact
  • creating an activity plan.

Partners Trello board

• Repetitive activities for our group of Figure’s 20 partners — like sending Figure’s Digest emails.
• Activities that involve interaction between multiple parties — like setting up workshops.
• Big activities for partners but that aren’t related to specific contacts or companies — like setting up Solve documentation.
• Strategic activities that may or may not involve specific contacts — like looking at the legislation that Callaghan uses for funding.

Using Solve

Adding Companies and Contacts

• When adding a new Contact, first set up the Company they’re affiliated with.
• If they’re not affiliated with any Company, you can go ahead and set up their Contact entry.

Setting up a Company

• First, check to see if the Company already has an entry in Solve by searching for multiple names that could have been used to set it up.
• If the Company already has an entry in Solve, go directly to adding any relevant Contacts and connect them to that Company entry.
• If the Company does not already have an entry in Solve, go to the Home view (represented by an icon of a house) and select “Add a new record”.
• Select “Company”.
• Make sure the “Owner” of every entry is “Figure.NZ”.
• Fill out the fields in the following way.
  • Company Name: Use the most commonly referred to name — for example, “Inland Revenue” not “IR”; “ATEED” rather than the organisation name written out in full.
  • Other Names: Add all other names you can think of that people may use to search for this organisation.
  • Website: Copy and paste the URL from the company’s main website.
  • Background: Write a short description of the relationship. This should be updated and added to over time, but kept very brief. The purpose of this is for anyone else in our team now or in the future to be able to look at the summary and understand our current relationship with that Company at a high level.
  • Logo: Click the camera icon and upload a hi-res and coloured version of the organisation’s logo. Use a logo that is on a white background and make sure it looks similar to the other logos when you upload it.
  • Click the 3 dots at the top right of the Company profile and select “Track linked emails”.
  • In the Company entry, add relevant Tags under the Profile tab.
    • F20: Those committed to Figure’s 20.
    • Active: All organisations we’re actively trying to get committed to some kind of revenue relationship.
    • Pipeline: Those we aren’t actively working with, but may have potential down the track for a commercial relationship.
    • Customer: All organisations who have paid us for something before, but aren’t in one of the other categories.
    • Collaborator: Organisations we collaborate with, without money changing hands.
    • Community Resilience: Organisations related to this big project.
    • Declined: Those who have declined engaging with us in a partnership and don’t seem likely to be interested in the future.
• After you’ve created a Company, set up and link any Contacts we have with that Company. In particular, make sure you add their work email address so email exchanges can be tracked in Solve by bcc’ing the set-up email.

Setting up a Contact

• First, check to see if the Contact already has an entry in Solve by searching their name.
• If the Contact does not already have an entry in Solve, go to the Home view on (represented by an icon of a house) and select ‘Add a new record’.
• Select “Contact”.
• Make sure the “Owner” of every entry is “Figure.NZ”.
• Fill out the following fields.
  • Salutation: Keep blank unless a special salutation is appropriate such as “Doctor” or “Professor”. We don’t assign “Mr”, “Mrs”, “Ms”, or “Miss” unless specifically preferred.
  • First Name and Last Name: Please make sure you spell these correctly.
  • Job Title: Write this in full — for example, “Chief Executive Officer”, not “CEO”.
  • Related Company: Connect to related Company.
  • Relationship: Assign “Main Contact” if appropriate. There may be more than one Main Contact for a Company.
  • Business Email: Contact’s work email address.
  • Mobile Phone: Use the format “+64212342374” — country code first, and no spaces.
  • LinkedIn: Link to Contact’s LinkedIn profile.
  • Related Contact: Connect the Contact to other Contacts here if appropriate, such as their spouse.
  • Background: Add other notes about the Contact here.
  • Profile Photo: On the Contact’s main Solve profile page, click the camera icon and upload a photo of the Contact, ideally from their LinkedIn profile.
  • Click the 3 dots at the top right of the Contact profile and select “Track linked emails”.
  • In the Company entry, add relevant Tags under the Profile tab.
    • Interested in joining our team: For someone that we should include in any recruiting rounds.
    • Interested in user testing: People we can contact for testing.

Logging interactions

Track all interactions with Companies and Contacts in the Timeline tab. Always use the Company entry as the place to log interactions (except for non-associated Contacts) — this is the best way to build up a timeline of events and gives context to elaborate on the relationship we have with a Company.

Whenever you email people who are entered in Solve, bcc the address figure.nz@Figure.NZ.solve360.com – all of the emails will then automatically track under the Timeline tab.

For any other interaction, such as calls and meetings, select “Log an interaction” and add the following.

• A brief description summarising the interaction e.g. “Call with Annette about data literacy”.
• The date (and time if appropriate) of when it occurred.
• All notes in the text area at the bottom.

Adding tasks

Always use the Company entry as the place to add tasks (except for non-associated Contacts) — this is the best way to create a history of all that we’ve done with a Company.

Under the Manage tab click the + icon and add:

• Title
• Description of task type
• Assign to someone
• Due date
• Colour based on type.
  • Red: Urgent task.
  • Grey: General task.

Connecting Google files

In the manage tab you can also attach links to Google Drive for contracts and other important documents through the + icon. Make sure the appropriate permissions are set first.

Managing your tasks

• Looking back at the 4 main navigation icons in Solve, you’ll see one is an arrow going upwards. Click on this and you’ll see all tasks coming through that are assigned to you.
• Under the Priorities tab is where you’ll find all of the tasks that you have on the go.
• This is where you need to keep track of due dates and importance of tasks, add notes as you go, and then complete the tasks when they are done.

Communication guidelines

Figure.NZ exists to grow data use in New Zealand, so we can all better understand our country and care for our future. We do this by making it easy for everyone to find and use our country’s numbers for free, through our website.

We’re a non profit, we care about our country, and we believe data is for everyone, not just for experts.

The way we communicate is driven by our values. Read on for more about this.

We’re happy to help people find figures that deepen their understanding of a topic. Our approach is impartial, so we won’t tell people what to think. We’re not in a position to definitively say why something has happened in the data, or whether what’s happened is good or bad — but we can help people see the right questions to ask.

All figures we share are collected by other organisations. In the “About this data” section on every chart or map page on our website, we include details about which organisation has collected the data, as well as any information that organisation has shared about how and why the figures were collected.

Tone

Figure.NZ is knowledgeable, trustworthy and impartial, while also being friendly and welcoming.

We know data can be intimidating for people who aren’t comfortable with numbers, and we want to bridge that gap by encouraging curiosity and being helpful when people ask questions. Sometimes we don’t know the answers, and we’re honest about that.

We’re humble, and we take care to talk in ways that aren’t elitist. Figure.NZ believes data is for everyone, and we try to demonstrate this through our communications by meeting people where they are.

We love our country, and we want everyone to understand it, and each other, better.

Language

The language we use is guided by our values, and we aim to communicate in a way that makes everyone feel welcome and included. This means avoiding language that’s violent, obscene, hateful, suggestive, racist, sexist, homophobic, transphobic, or ableist.

We expect the data we share to meet these standards too, and we won’t publish anything that doesn’t. We’re happy to hear from anyone who spots something we may have missed on this front.

We value kindness. We don’t say mean, judgemental, or defamatory things about people or organisations.

We steer clear of using jargon as much as possible, and we do our best to talk in plain language that’s easy for people to understand, no matter how much knowledge they already have.

How we talk about data

Note: these guidelines only apply to Figure.NZ’s brand accounts. On an individual level, we encourage our team members to talk about data as they see fit.

We do the following.

• Encourage people to ask questions about data.
• Answer questions as best we can, based on the information we have.
• Help people find answers elsewhere, if we can’t answer the questions ourselves.
• Use plain language as much as possible. This applies to how we talk about technology, too.
• Explain terms people might not be familiar with.
• Use the same terms as were used in the collection of data — for example, if data was collected “by sex”, we describe it in the same way, rather than saying “by gender”.
• Note (but not give expert commentary on) trends and unusual aspects in the data.
• Highlight certain figures from a chart — for example, the figure for the most recent year.
• Highlight supporting and background information about data — for example, who it was collected by, why it was collected, how often it’s collected, what terms used in the data mean.
• Include links for people to find out more about the data — for example, if we’re sharing data about District Health Board areas, we may include links to information about those areas.

We don’t do the following.

• Use jargon.
• Position ourselves as experts on the data we publish. Having not collected it ourselves, we’re not qualified to give expert commentary. We may offer possible explanations for what’s happened in the data, though. For this purpose, we define expert commentary as follows.
  • Coming from a subject matter expert (which we’re not).
  • Stating a definite position on a subject.
• To maintain our impartiality, we don’t do the following.
  • Say whether occurrences or trends in data are good or bad.
  • Share or retweet other’s uses of Figure.NZ data.
    • This has value in showing people how data can be used, but it’s risky in terms of bias. For example, if we see our data being used for what we consider to be a negative purpose, we’d probably avoid sharing it further.
    • The value of sharing or retweeting Figure.NZ data use on our own channels is limited, as we’re talking to people who already see the value of data use, rather than widening our reach.
    • Compromising our impartiality so we can demonstrate data use to people who are already supportive of Figure.NZ’s mission isn’t a risk worth taking.
  • Share links to news stories that use Figure.NZ data to promote a particular viewpoint.
    • For the same reasons as above, this isn’t worth the risk to our impartiality.

    • In addition, media have far greater audience reach than we do through our channels, so there’s more to be lost than gained (in terms of our impartiality) by sharing their use of Figure.NZ data further.
    • We see media as having an important role to play in making data use part of everyday life in New Zealand, so we want to support journalists to keep using robust figures in their work. While sharing their work further would do this, we can achieve the same thing by working directly with them.

How we engage with people who use Figure.NZ

When we’re engaging with people who use Figure.NZ (through any of our communications channels), we follow the tone and language guidelines set out above, as well as making sure whatever we say is in line with our values.

Much of the engagement we have with people who use Figure.NZ happens on social media. Below is the policy we apply to those interactions.

Social media policy for Figure.NZ brand accounts

Our social media channels are monitored regularly by Figure.NZ. Figure.NZ is not responsible for the personal, political, organisational or religious beliefs of its friends, fans or followers across all social networks.

We encourage you to think about and discuss what you see in the figures we share. Everyone has different experiences, and that means we can see or understand figures differently.

It’s important to us that everyone feels welcome on our social media channels, so there are some things we’re not okay with. These include, but aren’t limited to:

• violent, obscene, hateful, suggestive, racist, sexist, homophobic, transphobic, and ableist posts, links or images
• use of profanity
• comments that threaten or defame any person or organisation
• solicitations, advertisements, or endorsements of any commercial organisations
• off-topic posts by a single user
• repetitive posts copied and pasted or duplicated by single or multiple users.

If you post something we think might make other people feel unwelcome, we’ll remove your post or comment. If you continue to post in this way, we’ll block you.

Notes on this policy

• On removing vs. hiding Facebook comments.
  • If the comment is offensive (as per the guidelines above), we’ll remove it.
  • If the comment is annoying but harmless, we’ll hide it. This means that the person who posted it and their friends can still see it, but no one else can.
• We aim to be open and assume the best of our social media followers, so blocking is a last resort. We’ll only do this if they repeatedly breach the policy above.
• We won’t get into discussions with anyone who wants to debate why their comments have been removed or hidden. The potential for positive results from discussions like this is minimal.

Social media spending policy

Following the March 2019 terrorist attacks in Christchurch, Figure.NZ has chosen to stop spending advertising money on Facebook. This will be our position unless meaningful changes are made to the way the platform is run. Specifically, we’re concerned about Facebook’s handling of live streaming, harmful content, and hate speech.

Figure.NZ also uses Twitter, YouTube, and Google Ads. We haven’t spent advertising money on these platforms before and we don’t intend to now, for the same reasons we’re stopping our spending on Facebook. The exception to this is our use of Google Ad Grants, which provides in-kind advertising for charities.

We know we’re supporting these platforms just by being present on them, but we want to reach all New Zealanders. This means we need to be where people are. For Figure.NZ, the appropriate trade-off is to use these platforms mindfully, without spending advertising money on them.

We’ll keep an eye on the situation and review our position if anything significant changes.

Background

• Lotto, Westpac, TSB pull online adverts in the wake of the Christchurch shootings
• New Zealand’s biggest advertisers make global call for suspension on Facebook advertising

How we write about figures

These guidelines are for when we:

• Write about figures in our external communications.
• Provide figures to people outside of Figure.NZ.
• Use figures in presentations.

They recognise that although precision is often valuable, in some cases we believe it’s more important for people to easily understand and remember figures than it is for us to present the exact figure.

Like all of our guidelines, these aren’t set in stone — we’ll iterate them as we learn more and our views evolve.

These guidelines don’t impact how we present numbers in formats like data tables.

Precision and rounding

Using exact figures

We use the exact figure up to one decimal place in cases where:

• the context implies precision, like interactive charts on figure.nz
• rounding is likely to be applied by the person presenting the figures, like when we provide figures to media
• calculations are going to be made from the figures
• we believe it’s relevant for the way the figures will be used.

Note: there are some cases in which using exact figures can create a false sense of precision. If you’re providing figures for one of the cases described above and you’re not sure whether you should give the exact figure, check with the Data Team.

Using rounded figures

In cases where the key purpose is easily understanding and remembering the figures, we follow the rounding guidelines below.

These cases include:

• social media posts
• quizzes
• other entry-level content, like Facts
• presentations and slide decks.

We also use the words “about” or “around” to communicate that a figure has been rounded.

Rounding guidelines

For all numbers except dollar values: if the source figure includes decimal places, first round to a whole number, then follow the guidelines below.

Figure	Guideline	Examples
Dollar values up to $10	Round to nearest 10 cents	In September 2018, the average price for a takeaway coffee in New Zealand was about $3.90 In September 2018, the average price for a frozen chicken in New Zealand was about $7.60
Dollar values between $10 and $100	Round to nearest dollar	The average hourly wage for 30-34 year olds in New Zealand is about $30
All numbers under 100 (including percentages) except dollar values	Use exact whole number	The median age in Hawke’s Bay is about 41 About 18% of people in Wellington completely trust others
All numbers between 100 and 1,000	Round to the nearest 10	In 2001, there were about 820 Alternative Education students in New Zealand In 2018, the median weekly earnings for self-employed European people in New Zealand is about $770
All numbers between 1,000 and 10,000	Round to the nearest 100	In 2005, there were about 1,200 preschool education businesses in New Zealand In 2005, the average electronic card spend per capita in New Zealand was about $9,600
All numbers between 10,000 and 1,000,000	Round to the nearest 1,000	There are about 41,000 35-39 year olds in New Zealand whose main earnings source is self-employment In January 2018, visitors from Japan spent about $252,000 on tourism in the Southland Region
All numbers between 1,000,000 and 1,000,000,000	Round to the nearest 100,000, use one decimal place, and write out “million”	In the year ending September 2018, there were about 3.8 million international visitor arrivals to New Zealand In April 2018, visitors from Germany spent about $4.7 million on tourism in the Canterbury Region
All numbers over 1,000,000,000	Round to the nearest 100,000,000, use one decimal place, and write out “billion”	In 2018 Q2, there were about $3.7 billion worth of building consents for residential buildings in New Zealand In 2019, about $11.7 billion is forecast to be spent by all visitors to New Zealand

If you’re sharing more than one figure from the same data set, use the same level of rounding for all figures — specifically, the rounding that makes sense for the smallest value. For example, if you were sharing the population count from the 2013 Census, you’d write 1,416,000 for Auckland and 341,000 for Christchurch City.

Past or present tense

• If it’s the most recent data available, use the present tense.
  • There are 27.5 million sheep in New Zealand.
• If it’s data we know has been superseded by more recent data, use the past tense and include the date.
  • In 2005, there were 763,000 students enrolled in schools in New Zealand.

Other

• Always state the area the figure is for.
  • There are 12,000 German Shepherds in New Zealand.
  • There are projected to be 310 plumbers in the Northland Region in 2019.
• When writing “million” or “billion”, write the word out in full wherever possible. If there are space constraints, abbreviate “million” to “m”, and “billion” to “b”.
• When writing percentages, always use the numeral and percentage sign. For example, write “6%” rather than “six percent” or “6 percent”.
• Contextualising numbers can also help with ease of understanding — for example, “1 in 6” is easier to understand than “17%”. When deciding whether to use a statement like this, consider whether it makes understanding the figure easier or not. An example where it wouldn’t make it easier is saying “4 in 9”, rather than “44%”.

Content warnings and inclusive communication

Figure.NZ holds a wide range of figures that we aim to share with a wide range of New Zealanders. The breadth of our data means that, inevitably, some of the figures we hold and share will be upsetting to some people.

Inclusive communication is communication that respects the emotional wellbeing of the people receiving it, and takes care to minimise the negative impacts on them. It does not ignore the potential harm that may be caused.

We use content warnings so we can warn people about these types of content before we share them through Twitter.

Note: As we’ve not yet found a suitably effective content warning method for Facebook or LinkedIn, we’ll instead be selective about which content we share on those channels.

What’s a content warning?

Content warnings tell our followers in advance what we’ll be sharing, so they can decide if they want to avoid it.

Content to warn for

The list of topics that require a content warning will continue to evolve, and we’re open to feedback. If there’s a topic you think should be added to the list, please contact us.

This is our current list, including content examples.

• Suicide. For example, deaths by suicide in New Zealand.
• Self-harming behaviours (self-inflicted injuries, disordered eating). For example, rate of intentional self-harm hospitalisation among New Zealand youth.
• Abuse or assault. For example, aggravated sexual assault in New Zealand.
• Mental health. For example, New Zealand adults diagnosed with mood or anxiety disorders.
• Loneliness. For example, people who felt lonely at least some of the time in the previous four weeks.
• Having a low sense of purpose. For example, the lower end of sense of purpose among people in New Zealand.
• Abortion. For example, proportion of pregnancies ending in abortion in New Zealand.

How we use content warnings

• Before tweeting the content, tweet: “Content warning for [topic] for the next tweet/s. Will be hashtagged #[hashtag]”, including a word describing the topic, for example, “#selfharm”. This second part allows people to mute that hashtag so they can avoid seeing the tweets.
• Example content warning tweet: “Content warning for self-harm for the next tweets. Will be hashtagged #selfharm.”
• Once you’ve tweeted the content warning, tweet the content, threaded to the warning tweet. Make sure to include the previously specified hashtag in every tweet that contains the content you’re warning for.

Style guide

This guide documents how we write in Figure.NZ’s external communications. It covers specific points that come up often, and we’ve put it together to help us save time and be consistent in our writing. It will mostly be used by the Figure.NZ communications team, but anyone is welcome to use it.

Many of the guidelines below are taken or adapted from the Govt.nz style guide or the UK Government Digital Service style guide, which are both excellent references ✨📝

Abbreviations and acronyms

The first time we use an abbreviation or acronym in a piece of writing, we write it out in full. If it will be used again in the same piece of content, we include the abbreviation or acronym in brackets after the first use, and and then use the shortened version.

We don’t use full stops in abbreviations.

Example: “This data comes from the Ministry of Business, Innovation and Employment (MBIE). Aside from being available on the MBIE website, this information is also free for you to use on Figure.NZ.”

Active voice

We use the active voice as much as we can.

Example: “We make it easy for everyone to find and use our country’s numbers for free, through our website”, not “Our country’s numbers are made easy for everyone to find and use for free, through our website”.

Ampersands

We use “and” rather than “&”, unless it’s part of a brand name.

Apostrophes

We don’t add an extra “s” after nouns or names ending in “s”.

Example: “The business’ work”, not “the business’s work”.

Bold

We only use bold when it’s really needed for emphasis — using it too often makes it hard for readers to know which content they should pay the most attention to.

Brackets

Where possible, we avoid using brackets in the middle of a sentence. We always use (round brackets), not [square brackets].

Bulleted lists

Sometimes we use bulleted lists to make text easier to read. If we’re writing about processes where the order of steps is important, we use a numbered list instead.

We use 2 types of bulleted lists — single-sentence lists and multi-sentence lists. You might not know which type you’ll need until you write it, so we suggest writing out what you want to communicate, and then deciding which type is better suited and adjusting the formatting as needed.

Single-sentence lists

When we’re writing a single-sentence list, we:

• always use a lead-in line with a colon at the end
• check each bullet point makes sense running on from the lead-in line
• start each point in lower case, and only use a full stop on the last point.

Single-sentence lists are best suited to when you have a few short items you want to list that make sense starting from the same lead-in line. We describe it as a single-sentence list because the content forms one sentence altogether. It could also be written in sentence format, but using a bulleted list makes it easier to read at a glance.

Example:

“The data we have on figure.nz is:

• public and aggregate
• relevant for New Zealand
• collected by others
• of varying quality
• on lots of topics.”

This would also read correctly as: “The data we have on figure.nz is public and aggregate, relevant for New Zealand, collected by others, of varying quality, and on lots of topics.”

Multi-sentence lists

Multi-sentence lists are introduced by a complete sentence.

• Each point in the list is also a complete sentence.
• Each point can be 1-3 sentences long.
• Each point begins with a capital letter and ends with a full stop.

Multi-sentence lists are best suited to when you’ve got lots of content to cover, and formatting it as a list will make it clearer to the reader. We describe it as a multi-sentence list because it includes several sentences.

Example:

“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.”

Capitals

We avoid writing in ALL CAPITALS because it’s hard to read.

For page or section titles, we use sentence case rather than title case.

Example: “Our objectives process”, not “Our Objectives Process”.

We use capitals for proper nouns and brand names.

Charts

We use “charts”, not “graphs”.

Commas

We use the Oxford comma if it makes a list in a sentence easier to understand.

Example: “Using figure.nz charts, you can compare prices for tomatoes, pumpkin, cauliflower, and kumara”, not “Using figure.nz charts, you can compare prices for tomatoes, pumpkin, cauliflower and kumara”.

Contractions

We use simple contractions to make text feel more conversational and friendly, but avoid complex ones that are harder to read and understand.

Simple contractions include:

• you’re
• it’s
• can’t
• don’t
• isn’t
• there’s
• you’ll
• that’s.

Complex contractions include:

• should’ve, would’ve, could’ve, they’ve
• mustn’t, aren’t, couldn’t, haven’t
• it’d, it’ll.

Data

We treat this as a singular noun.

Example: “The data is from 2018”, not “the data are from 2018”.

Dataset

We use “dataset”, not “data set”.

Dates and times

We write dates as day, month, and year in full, without commas.

Example: “19 September 2018”, not “19 Sept, 2018”.

We don’t use ordinal numbers, like 1st or 3rd, in dates.

We show time using a 12-hour clock.

Example: “5:30pm”, not “17:30”.

We show start and end times in full.

Example: “10am to 11am”, not “10 to 11am”.

We spell out names of days and months in full.

Examples: “Monday to Friday”, not “Mon to Fri”; “12 January”, not “12 Jan”.

Em dashes

We use em dashes — with a space on either side — to separate ideas within a sentence.

Example: “We’re not in a position to definitively say why something has happened in the data, or whether what’s happened is good or bad — but we can help people see the right questions to ask.”

To type an em dash on a Mac keyboard, use “shift + option + minus”.

See further notes on our use of dash and hyphen conventions.

En dashes

We use en dashes to show number ranges.

Example: ages 15–19.

We don’t use an en dash when we’re using the words “between” and “from”.

Example: aged from 15 to 19.

To type an en dash on a Mac keyboard, use “option + minus”.

See further notes on our use of dash and hyphen conventions.

e.g., etc and i.e.

To make our content easier to read, we either write it so these abbreviations aren’t needed, or we use appropriate phrases instead.

We use:

• “for example” instead of “e.g.”
• “that is” instead of “i.e.”
• “And so on” instead of “etc”.

Here’s how to use commas with these phrases.

• If they’re used at the beginning of a sentence, use a comma after them. Example: “You can look up lots of topics on figure.nz. For example, education, health, and travel.”
• If they’re used in the middle of a sentence, use a comma before and after them. Example: “The data Figure.NZ publishes is public and aggregate, that is, we don’t publish any personal or unit record data.”
• If they’re used at the end of a sentence, use a comma before them. Example: “Data from figure.nz is used by many different kinds of organisations — media, small businesses, schools, and so on.”

Figure.NZ and figure.nz

When we’re writing about the organisation, we use “Figure.NZ”. When we’re writing about the website, we use “figure.nz”.

Figure’s 20

We write this as “Figure’s 20”, and it refers to our Figure’s 20 partners.

Fractions

We write out fractions and hyphenate them where needed.

Example: “Three-quarters”, not “¾” or “3/4”.

We only use simple fractions, which we define as those with a denominator of 4 or below.

Specifically, the fractions we use are:

• half (which we write as “half”, not “one-half”)
• a third (which we write as “a third”, not “one-third”)
• two-thirds
• a quarter (which we write as “a quarter”, not “one-quarter”)
• three-quarters.

Hyphens

We sometimes hyphenate words to make sure their meaning is clear.

Example: “8 year old children” could mean children who are all aged 8, or 8 children who are 1 year old. “8-year-old children” means children who are all aged 8.

See further notes on our use of dash and hyphen conventions.

Jargon

We avoid jargon where we can.

The exception is when we’re writing about data and we use the original terms from the data collection — we do this to make sure we’re not changing the meaning of the data. In this case, we explain terms in plain language to make them easier to understand.

Links

We use words only, rather than writing links as URLs.

Example: “Our kaupapa”, not “https://tohu.figure.nz/internal/our_kaupapa”.

The exception is when we’re writing about the figure.nz website — though “figure.nz” is a URL, it’s sometimes clearer to write this than to write “our website”.

We write descriptive links that tell you what you’ll find when you follow them — we avoid linking words like “click here” or “this page”.

We write our email addresses in full, in lower case, and link the entire address. We don’t link to personal email addresses.

Lists

We use lists to make it easier for people to:

• scan the page, and
• understand information by visually separating out the points.

We use bulleted lists to list items or points, and numbered lists for instructions where the order of steps is important.

We try to:

• keep our lists short (2–7 items)
• only use 1 level of nesting.

Macrons

We use macrons when writing Te Reo Māori words. If you’re not sure whether a word needs a macron, you can check by looking it up on the Māori Dictionary.

Example: “Te Reo Māori”, not “Te Reo Maori”.

Follow the instructions at this link to set up your keyboard for typing macrons.

Measurements

The first time we mention a measurement, we write it out in full. If it will be used again in the same piece of content, we include the abbreviation in brackets after the first use, and then use the abbreviation.

When the measurement is written out in full, we use a space between the numeral and the measurement. When the measurement is abbreviated, we don’t use a space between the numeral and the abbreviation.

Example: “In January 2019, the average price of carrots in New Zealand was about $2.50 per kilogram (kg). For capsicums, it was about $10.30 per kg.”

Metadata

We use “metadata”, not “meta data”. On our content pages, metadata is under the heading “About this data”.

Numbered lists

We use numbered lists for processes where steps need to be done in order.

1. First, you do this.
2. You do this next.
3. To finish the process, you do this.

For numbered lists, we use the same conventions for capital letters and full stops as we do for multi-sentence lists — that is, each point begins with a capital letter and ends with a full stop, as does each sentence within a point.

Numbers

We use numerals instead of words when we write numbers.

Example: There are 12,000 German Shepherds in New Zealand.

We use commas and no spaces to separate thousands when the number is over 10,000.

Example: In 2005, there were 763,000 students enrolled in schools in New Zealand.

When writing “million” or “billion”, we write the word out in full wherever possible. If there are space constraints, we abbreviate “million” to “m”, and “billion” to “b”.

Example: There are 27.5 million sheep in New Zealand.

We start with the plus sign and use spaces to separate groups of numbers when we write phone numbers.

Example: +64 21 123 4567.

See more detailed information about how we write about figures, including how we approach precision and rounding.

New Zealand and NZ

Our preference is to write “New Zealand” out in full, but we write “NZ” if there are space constraints.

Okay

We use “okay”, not “OK” or “ok”.

Paragraphs

We aim to keep our paragraphs as concise as possible — 3–4 sentences is ideal.

Partners

We use “partners”, not “sponsors”.

Percentages

When writing percentages, we use the numeral and percentage sign.

Example: “6%” rather than “six percent” or “6 percent”.

Plain language

We use plain language as much as we can.

Quotation marks

We use “curly” quotation marks, not “straight” quotation marks.

We use double quotation marks unless we’re quoting words within a quoted section — in that case, we use single quotation marks.

Remote-first

We use “remote-first”, not “remote first”.

Temperature

We write temperatures with the degree symbol and the abbreviation for “Celsius”.

Example: In 2013, the annual average temperature in New Zealand was about 13°C.

To type a degree symbol on a Mac keyboard, use “shift + option + 8”.

Notes on Figure.NZ’s use of dash and hyphen conventions

The dash and hyphen conventions (em dashes, en dashes, and hyphens) in this style guide aren’t yet consistent with how we use them on our charts. We’re looking at whether we can align these, but if you notice inconsistencies in the meantime, that’s why.

If you’d like to know more about the technical and historical reasons for the difference, read on ⬇️

The hyphen character was found on early typewriters, and because of mechanical limitations, a single key was used to represent a hyphen, the minus sign, and various kinds of dashes. Early computer interfaces were often based on typewriter technology, and some of these historical limitations have carried through into the present day.

In particular, some computer systems have only a single dash character, and they use it ambiguously as a minus sign (a negative value like “-10”), a hyphen (“8-year-old children”), or a dash separating a range of values (“15-19”).

Figure.NZ aims to cut down these ambiguities, and we typically correct this usage in chart titles and captions. You may still see it in tables or datasets exported from our site if it was present in the source data, though.