An Engineering Blog, by
BLOG

Kieran Gill

Rigor and Urgency

Balancing urgency without sacrificing quality.

The following is from our Candidate Evaluation Framework series.

Job descriptions are often full of well-meaning platitudes that don’t say much. Instead, we’re sharing the real hiring rubric our team uses. We hope this gives you a clearer, more honest view of what we value — and whether we’re the kind of team you’d like to join.

If this resonates with you, I encourage you to apply. We’re building the most accessible and highest quality healthcare clinic for children.

Rigor and urgency

Blueberry is a 24/7 clinic startup. We need to move fast and not break things. This requires us to have a disciplined balance of rigor and urgency.

We expect our engineers to find ways to consistently ship high-quality work at a low cost. Doing so requires business context and collaboration across departments.

Sequencing

Proper sequencing requires engineers to understand the value of what they’re making. What business metric does this feature move? How does this feature relate to the team’s OKRs?

If an engineer doesn’t understand the value, they’ll struggle to build the right thing. Often, the ‘right’ thing isn’t a direct translation of the Product Requirement Document1 to code. Great Product Managers agree with this. Often, they’d rather have a solution that fixes their problem next week than their specific solution next month.

This is surprising to junior developers. Juniors believe a PRD is exactly what the PM wants. What a PM really wants is to solve their problem.

So while sequencing is about when to build something, engineers also need to engage with what to build. That’s why engineers partner with the PM—not just to follow a plan, but to find the right solution to the problem.

Pushing back on a proposed solution can feel like conflict and conflict is uncomfortable. On the other hand, doing exactly what is in a PRD is just one pip install complex_dependency away. This “easy” solution tends to introduce accidental complexity.

Senior engineers tread carefully when solving non-trivial problems. They step back and ask themselves, “Does the PM need the sophistication of this solution? What problem are they solving? Oh, they just want to collect information from a user via a form? Then we don’t need Redux, useEffect, thirty layers of indirection, a specialized form library…”

Great solutions are testable, easy to maintain, and extendable. All else being equal, a simple solution trumps a complex one. The fewer moving pieces involved, the less surface area exists for aberrant behavior. The smaller the solution, the easier it is to test.

We pay ChatGPT for its ability to translate natural language into code. This is the work of a scribe. We expect more from our engineers. We expect creative problem solvers.

Quality

We cannot compromise on the quality of our core product. If an engineer doesn’t have confidence in the code they’ve written, they shouldn’t release it.

Senior engineers understand there is no “trade-off” between quality and velocity. Quality enables velocity.

“Quality” software is:

  • Stable.
  • Affordable to build and maintain.
  • Secure.
  • Perceived2 as performant.

What quality isn’t:

  • Quality is not formatting or a comfortable IDE setup. These things ease development but are second to testing and observability.
  • Quality is not applying paradigms that are familiar to the engineer. Engineers can become idealistic: “Functional programming is the only way to write reliable systems”. This passion comes from a good place but can be misappropriately applied.
  • Quality is not an aversion to tech debt. Tech debt should be thoughtfully used to buy us an advantage3.

I can’t describe what it takes to build quality software in this document. However, here are some things that can enable quality:

  • Testing. This includes automated and manual testing.
  • Observability. Roughly, this is tooling that enables us to ask questions about a running program.
  • Thoughtful planning and assessment of risk.
  • A bias toward simple solutions.
  • Pair-programming, peer reviews, or other collaborative development practices.
  • Static analysis.
  • The ability to deploy to production frequently.
  • A healthy fear of dependencies.

It’s possible to over-index on any one of these. Our investment in quality should be proportional to the risk level, complexity, and longevity of a feature.

What great looks like

  • They understand how their work impacted the business.
  • They can describe the trade-offs they made in scope for quality.
  • They exercise a healthy level of appropriately placed caution. An example of inappropriately placed caution is setting an organization-wide goal of 80% code coverage. Some projects necessitate more quality than others. An internal tool to help doctors understand their workload stats doesn’t need the same level of rigor as the tool they use to triage a case.
  • Great engineers know when to pause and plan. Planning helps to mitigate risk and ensures we’re building on a stable foundation. Some feature work is trivial and doesn’t require planning. Other work has long-term consequences: adding a vendor, dependency, new data model, language, etc.

Potential issues

  • People pleasers tend to avoid giving pushback. A lack of pushback can lead to projects with high complexity and exploding timelines. Look out for candidates who avoid conflict.
    A Product Manager’s perspective:

One experience that was negative was poor communication when scope increased or timelines were off track. In this specific instance there were engineers working weekends and nights to meet commitments but had not communicated that to me because they did not want to raise an alarm. This is not sustainable and is bad for the health of the team. Additionally, it impedes a PMs ability to set realistic expectations on when the team can deliver things with other stakeholders.

[I’ve had positive experiences] when we were under time pressure the engineers did a good job of enumerating low, medium, high level of effort options with the respective tradeoffs. This meant that when we had to do something in a hacky way we were always able to very explicit about what the negative impacts of that would be or if we did something in a way that took longer than expected we could articulate the benefits of going that route well.

– Sejal

  • Our understanding of the project changes over time. This means our initial guesses at sequencing get invalidated. We don’t expect omniscience from our engineers. Be skeptical of candidates who believe they can one-shot an implementation plan or do not find any benefits in planning.
  • Inability to describe what the business/team was responsible for and how they impacted their OKRs.
  • Prioritizing tech debt that had no demonstrable impact on the business (velocity, quality).

  1. PRD: The Product Requirement Document contains a list of features for the engineering team to implement. Our PRDs start with a problem statement and a series of proposed solutions to the problem. Typically, the PM and engineers work together to find the best solution, giving technical constraints. ↩

  2. A user won’t notice that we improved a page load from 150ms to 100ms. But they will notice 1250ms to 350ms. ↩

  3. For example, let’s say we need to show an increase in sales before the end of a quarter to hit important figures for fundraising. We find a vendor that can help us meet our goals. However, the vendor will deprecate this product next year. This is by definition “tech debt” – work that we must undo in the future. This is a good form of debt. It’s a conscious choice we make to buy us a short-term advantage. ↩

We’re hiring full-stack engineers.

If you’re interested in helping us build the most accessible and highest quality healthcare clinic for children, consider joining us. Go here to learn more about the role.

This article is from our Candidate Evaluation Framework series. To learn more about our ideal engineering candidate, go here.