Teal’s Engineering Culture and Processes are the culmination of our team’s experiences and opinions on best practices. We made this public as a way for prospective engineers to get a detailed sense of how we do things, and why.
What you will read below is not set in stone. Our processes are constantly evolving. We experiment, sometimes fail and we foster a space for that to be okay. We learn openly.
See Open PositionsWhat you will read below is not set in stone. Our processes are constantly evolving. We experiment, sometimes fail and we foster a space for that to be okay. We learn openly.
Teal Stack
Backend
- Rails@6
- Redis
- Sidekiq
- Postgres
- Hosted on Heroku
Frontend
- Typescript@5
- React@18
- vite@latest
- vitest@latest
- playwright
Team
Skillsets
We generally look for people with a deep skillset in either the frontend stack or backend stack. If they happen to be a full-stack engineer thats great, but it is not something we actively seek out.
Breakdown
The team consists of around 4 frontend engineers and 3 backend engineers. We are hiring, so the numbers might be a bit higher than this.
Process Highlights
- Agile or Kanban: Kanban
- Goal Setting: Velocity (not deadlines)
- Daily Stand-ups: No (kanban fills this need)
New Feature Process
1. Figma Review
While we are not Sprint based, we do have a specific time each week that engineering reviews new features, which come in the form of Figma documents. If there are questions, we ask them in the form of comments in the Figma document. If everything feels clear, we move onto story breakdown
2. Story Breakdown
We break up into smaller groups, sometimes it could be just one person groups tasked with creating the stories for a specific part of the feature. We have detailed idea of the information that needs to go into each story, including acceptance criteria that will be used both to shape tests but also help QA.
3. Story Estimation
Once Story Breakdown is complete, we regroup for estimation. Teal Engineering uses fibonacci points to point our stories based on complexity, and we have a document that outlines with examples to make this easier. We are often aligned here, but when it happens that we are not, we talk through it. Often this leads to a much clearer idea of scope.
4. Backlog Shaping
Once estimation is done, stories can go into the backlog. This is currently done by Keith, who is in tight communication with business stakeholders, and the kanban style means we can quickly adjust what is in the backlog, rather than waiting for the next sprint for changes.
5. Engineering
Engineers pick stories from the top of the backlog, and code :) At this point stories enter the kanban flow, moving from left to right. There is a bit more detail here of course, but you can prob guess what most of our columns are.
Making Time For Bugs
We have a dedicated Trello board for bugs. They are labeled low, medium and high. They are created by our member support team. The below system helps us all feel like we know when to work on bugs versus features and chores.
- High priority bugs trigger a Slack alert to the engineers. They are handled by the first person who can get to them.
- Medium priority bugs are handled as part of the first hour of each engineers day, before feature development begins.
- Low priority bugs are handed during a dedicated block of time once per week. The length of this block varies depending on how many low priority bugs are in the queue
Communication
Slack Text
This is our primary method of communication. Teal Engineering has its own slack channel. We keep most communication here, even if its a question to a single person, which helps with knowledge sharing. We also have a dedicated channel that is the “interface” between engineering and stakeholders. Both of these channels are no-nonsense channels, so we know that if there is talk there its worth looking at.
Slack Huddles
This is an “escalation” when text feels like its working against us rather than for us.
Github PRs
We have code-based discussions here when necessary
Trello
Tickets often receive comments that can serve as updates, as well as cross-team communication if we have stakeholder questions and want to capture that information in the right place.
Zoom Meetings
As mentioned in the meeting section below, we are very very light on meetings. We think asynchronous should almost always come first.
Testing
We LOVE testing. On the backend, we have solid coverage, around 95% using rspec. On the frontend, we have a mix of component-level tests as well as integration tests that actually run all the way through the backend, which gives us a lot of confidence that at least the happy-paths are running smoothly.
Meetings
Teal is very light on meetings, and so is the Teal Engineering.
We do not have daily stand-ups.
- The kanban board is enough to let us all know what everyone else is working on.
We do not have meetings on Mondays or Fridays.
- We should be able to take off Monday or Friday and not miss anything important
Our only regularly scheduled meeting as a team is on Wednesday, which can serve multiple purposes depending on need. It can be a retro when needed, it can be a weekly standup. It can be a time to propose ideas, or vent frustrations.
If it is a week that we are going to review new figmas (features), we schedule a meeting for later in the day Wednesday to review. This makes Wednesday a bit of our sacrificial lamb of a day, but it means we get four days with little to no distractions.
We do have 1-on-1s (between Keith and an engineer) once every two weeks. These are designed to actually be useful, and if they start to feel like a waste of time we either change the cadence or the questions (or both!)
Hours
In general people can keep their own hours within the constraint of being around +/- 3 hours of east coast time. We have people all over the United States, and we’ve even had engineers take some prolonged trips to Europe, where they did a great job finding a good middle ground to both get work done and enjoy time with their family in Europe.
The Annual “Onsite”
Once per year, usually in the winter, we head to Miami for an “onsite.” It lasts around four days, and it is entirely paid for by Teal. We get to stay in a really nice hotel, eat delicious food, and hang together, sometimes on a boat. The intent of the trip is really just team building, and for the engineers, this is often a time for a fun project, like a hackathon.
Engineering Onboarding Process
- We have a host of living documentation we walk through.
- Next is getting a local environment up and running.
- We generally start with very small projects, building up confidence and ensuring an engineer starts off with wins. We gradually increase scope and complexity as engineers feel more comfortable.
- During all of this, engineers are on hand to make sure you never feel too stuck :)