How we are organised

We have 8 functional teams:

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

Who is in each team?

💖😍💯👍🏼 Governance 🔭 Strategy 🔮 Revenue 💰 Data 📊 Product ⚗ Development 💻 Comms 🎙 Organisation 👨‍👩‍👧‍👦🏢
Aaron            
Amy            
Andrea            
Chris            
Hayden      
Lillian      
Ludwig          
Martyn            
Miekes            
Nat          
Nigel            
Richard            
Rob          
Stephen            
Vic            

How each team operates

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

Communications team

Why this team exists

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

What are we responsible for

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

How do you know if we are doing a good job

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

How we interface with other teams

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

Our outputs

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

Things we don’t do

  • We don’t micro manage.

Data Team

Why this team exists

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

What we are responsible for

  • Data processing and prioritising content to ensure we meet our obligations

  • Responses to public and internal data queries

  • Research activities (scoping new projects, increasing the collective knowledge on what’s available in the data landscape)

  • Liaising with external stakeholders such as patrons or organisations on data-related projects

  • Assisting in the design of Grace and testing functionalities

  • Maintaining Business Figures’ logic and content

  • Managing and using our Mapbox account

  • Tagging content so people can find it

  • Building relationships between data so people can find it easily

  • Preparing quizzes to be published on The Spinoff and social media

How you know if we are doing a good job

  • There are no errors in content posts

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

  • We are on track with the Data Roadmap (i.e. data is up to date and covers a good breadth and depth)

  • Data Artefacts are [complete]

  • We consistently deliver data projects on time and within budget

How we interface with other teams

  • Raising Grace bugs - via #development and Dev Trello

  • Requesting new Grace features - via Product Trello Board

  • Responding to data queries from other staff - via #general/#data as they pop up

  • Providing cost & time estimates for data projects to the Revenue team

  • Any feedback or suggestions for the data team are welcomed in #data at any time. Please make your comments publicly unless they are sensitive in any way, in which case private Slack or in person is welcomed. We are open to feedback at any time unless specifically stated otherwise. If you find a chart or table with a problem, please let us know immediately and we will deal with it as soon as we possibly can.

  • Please consider carefully and consult in #data with the data team about turnaround times before committing us to any deadlines, as we have a good idea of how long work might take us without putting undue pressure on ourselves

Our outputs

  • Content posts on figure.nz

  • Quizzes

  • Data Artefacts

  • Data Roadmap

  • Enumerations and connections across data concepts (i.e. Business Figures)

Things we don’t do

  • Set priorities for other teams

  • Design user-facing elements

  • Sales

  • Write code

Governance Team

Why this team exists

To make sure Figure.NZ delivers on its mission.

What we are responsible for

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

How you know if we are doing a good job

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

How we interface with other teams

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

Our outputs

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

Things we don’t do

  • Manage or interfere with the day to day operations

Organisation Team

Why this team exists

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

What we are responsible for

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

How you know if we are doing a good job

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

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

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

How we interface with other teams

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

Our outputs

  • Health and Safety Policy

  • A smoothly-running office environment

  • Six million small technical things that make your life better

Things we don’t do

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

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

Product Team

Why this team exists

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

What we are responsible for

  • Enabling people to find and use the data we have

  • Gathering requirements from users

  • Gathering requirements from other teams

  • Designing products

  • Designing graphics

  • Testing ideas

  • Providing a cohesive set of products

  • Managing projects

  • Ongoing measurement and improvement of our products

  • Prioritising product development

  • User research

  • Artefacts that need to be maintained

  • The product

How you know if we are doing a good job

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

  • Projects are delivered on time and on budget

  • The Development team knows what to do

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

  • People are using our products more and more

  • Our analytics measure and reflect how well we are doing

How we interface with other teams

  • Anyone can attend our weekly team meeting and ask questions

  • Anyone can ask a question in any channel

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

  • Anyone can put a card in our product backlog, but only a Product team member can push it to To Do. Not doing a card has to be agreed with the person who made the card

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

Our outputs

  • Bug backlog (shared with Development team)

  • New Feature backlog

  • Product map

  • Product vision

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

  • Products

  • Documentation for these products

Things we don’t do

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

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

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

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

Revenue Team

Why this team exists

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

What we are responsible for

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

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

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

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

  • We keep the other teams informed of what is looming

How you know if we are doing a good job

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

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

  • We have a strong sales pipeline

How we interface with other teams

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

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

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

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

Our outputs

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

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

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

Things we don’t do

  • We don’t decide how revenue gets spent

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

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

Strategy Team

Why this team exists

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

What we are responsible for

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

How you know if we are doing a good job

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

How we interface with other teams

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

Our outputs

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

Things we don’t do

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

How do we communicate with each other?

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

Communication style questionnaire

Planning/Research

  • How do you do dreaming?
  • How do you prefer to work on new ideas?
  • How do you 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 you to get the most out of it? (Context etc, ideas, purpose etc)
  • What’s the best way to get an update on work?
  • What’s the best way to get hold of me in a hurry?

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?

Lillian’s communication style

Planning/Research

How do you do dreaming?

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

How do you prefer to work on new ideas?

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

How do you like to ask for input on ideas?

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

General office work

How do I respond to interruptions?

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

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

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

How do I prepare for meetings?

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

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

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

What things do I find challenging?

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

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

Haphazard. Genuine. Open. Emotive.

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

What’s my style when giving feedback?

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

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

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

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

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

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

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

Writing

How do I write?

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

What sort of editing do I need and when?

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

When things go wrong

How do I express frustration?

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

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

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

What’s the best way to provide help?

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

Amy’s communication style

You can read Amy’s communication style on Slack.

Anoushka’s communication style

You can read Anoushka’s communication style on Slack.

Kimberley’s communication style

You can read Kimberley’s communication style on Slack.

Nat’s communication style

Planning/Research

How do you do dreaming?

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

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

How do you prefer to work on new ideas?

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

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

How do you like to ask for input on ideas?

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

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

General office work

How do I respond to interruptions?

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

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

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

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

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

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

How do I prepare for meetings?

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

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

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

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

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

What things do I find challenging?

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

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

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

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

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

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

What’s my style when giving feedback?

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

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

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

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

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

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

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

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

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

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

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

How do we manage passwords?

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

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

The signup process works as follows:

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

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

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

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

How do we start a project?

Project name:

Introduction:

  1. High level description of project, deliverables and benefits
  2. Summary of framework of the project and its purpose
  3. Who the stakeholders are and why
  4. what is success and how will we measure it?

Project Management Approach: (Optional)

  1. Overall management approach, i.e. the roles and authority of who is working on the project
  2. List of what orgs will provide resources (if any)
  3. List of any resource constraints or limitations (see next point)

Mitigate risks:

  1. Define what risks there are
  2. What does the future of this project look like and how to we scale? (Future proofing)
  3. Are there things we need to invest in now that will help us scale/grow/reduce error/etc

Project Scope:

  1. What the project does and does not include (provide as much detail here as possible) and if anything is going to be outsourced

Milestone list:

  1. Introduction paragraph to add any context/insight into the major milestones and if any changes to delivery dates etc are req.
  2. List of milestones and dates for each milestone (Milestone > Description > Date due)

When does this project finish?

What will we have on this date?

How do I report a bug to dev?

Great bug reports help our development team quickly and easily find the solution to your problem without needing to pester you for more details.

It’s also respectful of the time of the developers.

There are three things you need to know:

  1. Where do I raise a bug?
  2. How do I raise a good bug report?
  3. What do I do next?

Where do I raise a bug?

There are 3 different places to raise a bug:

If your bug is about:

  • Grace, raise a bug here.
  • The Figure.NZ website, raise a bug here.
  • The Guide, raise a bug here.

When raising a bug, remember to follow the guidelines for raising a good bug report so that our lovely development team are happy and can get things sorted as quickly as possible.

How do I raise a good bug report?*

A great bug report is clear, precise, and reproducible.

There are several components that make up a great bug report:

  • A great title
  • A concise, precise description
  • How to reproduce it
  • Additional information, like console logs, images and GIFs,

A great title

A great title can be scanned by your colleagues to immediately get a sense of what’s happening, where, when, and how. Remember this is going to have to be picked out from a list of other issues during triage. A descriptive title will also ensure that duplicate reports of the same bug will be quickly spotted.

Bad: User list is bust for this user

Bad: User list is bust for this user How could anyone know what this is without having to click through and read more?

Good: User list not scrollable in Linux on OSX FF34

Good: User list not scrollable in Linux on OSX FF34 This has lots of detail including the operating system and browser being used.

A concise precise description

Be as detailed as possible as to what is actually happening, and how the user experiences it. Be careful to separate observation from fact. For example, did an upload actually fail, or did Grace’s UI just tell you it did?

If you’ve tested anything to see if it fixes or changes the result, include this as well, like clearing cache/cookies.

How to reproduce

For a developer to reproduce your bug, they need more than just the end result. They need to know the conditions it occurs in, and the steps they need to take to get the bug to occur on their machine.

Conditions are everything from Device/Browser/Operating System/Plugins through to customer state (e.g. logged in, logged out, first-time visitor etc.)

Steps is any actions taken on screen that resulted in the broken state. Remember, you might need to go back several steps to trigger the bug.

GIFS and screenshots

Screenshots are the best way to communicate a UI bug. GIFs are the equivalent for interaction bugs. If something is janky, a rough animation or broken transition, a GIF is the easiest way to communicate it. Show, don’t tell.

You can download LICEcap to capture GIFs of the bug.

Check the JavaScript console

If it’s a bug with the UI, it’s always good to check the Javascript console. To do this in Chrome, hit <option>-<cmd>-<J>. If there’s anything red, that’s bad. Take a screenshot of the red text, and include it in your bug report.

Other considerations

  • Does this happen every time? Or is it sporadic. This will influence the severity of the bug, and the complexity of the investigation.
  • What were you doing right before this occurred? Often times there’s an offending prior state that goes unnoticed (e.g. I arrived here by clicking this link in an email)
  • If the bug causes a crash, does the crash log offer any clues as to what might be the underlying cause?
  • What plugins are in use? There are many, many, popular but badly maintained plugins that cause browsers trouble.

The eternal rules of bug reporting

In the QA mindset, Rands outlines the golden rules of bug reporting. Put concisely:

  • If you see something wrong in the product — however big or small, report it as best you can.
  • It is good form to take the time to report the issue as descriptively and thoroughly as possible, but it is more important to report the issue.
  • It is also good form to check if the issue has been reported by someone else, but it is more important to report the issue.

No matter how rudimentary it is, a bad report is better than no report. Everyone in our team should know how to report a bug if they spot a problem, and everyone should feel comfortable doing this.

*Credit and thanks to the team at Intercom.io for their blog post on this, which provided the basis for this content.

What do I do next?

If it’s a bug that has a deadline for fixing, rather than something that can be picked up when we next work on that part of our product, hop into the #development channel in Slack and chat with Richard and Opcode about timelines and severity.

Remember that if everything is high priority, nothing is high priority, so be realistic about deadlines. Unless something is offline, or is blocking us from delivering a necessary piece of client work, it’s probably not urgent.