Transparency, autonomy, responsiveness, and education: How the Aha! engineering team works

Organizations have many different ways to approach how teammates write code. You have individual silos, pair programming, team-based work, and black box interfaces where you have no idea how the other team is structured.

We use a mix of these approaches at Aha! rather than sticking to one methodology. The Responsive Method (TRM) — the framework our co-founders created that guides individual and business success — helps us decide what actions to take in the moment. In general, a single engineer will work on their feature. They will present that work to their smaller team and the full engineering team during weekly meetings. We engage very deeply and make it enjoyable to present. And in that way, knowledge bubbles up to the entire engineering team. That engineer then owns their code for its lifespan and becomes a code champion who educates our team (and possibly presents to the larger community).

Segmenting engineering teams and assigning features

In engineering, we split into small agile teams aligned with different parts of the application. It's pretty easy to see how these teams are structured based on our product offerings (Aha! Roadmaps, Aha! Ideas, Aha! Whiteboards, Aha! Knowledge, and Aha! Develop) along with our infrastructure and security.

For larger offerings such as Aha! Roadmaps, we have several teams. We also have a rotating support team that uses members of each group, which means you see all parts of the application while on that rotation. But in general, each team is an expert in its particular product.

Our products delineate the way we assign features. Our product managers use The Aha! Framework to do the Sisyphean task of prioritizing our features backlog, and those features go into our team queues in turn. From there, we have a weekly meeting with our team's product manager, designers, and engineers. We discuss what's coming down the pipeline and gauge engineering's interest. Some projects might be an extreme draw for one engineer, whereas others might just get assigned to whoever is free.

Project scope is a concern that is addressed during the research phase by the engineering anchor. That person will spend time understanding the feature's breadth and depth. During that time, they determine whether pieces can be parallelized as well. They might create individual features for pieces of the project to assign out to multiple engineers, or just set them as milestones for a single engineer. That work is then assigned to the person (or people) developing the feature.

Giving engineers creative freedom

Aha! engineers enjoy considerable autonomy when starting new projects, with the freedom to make key design decisions. This process typically begins with an engineer developing an initial structure, which they then present to the team for feedback. Given the complexity of our application, this early input is crucial, as even small changes can have far-reaching effects. We prioritize getting code into production quickly, using feature flags to allow product managers and designers to iterate alongside engineers. And weekly team demos keep everyone up to date on progress.

For larger features, we employ a "pull request buddy" system where a dedicated reviewer is assigned early on. This approach facilitates incremental reviews of small pull requests into a feature branch, preventing surprise large-scale changes and keeping the entire engineering team informed about ongoing work. This combination of individual creativity and collaborative refinement ensures we maintain both innovation and quality during our development process.

Circling back to TRM: Our framework for success

Again, we practice something called TRM while working on code. This framework for success isn't just aimed at customer interactions — it's also something we practice internally. Part of it involves being interrupt-driven. (Put simply, this means we view interruptions to our work as useful rather than distracting. We try to address these interruptions immediately, when everyone's focus on the issue is strongest.)

Even though many engineers think that might be a distraction, it becomes a strength at Aha! New hires often comment on how amazingly responsive other engineers are. It's very difficult to get stuck, as someone is always there to be a rubber duck, answer a question about part of the application, or help address a support ticket. The prevailing thought is that engineers are more productive when they have large blocks of work time. But productivity actually increases when teams can unblock things quickly.

How a feature comes to be

Once product management assigns a feature, it goes into the code process. We typically have a code champion look at the feature, comment on its scope, and give a rough estimate of time to completion (more on this concept later). From there, we have our engineering anchor take over — who might or might not be the code champion — and that person figures out the estimate and breaks it up into its individual requirements. Those requirements then go to a single engineer or multiple engineers. They present the ongoing work in team meetings to make sure it matches the definition. That's the time to find out from either other engineers or from product managers or designers whether the requirements need to change. And once everything is done, we start the process of getting the feature into production.

At this stage, we follow a few steps to make sure things go smoothly. We first have two pull request reviewers from the team look over the code and approve it, as well as a security team that reviews all code thoroughly. Any migrations will also have their own reviewer to make sure we don't run into unexpected database performance issues. Then, the individual will merge their own pull request into the main branch.

Everything is now ready to deploy. We do this several times a day, so code is always going out quickly. We have a rotating deployer who happens to be the lead on the support team that week. This way, they can deploy quick fixes in response to customer issues along with new work. Once the code is in production, it is on the engineer to watch for alerts and any support tickets coming in. The engineer is also responsible for answering questions about the running code if another engineer or customer runs into an issue.

Helping code champions showcase their expertise

That leads us to the concept of a "code champion," which we referenced earlier. Our code champions own pieces of the product and are experts in that realm. They present their knowledge to the team during our weekly code presentation meeting, and possibly to the entire company. And if their learnings are sufficiently interesting to the greater engineering community, they will go to a conference and present them.

Here are just a few talks led by teammates:

• A deep dive into sessions by Justin Weiss
• Building a collaborative text editor by Justin Weiss (this author was lucky enough to work on this project as well)
• Off to the races by Kyle d'Oliveira
• Testing legacy code when you dislike tests (and legacy code) by Maeve Revels

That's how we work at Aha! We have transparency into projects and, for the most part, choose what we work on. We have great autonomy in implementation and logistics. Help is always a Slack message away due to TRM. We also make sure to educate both our engineers internally and the engineering community externally.

Does this creative autonomy and responsiveness sound appealing? We're happy and hiring engineers — join us.