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.
The team consists of 4 frontend engineers, 4 backend engineers and data scientist. We are hiring, so the numbers might be a bit higher than this.
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
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.
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.
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.
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.
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.
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.
This is an “escalation” when text feels like its working against us rather than for us.
We have code-based discussions here when necessary
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.
As mentioned in the meeting section below, we are very very light on meetings. We think asynchronous should almost always come first.
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.
Teal is very light on meetings, and so is the Teal Engineering.
We do not have daily stand-ups.
We do not have meetings on Mondays or Fridays.
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!)
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.
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.