How to Build Fast Part 3: Engineers

This article is part three in the How to Build Fast series. Read part one on team culture here and part two from a Product Manager’s perspective here.

This article provides guidance to help engineers “build fast”, specifically focusing on building an initial product to launch to users.

It’s all about trade-offs

Building fast requires having a laser-sharp focus on user impact. That means knowing where to invest time, and more importantly, where not to invest time. 

Engineers make a ton of decisions—the code architecture, the technologies to use, whether it’s time to refactor, and many more. In order to make the decisions that best enable user impact, engineers need to understand the context of the project and communicate their perspective back to the team. Engineers should proactively discuss implementation trade-offs with their team:

• Which elements produce impact and which are nice to have?
• What are the timelines for different implementation options?
• Where is the quality bar? Are we aiming to be pixel-perfect? Cover all edge cases? (Note this answer likely changes depending on the feature and the stage of the project.)

Be accountable for timelines

Specifically when building fast, extra days spent on tickets can add up to delaying a launch by weeks, which is a significant cost before getting feedback from the market.

Alert the team if the roadmap is unrealistic

Be proactive and honest so that the proper discussions can happen, rather than hoping for the best, working unsustainable hours, and/or dropping the quality.

Flag when a ticket is taking longer than expected

Discuss with the team if spending additional time on the ticket is worthwhile, and if so, what will be adjusted or cut accordingly.

Time-box investigations

There are a lot of unknowns when building a new product. In order to move forward, some decisions need to be made without knowing all the details. Take some time to investigate, document the limitations and unknowns, discuss the options with the team, and come to a decision.

Ensure a shared understanding of what a task covers and doesn’t

If a ticket is open-ended and vague, it invites scope creep. Clarify the minimum requirements and keep an eye on overall priorities—ask yourself: is spending more time on the current ticket more important than starting the next?

Quick to write, easy to change

When writing code, think about how to make it quick to write and easy to change. Start with the simplest implementation, and plan for adaptability by ensuring the code is readable, well-named, and has good separation of concerns. Write appropriate tests so the team can make changes with confidence that they’re not breaking something else. Also, take advantage of source control—revert changes if needed and ruthlessly remove unused code since it remains in the history.

Address privacy, security, compliance upfront and throughout the process

Concerns raised from a security audit before launch can significantly delay the launch. Worse, if issues are not caught before launch, they can risk user data, cause the company to lose public trust, and even be grounds for legal action. At the beginning of a project, flag areas of concern and discuss them with a knowledgeable advisor. Repeat this process throughout the project as new concerns arise, and ensure there is time in the schedule to resolve any issues.

Take advantage of trusted libraries

Using trusted libraries can save a lot of time and help the team move quickly. Of course, investing in a library that isn’t a good fit can be costly, so take some time to research a library to understand if it really addresses the team’s needs or if it’ll cause more headaches than it resolves. Generally, if the functionality is core to the product and will change frequently, it makes sense to build it from scratch. If the functionality is unlikely to change after it’s built, such as authentication and analytics, an established library is a good choice.

Decide error handling defaults early

When starting a project, it’s easy to skip over error handling and just focus on the happy path. However, it’s a hassle to retroactively find all the unhandled errors and address them. Instead, agree early as a team how to handle errors and create common code, like a default error dialog and logging, and common documentation, like the error codes for each endpoint.

Align the eng team on the code review process

Code reviews can take up a surprising amount of time for both reviewers and authors, so it’s important to make that time investment worthwhile. Discuss as a team the expectations around formatting the change description, how long a code review should take, when approval should be given or withheld, and what aspects to actually review (i.e. is the code simple? Easy to adapt?). Code design and architecture should be discussed as early as possible to avoid wasting time in the wrong direction. Complex features can even be worked on by a pair of engineers to share deeper context and speed up the review and delivery. Although it may seem quicker to approve a change without discussing concerns, well-designed code will lead to higher sustained velocity.

To repeat, developing software requires making trade-offs based on the project and its objectives. An engineer building fast may make very different decisions from one project to the next. While the actual decisions may vary, this article highlights common areas for engineers to consider and discuss with the team.

Keep an eye out for the final installment of the Build Fast series for a Designer’s perspective.