How to set yourself for success working on complex projects at Feather

Simple problems can live in the head of one person that understands the problem and the solution end to end. You don’t have to communicate, and are fastest on your own.

Complex problems feel harder. Slower. That’s normal.

Breaking down complex problems into simple ones is an amazing skill to have, because then you don't have to deal with a complex problem… but that isn't always possible. So here's what we recommend at Feather for dealing with complex problems:

1. Communication becomes the most important thing. Specifically, repeating what you think is true back to everyone on the team is your main job - you can’t overcommunicate.
2. The plan to solve the problem evolves by you sharing your best guess of the plan with each area expert, and you iterating on the plan based on their input. It will always be wrong to start, and that feels bad if you’re used to simple problems. That’s normal and ok. It’s all the more important to share the “wrong plan”, because that’s the only way you can get it right.
3. It’s your responsibility to tie what we do to useful business outcomes. That can be a better product for customers, save time for ops or reduce technical complexity (the best include all 3!). Cutting corners is ok, and encouraged, because you know if the business outcome is worth the effort. Where it’s not, cut the corner. So really knowing when we have made a difference for the company and what that difference is ensures we do the right stuff, rather than just “doing stuff”.

Simple vs complex projects

How to effectively document and update on the progress of your project at Feather.

> This is an internal company guide that we've shared externally.

The most important thing about a complex project is… communication. Here’s how to set yourself up for success as you’re now in charge of one of these.

### What projects to use this on

**Remote.** We run a mostly remote setup at Feather, and here is how we get things done. I think all of these apply to non remote work too, but maybe the toolstack looks different.

**Non-tech.** While the communication basics apply to all projects, the toolstack is only for non-tech projects. For tech projects we use a different toolstack.

### Complex project communication basics

If you nail these three things, the project will feel easy. Miss any one of them and you’ll end up chasing people, chasing deadlines and things will slip away from you.

**(1) Push updates.** Everyone contributing should be as up to date as possible on the project without them having to pull the information. Especially when progress is made.

**(2) Visibility on current status.** Everyone can see the current status of the work in the obvious place and doesn’t need to ask anyone for the “up to date file” or “what did we decide last time?”

**(3) Clear next steps.** Starting with the release date, you have deadlines for all big intermediate steps, and super specific sub-deadlines for the next intermediate step with names attached.

## The Feather implementation

### Tooling

**Documentation:** Notion. All documents in current versions here, or linked to from here. All expected outputs as empty pages or folders.

**Push updates:** Slack channel for the project. Must have: Link to notion documentation page in the slack channel. Optional: Link to important other files/pages/output directly.

### Workflows

**Doing the project kickoff:** The project owner will outline what the goal of the project is along with the final deadline. Working backwards sub-deadlines are shared in the kickoff, and each person involved with the project has a short call with the project owner on their part in the project. We start this with a message in the slack channel with the project plan as well as the deliverables assigned to each person.

**Setting a push cadence:** The project owner decides on a daily/weekly/bi-weekly cadence of sharing all the main updates that happened since the last update, as well as any changes or updates to the plan. This is shared in the slack channel.

**Maintaining source of truth:** The project owner is responsible for keeping all documents in the notion page up to date.

**Maintaining momentum:** When a sub-deliverable is complete, this should be shared as a win. Use this chance to update and remind everyone of the next steps for the next sub-deliverable.

**Finishing the project:** Depending on the size of the project, post what you did in the releases channel, tag all the people involved, and show off what it means for us/our customers in a Friday celebration. Make sure documentation is up to date, archive the slack channel (unless it turns into a rolling project), and make sure all moving pieces have an owner (probably you!) in future.

When in doubt, over communicate. And read the [simple vs complex projects](https://feather-insurance.com/en-de/feather-in-depth/simple-vs-complex-projects) to understand why.

Your first project at Feather

Learn about Feather's product team evolution for 2024

> We’re sharing how we worked in 2023 as a product team and how we’d like to change things for the year to come.

## Product team at Feather in 2023

In 2023, we had three cross-functional teams of 4-5 contributors each. They were staffed with engineers and designers, and a PM managed the team. The different teams were broadly structured according to areas of expertise. Some teams were focused on user acquisition (signup funnels, quote computation, checkout…), while others focused on post-purchase user experience (managing user policies, making claims…).

The PMs were given a problem and were responsible for shaping the solution. Shaping the solution meant communicating with the person closest to the problem (e.g., customer support) and consulting with developers and designers to gauge the feasibility. 

We started 2023 with a scrum-like process and moved toward a tweaked version of [Shape Up](https://basecamp.com/shapeup) around September.
## Why do we want to change?

While our team setup meant team members got deep expertise in their team’s product area, and we could quickly ramp up projects in existing areas, there were downsides that we wanted to address with our new setup.

A traditional team setup leads to information and expertise silos, and while this was not a major issue for us yet, we felt the need to tackle the problem by swapping team members between teams and by using [push updates](https://feather-insurance.com/feather-in-depth/your-first-project-at-feather) in our communication.

We also realized that we could be more efficient by having direct collaboration between people close to the problem (e.g., customer support) and people creating the solution (e.g., developers, designers). The way our team was set up with PMs acting as a layer between problem space and solution space felt inefficient in that regard. Detaching the problem and solution spaces required more coordination, and pushed us towards a quasi-waterfall process, with designers solving a problem first, and only then handing it over for implementation.

Our team setup offered a clear solution to the problems we were experiencing. Through careful recruitment, folks who work at Feather have a high accountability mentality. We all had frustrating experiences with insurance companies and bureaucracy and agree on how we want to change the industry. We have a common understanding of what a good user experience is.

People with a high accountability mentality don’t need much hand-holding; in fact, they are the kind that strive when given a problem with a blank canvas. We felt that our team setup was doing too much hand-holding and not giving the necessary trust and freedom to the people closer to the problem.

Our homogenous codebase makes it easy for people from different teams to jump and help on other projects. Everything runs on TypeScript (from backend to web to mobile); we share engineering best practices regularly with jour fixes, RFCs, postmortems, etc. We also have a set of reusable utility classes, [a design system](http://dirtyswan.design/), eslint configuration… ensuring a standard across our engineering team. Having a set team to guarantee continuity within a certain area doesn’t feel strictly necessary with such setup.

## Product team at Feather in 2024

We’re going to move away from “fixed” cross-functional product teams. Instead, we will staff teams on a per-project basis. Any individual who will help craft a solution will be part of that team (from customer support to engineers).

Every team will have a lead. This lead will:

- Be responsible for the delivery of the feature.
- Be accountable for meeting the deadline (cutting scope where it makes sense).
- Be responsible for [pushing updates](https://feather-insurance.com/feather-in-depth/your-first-project-at-feather) to the company on the development of the feature.
- Seek external help when necessary*

> Falling behind schedule on a project happens; at Feather, deadlines are important, and they are even more important in Shape Up. When deep in the work, it’s common to over-emphasize the little details that don’t matter much. The team lead should seek advice from our experienced PM to reduce scope and find smart solutions to reach deadlines. Further reading: [Shape Up - Decide When to Stop](https://basecamp.com/shapeup/3.5-chapter-14)

PMs will move to a more strategic role; they will:

- Plan the delivery of the roadmap (as opposed to planning the individual features)
- Educate within the company on how to become a product team lead for your short-term lived-project
- Act as a consultant to every team.
- Oversee all the running projects and ensure they finish on time.

## Related reading materials

- [https://www.lennysnewsletter.com/p/how-linear-builds-product](https://www.lennysnewsletter.com/p/how-linear-builds-product)
- [https://basecamp.com/shapeup](https://basecamp.com/shapeup)

Product team in 2024

Branching policy at Feather: Learn why and how we switched from Git Flow to Trunk-based development.

> This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We’re always looking for talents to join our team [check out our careers page](https://feather-insurance.com/careers)!

There are many different great articles on branching strategies and how to choose them. In this article, I’ll be talking about the current branching policy at Feather and the reasoning behind our choices.  
We started off by using the [GitHub flow](https://guides.github.com/introduction/flow/) with two branches deploying to two different environments. The _main_ branch and the _dev_ branch. Every commit pushed on _dev_ triggers a staging deployment and every commit pushed on _main_ triggers a production deployment. But in one of our [retrospectives](https://www.atlassian.com/team-playbook/plays/retrospective), we realized that we could improve on that.  
The workflow was the following:  

![](https://storage.googleapis.com/popsure-blog-content/1/2023/08/Untitled-2023-08-15-10562-1024x472.png)

We believe in merging as early as possible. This helps us deploy to production faster, but comes at a price of invalidating the staging environment — and QA results — too often.  
We decided to go with a solution where we could be confident enough to deploy at any time.

## We heavily invest in testing

Whenever we make a change to the codebase, we need to be confident that it won’t break anything. This means that we need to heavily invest in testing (unit testing, visual regression testing, end-to-end testing…).

## We merge early and small with the help of feature flags

It’s really important to avoid massive pull requests in order to get quick and efficient code reviews from your peers. A huge feature will get incrementally incorporated in the codebase with small and reviewable commits. When this feature is ready to go to production it’s only a matter of flipping a boolean value or adding a few lines of code (e.g. to make the endpoint public).

## We moved to trunk based development

We realized that with the current setup we didn’t gain anything from using GitFlow. We came to the conclusion that moving to [trunk based development](https://trunkbaseddevelopment.com/) — where developers collaborate on code in a single branch called _trunk_) — will allow us to have a [tidy, linear Git history](https://www.bitsnbites.eu/a-tidy-linear-git-history/), force us to be stricter with our testing coverage, and is more straightforward to work with.

![](https://storage.googleapis.com/popsure-blog-content/1/2023/08/Untitled-2023-08-15-10563-1024x274.png)

Check out our [Deploying our code at Feather](https://feather-insurance.com/blog/deploying-our-code-at-feather/) to know more about how we manage releases.

## Related resources

-   [Git Branching Strategies vs. Trunk-Based Development](https://launchdarkly.com/blog/git-branching-strategies-vs-trunk-based-development/)
-   [Trunk Based Development](https://trunkbaseddevelopment.com)
-   [GitHub flow](https://guides.github.com/introduction/flow/)
-   [Feature Toggles (aka Feature Flags)](https://martinfowler.com/articles/feature-toggles.html)


Branching policy at Feather

Learn how we implemented a user-friendly CI / CD flow to deploy our code at Feather.

> This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We’re always looking for talents to join our team [check out our careers page](https://feather-insurance.com/careers)!

## Introduction

At Feather, we love simple and efficient solutions. We firmly believe in continuous development and continuous integration with the shortest iteration cycle. Our workflows need to be designed so that if we need to deploy to productions _hundreds_ of times a day, we are be able to do so.

We have been invested in automated tests from the start: we practice unit testing, integration testing, end to end tests, and more. We feel confident that we aren’t breaking anything while developing.

We use a branching policy inspired by [Trunk Based Development](https://trunkbaseddevelopment.com) with the use of [Features Toggles](https://martinfowler.com/articles/feature-toggles.html) in order to keep our velocity as high as possible. For version control, we’re using GitHub and our continuous integration and continuous development runs on [GitHub Actions](https://github.com/features/actions). To learn more about this, check out our article on the [Branching policy at Feather](https://feather-insurance.com/blog/branching-policy-at-feather/).

This article describes our release and deployment policy. We have found a way to keep everyone on the team updated on important changes and have integrated it into our development workflow.

## Deploying our code

Every commit pushed to the _main_ branch will trigger a staging build. In addition to this, every commit pushed to the _main_ branch will draft a new release on GitHub with the help of the [release drafter](https://github.com/release-drafter/release-drafter).

The drafted release will contain all the commits added since the previous release and a suggested new version for the (soon to be) new release. The suggested new version is following the [Semantic Versioning](https://semver.org) rules.

In order to deploy our code to production, we simply need to click on the “Publish release” button on GitHub. From there, a GitHub action will take over and take care of the following:

-   Deploy the code to production.
-   Notify the team (on Slack) about a new release being deployed and let them know what’s changed.
-   Bump `package.json` version to one of the drafted releases and push the changes to GitHub.

## Checklist for releasing ✅

![draft-release-detail-view](https://res.cloudinary.com/practicaldev/image/fetch/s--jAYZUacn--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yir3xgvd6ijkhsu62fc9.png)

In order to publish a release we need to:

1.  Check that the SemVer is correct
2.  Check that the “Raw changelog” section contains the changes we wish to deploy
3.  Check that the “What’s changed” section is descriptive enough. This will be read by non-techies 🤓

If everything is correct ✅, click on (4) “Publish release”. The version will shortly go live and the changelog will be sent to the whole team.

## Release notes

Everyone on the team is following our release notes, so they have to be easy to read. That’s why we’ve split the notes into two sections: a high-level summary that is added by the person publishing the release and the raw changelog that’s compiled of all the commit messages.

You can use our release drafter template in your project:
```
name-template: 'app: v$RESOLVED_VERSION'
tag-template: 'v$RESOLVED_VERSION'
template: |
  # What’s Changed 🤩
  _Please insert human readable changelog based on the raw changelog_
  # Raw changelog 📃
  $CHANGES
  ```

It looks like this in our Slack:

![release-note-slack](https://res.cloudinary.com/practicaldev/image/fetch/s--pa1eCiv---/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ny7iuiegqdimv3otlr6x.png)


Deploying our code at Feather

What salary can you expect, and how do we define seniority level.

> This article is part of our internal documentation at Feather. We build our product in the open and share our learnings with the community. We’re always looking for talents to join our team [check out our careers page](https://feather-insurance.com/careers)

In the software industry, it’s sometimes a frustrating experience to speak about seniority since there is no industry-wide standard that defines the difference between a junior and a senior developer. At Feather, we want to give you full transparency about how we define seniority internally and how it is connected to salary.

You may notice that this combines different seniority grids we’ve found online, and we made it our own. For instance, you can feel the inspiration from the [Engineering career path at Alan](https://medium.com/alan/engineering-career-path-at-alan-e5de5c2e740c).

## Seniority grid

We have developed our own seniority framework that includes Junior, Middle and Senior levels. We also added a Staff level, but we are still too small to use it. Currently, it serves as a reference for our Senior engineers.

| | Technical | Collaboration | Recruiting | Scope & Ownership | Knowledge Sharing & Leadership |
| - | - | - | - | - | - |
| Junior developer | <ul><li>Crafts straightforward pull requests that are easy to review</li><li>Ensures a comprehensive functionality of their project in production</li>Is comfortable with Feather's core tech stack (TypeScript, React, Nest, Next, etc.)<li>Ensures sufficient test coverage (unit, integration, e2e) for their code</li><li>Proactively identifies edge cases</li></ul> | <ul><li>Takes an active part in the team's processes and rituals (grooming, planning, daily standups, demos, and project meetings)</li><li>Gives precise technical updates on tasks they have completed and bugs that have been raised</li><li>Isn't afraid to ask questions or clarification to their colleagues</li><li>Accepts constructive feedback and learns from experience</li></ul> | |<ul><li>Owns clearly defined tasks and projects</li><li>Can align with more experienced engineers about scope and technical approach</li></ul> | <ul><li>Contributes to existing documentation and keeps it up-to-date</li><li>Takes ownership of their personal development</li></ul> |
| Early mid developer | <ul><li>Participates in reviewing pull requests</li><li>Is comfortable working on any part of the codebase, after a short ramp up</li><li>Participates in On-call rotation</li><li>Able to debug issues, find root causes and propose solutions</li><li>Manages releases and infrastructure without external help</li><li>Owns the implementation and design of their projects with little guidance</li></ul> | <ul><li>Proactively proposes solution to enhance our tooling and code quality</li><li>Can explain technical concepts to non-technical colleagues</li><li>Helps stakeholders understand implementation boundaries, pushes back when needed</li></ul> | <ul><li>Is able to lead first interview with engineers of their level or below</li></ul> | <ul><li>Owns projects that require research and cross-functional collaboration</li><li>Finds creative solutions to cut scope of their work and iterate faster</li></ul> | <ul><li>Creates useful documentation for engineers and non-technical people</li><li>Holds technical presentations and feature demos</li></ul> | 
| Mid developer | <ul><li>Reasons about the design of our existing systems, and understands what changes would match or contradict a given design</li><li>Solves self-contained problems that are not completely well defined and contain some ambiguity</li><li>Identifies opportunities for improving Feather’s CI/CD and reliability of releases</li><li>Able to work efficiently with Feather’s tech without external help</li></ul> | <ul><li>Owns the discussion of how to solve self-contained technical problems in RFCs, jour fixe meetings, planning sessions, postmortems, etc</li><li>Provides actionable technical feedback to other engineers (i.e. PRs, RFCs, tech talks, documentation)</li><li>Proactively takes over responsibilities of more experienced engineers (i.e. maintaining areas of codebase, monitoring production systems, resolving incidents, leading recurring meetings</li><li>Proactively steps up when someone needs help</li></ul> | <ul><li>Can lead each type of technical interview</li><li>Gives high-quality interview feedback that lead to solid and confident hiring decisions</li><li>Contributes to onboarding, and/or training newer team members</li></ul> | <ul><li>Identifies roadblocks and problems to solve that affect team velocity</li><li>Owns some of the core features, services and projects at Feather</li><li>Doesn’t need guidance from more experienced engineers for their team to be productive and meet goals in time</li></ul> | <ul><li>Gives relevant feedback on RFCs and designs</li><li>Can run an engineering meeting (i.e. book club, frontend jour fixe, backend discussions etc)</li><li>Is able to lead the onboarding and help ramp up new engineers to productivity</li></ul> | 
| Senior developer | <ul><li>Designs new solutions from scratch for difficult problems that are often ill-defined and ambiguous</li><li>Has good judgement of technical risk and is able to find solutions that minimize or avoid it completely</li><li>Speaks out regarding code maintainability and testability, identifies and executes on significant refactors</li><li>Speaks up to ensure quality of team’s work and design decisions</li></ul> | <ul><li>Communicates near-term plans and progress for their team</li><li>Owns the discussion of important technical decisions</li><li>For each solution provided, can lay out the alternative solutions considered, the design tradeoffs made, and identify the technical risks involved and gather info from other teams to get alignment</li></ul> | </li></li></li><ul></li><li>Oversees the recruiting funnel for one or more roles and contributes to final hiring decisions</li><li>Represents the interests of the company outside of work (blog posts and articles, open source presence, meetups and conferences)</li><li>Proactively suggests changes to the process based on their interviewing experience (i.e. candidate’s feedback)</li></ul> | <ul></li><li>Owns long-term projects affecting other engineers and teams</li><li>Identifies and explores areas outside their scope where they could progress company goals without any external guidance or support</li><li>Defines technical direction of their team</li><li>Is trusted to define their own priorities without any external oversight</li></ul> | <ul></li><li>Helps other engineers grow, directly or indirectly</li><li>Can coach and grow mid engineers and lower</li><li>Improves engineering team processes and leads initiatives that benefit everyone (book clubs, jour fixes, workshops etc)</li></ul> | 
| Staff developer | <ul><li>Designs systems that create new technical capabilities at Feather and solve difficult problems that require multiple engineers to build</li><li>Develops effective engineering practices around on-call, dev tools, and planning to maximize the effectiveness of the team</li><li>Proactively improves the stability of systems using better tooling and best practices</li></ul> | <ul><li>Defines engineering roadmap across multiple teams</li><li>Demonstrates leadership within the team about priorities and planning</li><li>Communicates plans to a broad audience to explain/justify their reasoning for major tech choices</li><li>Manages risks across multiple teams, unblocking teams on a technical level and proposing changes to reduce scope</li></ul> | <ul><li>Works with head of engineering to ensure that our recruiting funnel is healthy and that we hire enough engineers</li><li>Improves our interview process so that we make the best hiring decisions possible, and create a compelling experience for candidates</li></ul> | <ul><li>Owns major technology choices such as frameworks, CI, vendor services, open source tools</li><li>Defines the reusable building blocks that Feather requires to scale (design systems, internal tooling and frameworks, architectural concepts etc)</li><li>Owns promotion decision for individual engineers</li></ul> | <ul><li>Mentorship impact improves engineers across multiple teams</li></ul> |

## Salary band

When we’re speaking about compensation, we mean the money you take home before taxes. We’ve seen companies doing tricks to artificially inflate the compensation package by adding stocks, perks, and even vacation days (!) in the total compensation. 
 
When we make an offer to someone, it includes their seniority level, their salary before taxes, and their equity package. We also include [the benefits](https://feather-insurance.com/careers#benefits) – these are the same for everyone in the company.

| Seniority | Compensation range |
| - | - |
| Junior | €45,000 – €55,000 |
| Early Mid | €60,000 – €65,000 |
| Mid | €65,000 – €70,000 |
| Senior | €75,000 – €90,000 |
| Staff | - |

Our salary band reflects what the industry pays a software engineer in Berlin. This is our home base, even though most of the team works remotely. 
 
We review the salary band every year by using the open industry reports. The one in particular that we pay attention to is [Rocket X](https://rocketx.group/), but we also take into account such sources like [levels.fyi](https://www.levels.fyi) and [figures.hr](http://figures.hr).

## Related resources

- [The farther you go up the ladder, the less it’s about your technical skills](https://dev.jimgrey.net/2023/08/14/the-farther-you-go-up-the-ladder-the-less-its-about-your-technical-skills/)

Engineering seniority and compensation at Feather

Learn about how agile development is done at Feather

> tl;dr; If you take a look at our website, our price calculating tools, or even the coverage tables, you’ll see the product of our agile development process. Our team of engineers, product designers, and insurance experts use agile development to provide the information people need about insurance.

## Delivery Speed

When we think about developing new features and business initiatives, we try to emphasize the speed of delivery rather than ironing out the fine details. Of course, this doesn’t mean we put out half-baked products or features. Instead, we follow a quite rigorous process that includes testing to roll out products and features that can be easily improved over time. 

What exactly does this look like? Well, when revamping our dental insurance, we made sure that our most important features worked well and released the landing page. Afterward, we did some A/B testing to see which copy worked the best before finalizing. During that time, many people were still purchasing dental insurance while we got the right wording and design down on the page.  

Still, before releasing the page, we spent a lot of time testing to make sure everything worked as intended. After all, we are dealing with people’s livelihoods since many depend on insurance during the most challenging times in their life. That’s why we make sure our products work well and then adjust for the fine details since no amount of in-house thinking can beat a real-life market test. 

## Lean machine

Whenever we start working on a new feature, we ask ourselves what the minimal viable product (MVP) is that would serve customers’ needs. That way, we can develop new products as quickly as possible while also learning from them. By doing this, we’re using both the lean method and agile development.

The goal of the lean method and agile development is to develop products and features quickly. We start with developing the minimal viable product and then add on features, content, graphic, etc. in increments as we learn more about customers’ needs. Agile development allows us to test hypotheses faster to make better products that fit customers’ needs better. 

Although this might seem like standard practice, many other companies follow the mantra of “move fast and break things”. At Feather, we’d rather move fast and gently to allow ourselves the opportunity to take every step consciously, so we can learn as we move. 

## It’s about the customers

Our approach also goes along with the values we’ve instilled in the product team at Feather. We start the development journey as quickly as possible and treat users with the respect and care they deserve. By doing this, we’ve seen that customers give us the feedback we need to grow and improve.

It’s important to note that when we start the development process, we sometimes only have a vague idea of what the end product will look like. A lot of our early decisions are based on already released products and what customers have formerly told us they need. For example, our price calculators for our insurance products are always well-received, so we add them whenever possible which is why you can see them on the following pages:

- Public health insurance 
- Private health insurance
- Life insurance
- Bike insurance

For future products, we plan to add them wherever possible. Still, it sometimes doesn’t make sense for some products like expat insurance where there are two fixed prices depending on the basic or premium plans. 

More often than not, we also realize that our original assumptions were wrong about what customers need. And, we’re not ashamed to admit this because agile development allows us to react quickly and move through tight feedback loops to address problems for future customers. 

## Agility FTW

Even though the _Manifesto for Agile Software Development_ was published 20 years ago, it still forms the revolutionary foundation of software development. Questions like “_how do we place individuals and interactions over processes and tools?” or “how can a team respond to change over following a plan?_” might seem simple, but are rather complex when organizing a team around the answers. 

There are [12 guiding principles](https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/) that show us how to build complex products or features in a dynamic environment. Each of these principles calls for teams to embrace flexibility rather than following detailed planning and rigid structures. Otherwise, a team risks becoming reactive instead of proactive. 

At the same time, humans are naturally ill-equipped to deal with uncertainty. We feel safer with tangible solutions and concrete assurances. At Feather, we try to mitigate this to avoid wrestling with ambiguous results from our decisions by presenting our products early on to customers to gather feedback. 

Before including some of our insurance products in German, we opened our German products to a small number of customers to collect feedback and gather information for the next iteration. During this process, we found out that upwards of a third of our daily sign-ups for public health insurance were German speakers. Something we didn’t expect since we’re in the expat market. That’s why nothing is more precious than test results: they show us the direction we need to go while taking off the burden of making a decision from the shoulders of the product team.

## Incremental releases

Releasing products and features in small increments saves both the time and effort of all teams when we sometimes find ourselves at a dead end. While most of us enjoy the success stories some start-ups flaunt, we also struggled before finding our success. 

When Feather was founded, we had no idea if our products were bringing value to customers since we only had an early (and quite frankly crude) version of our current recommendation tool. The backlinks were broken, and we didn’t sell insurance at the time (plus, no insurance company in Germany took us seriously when we told them we wanted to digitize the application and claims process). It was only through customer feedback that we knew what we were doing was needed. People used the information with our recommendations (even if the backlinks were broken) to search for insurance plans and thanked us afterward.

This is the true essence of Agile at Feather: build, test, learn, adapt, and test again in frequent cycles. Often, we will use external tools to build sign-up flows to learn whether the ideas we developed during the “drawing board” phase translate to actual products our customers use. It’s at this stage that we encourage users to reach out and talk to our customer service team to learn more about what customer needs are not being met and how we can weave them into the customer flow. 

## Innovation is a shared responsibility

One aspect of agile development that we find incredibly rewarding at Feather is _transparency_ and the _close relationships_ formed within our organization. Because we’re still a relatively small team (but growing pretty quickly), we have the opportunity to freely exchange ideas with one another and get feedback. That way, no one feels like they have to face a problem alone. 

Doing that in a remote setting is even harder. Still, we’ve found that by encouraging the team to challenge one another, ask questions, and enable them to test ideas, remote teams can come together and build trust through difficult situations. A good example of this is during [Feather hack days](https://dev.to/feather-insurance/hack-days-at-feather-44g3) when people have one day to explore creative solutions every few weeks. 

The true approach to innovation is an agile foundation where people are allowed to step outside the box and know that their ideas will be valued and taken seriously – even if they can’t be implemented. Everyone deserves a chance to see the big picture and think of ways to improve it. 

Want to work with us in an agile environment? We’re hiring for a number of positions which can be found on our [career page](https://feather-insurance.com/careers)!

Agile development: How it’s done at Feather

Learn how we are doing management at Feather for our engineering team. We're constantly iterating on improving our internal processes.

In 2023, we used 1on1s and a classical manager/managee approach to career development for our engineering team. However, reflections on the year revealed challenges, leading us to rethink our strategy for 2024, shifting towards a mentorship model, individual career development, and a focus on personal responsibility as we continue to tailor our approach to fit our company culture.

## How the engineering team was set up in 2023
Our engineering team consists of people with different seniority levels. Given the company size (~50 people, roughly 20% of it being engineering), we didn’t find it necessary to get a proper management layer yet. We thought we would require _some form of management_, so we decided that senior engineers would manage their peers.

We expected managers to:
- Conduct regular 1on1s
- Give feedback
- Be responsible for career development
- Be responsible for the promotion
- Help with technical mentorship

## Reflection on 2023
We realized you can’t expect engineers to act as managers and roll with it; management is way more complicated than that (duh!). We threw senior engineers on management duties without giving them the tools or training to perform that role - it didn’t work how we expected it to.

We didn’t like the dynamic a manager/managee relationship creates. Some managers felt awkward in their positions because they weren’t necessarily much further in their careers than the person they were managing.

Our team structure made it hard for managers to deliver critical feedback without investing much effort into finding _what feedback to give_. Our team setup is very flexible (and will be even more so in 2024 - check out [Product team in 2024](https://feather-insurance.com/feather-in-depth/product-team-in-2024)). A manager wasn’t guaranteed to work on the same team as the person they manage (let alone the same codebase). To give constructive feedback, the manager would need to speak with the persons working on the same project as the managee, spend time looking at the managee PRs, etc. That would take ~20% of your time per person you manage.

Moreover, the fact that managers were responsible for giving feedback jeopardized our feedback culture. We believe feedback should come from whoever, whenever, and not only from the manager.

Midway through the year, we noticed that this setup wasn’t working how we wanted. However, we realized that pairing engineers regularly is very valuable for us. The Manager/Managee relationship turned into a mentoring relationship. 

## Going forward for 2024
We will not ask senior engineers to manage and conduct 1on1s anymore. What we wanted from our managers:

1. **Career development:** Make sure the managee grows on seniority
2. **Yearly review:** Perform yearly review and salary calibration
3. **Check-in:** Regularly check on the growth, happiness, and motivation

### Career development
Engineers will now be responsible for their career development. They can refer to [Feather's Engineering seniority and compensation](https://feather-insurance.com/feather-in-depth/engineering-seniority-compensation) to understand what is needed to reach the next level.

We will encourage them to choose a mentor that can help them grow. We like the concept of mentors because you can easily leave a mentor but can’t leave a manager. Engineers should switch mentors according to what they are lacking (some mentors might have a strong leg in one piece of technology…) - this will require a lot of _self-awareness_ from our engineers - something that we noticed was already the case.

### Yearly review
Another crucial aspect will be to _show your work_ - we won’t have managers preach about your achievements at the end of the year. You need to _show your work_. We are a remote company, and communication is incredibly important. We don’t have much water cooler communication. Instead, a few places to show proactivity are Slack, Notion, jour fixes, etc.

Areas of responsibility will become more important. They will be used to check the proactiveness of engineers.

> At Feather, engineers are assigned one or more areas of responsibility. An area of responsibility is a global topic or technology - the engineer assigned to that area of responsibility is the owner of that topic. They are responsible for maintaining and developing this area, proposing solutions to upcoming problems, writing documentation, etc. Examples of areas of responsibility: Internationalization and tooling, Website performance and SEO, Design system…

### Check-in

We will conduct a check-in 3 times a year with our team (every 4 months). During that time, we will check the following:

- In terms of personal growth, does the person make progress along the [seniority grid](https://feather-insurance.com/feather-in-depth/engineering-seniority-compensation)?
- Is the person motivated by their work and project? Is it time for them to change the team to gain exposure to other technologies or areas of the company?
- Does the person receive actionable feedback from their colleagues? Do they need guidance on what to improve on next?
## Closing words

It’s always tricky to come up with your way of doing management in an organization. There is a lot of great literature on the matter, but it doesn’t necessarily apply to your company. Management is part of the company culture. And company cultures are very unique. As your company culture is unique, you must develop your recipe for management, something that will fit your company culture.

As you can see, we’re still iterating on how we are doing management. We will re-assess how this year went at the end of 2024 and adjust accordingly.

## Related reading materials

- [https://shopify.engineering/what-being-a-staff-developer-means-at-shopify](https://shopify.engineering/what-being-a-staff-developer-means-at-shopify)
- [https://feather-insurance.com/feather-in-depth/product-team-in-2024](https://feather-insurance.com/feather-in-depth/product-team-in-2024)

Get a recommendation based on your lifestyle

Feather in-depth

2024

Management and Engineering at Feather in 2024