How FreshBooks democratizes technical design by applying lean UX principles

Your tech leads shouldn’t be the only ones tackling complex technical problems. With a process that is collaborative, transparent and iterative, any developer can be empowered to solve problems effectively.

The status quo: An exclusive and opaque process

The prevailing philosophy in software is that the most senior developers should be ones solving the most complex problems. This typically means that tech leaders are tasked with coming up with the designs that are then disseminated to other developers. Not too long ago, the technical design process at FreshBooks was no different.

As a tech lead, I was part of the Weekly Tech Lead Meeting which involved a lot of whiteboarding and passionate discussions about the design of our systems. This was a small group of 6–7 people. Technically, this meeting was open for anyone to attend, but in reality it remained quite exclusive. The space in the room was limited and the meeting invite only existed on the calendars of a select few. Occasionally other developers or product managers were invited to participate. But, apart from that, there was a general feeling that this meeting was exclusively for tech leads, and that tech leads held the exclusive rights to make key technical decisions.

It just doesn’t scale

As FreshBooks grew as a company, the technical design problems increased, both in quantity and complexity. The Weekly Tech Lead Meeting agenda started to get overloaded with topics to discuss. The room started to get overcrowded as we added more tech leads. The topics were tackled serially and so our overall bandwidth didn’t increase. Moreover, team members and stakeholders outside the meeting had little visibility into what kinds of issues were being discussed and how they were getting solved. As the tech leads rushed to push things through the pipeline, the quality started to suffer. For instance, we occasionally worked with wrong assumptions or produced solutions that lacked adequate alignment with the product goals. Very soon we realized that our process was impeding our ability to move fast and grow as a company.

Finding inspiration from UX Design

Around the same time, the UX Designers at FreshBooks transitioned to the Lean UX process. My colleague Avrum Laurie talks about it in this great post on How FreshBooks Got Its (Design) Mojo Back. Needless to say, there was a buzz in the office about how the designers transformed the way they worked to become more collaborative, scalable and highly effective.

While the specific problems that spurred their move to Lean UX weren’t the exact same ones we faced on the dev side, the fundamental issues of collaboration, scalability and quality were ones we shared in common.

If you’re not familiar with the Lean UX process (or at least the FreshBooks adaptation of it), it’s an iterative way to solve design problems that involves the following steps:

1. Charrette (Ideation): A brainstorming and sketching session involving a cross-discipline group (Designers, PM, Dev, QA, etc.).
2. Design Circle (Internal Validation): The sketches/prototypes are critiqued by a larger group within the company (mostly other Designers and PMs, ideally with Devs involved).
3. User Testing (External Validation): A refined prototype is presented to real customers for the purposes of testing some of our assumptions and getting feedback.
4. Design Circle (Review & Iterate): The insights gained from User Testing are brought back to the larger internal group, discussed and then used by a designer to further refine the design.
5. Repeat above as needed.

There were several outcomes our designers had achieved that I really wanted to emulate:

Trust and Autonomy: Any designer (junior or senior) can shepherd a design problem through the process

Speed and Distribution of Work: The steps outlined happen within a single one week sprint. Multiple problems can be tackled in parallel. Separate Design Circles can operate in parallel as well.

Cross Discipline Collaboration: The process is inclusive of stakeholders from various disciplines.

Feedback and Visibility: The Design Circle not only allows everyone to have visibility into the various problems being tackled, but also provides a forum for feedback and discussion.

A different approach to technical design

Inspired by the UX Design process we wondered if we could apply some of those principles to the create a process to address technical design problems. So we started experimenting with what we called The Technical Design Process.

The process is kicked off by a team needing to solve a non-trivial technical design problem. Any developer within the team can shepherd a problem through the process (it doesn’t have to be a tech lead).

1. Problem Definition

It starts with the developer working with the team (including product manager) to define the problem that needs to be solved and compile all relevant facts. It may seem obvious, but getting the problem definition right is critical as it informs a lot of assumptions used in the subsequent steps of the process (and yes, we’ve been burned by getting this wrong before).

Still, the problem definition doesn’t have to be overly complicated. A couple of sentences and some bullet points are often enough. It is important to not just explain what the problem is, but also why it needs to be solved.

Example Problem Definition:
We want to expose a public API to our product so that external developers can build integrations that provide value to our customers. How would we modify our platform architecture to build this?
- We have an existing "internal" API used by our frontend app.
- We currently have two integrations but we've done custom work to support it via a private API.

2. Technical Charrette

The developer then schedules a Technical Charrette. Similar to the Design Charrette, this is a session where a small cross-discipline group explores various approaches to solve the problem. We try to ensure that this group includes a mix of junior and senior contributors as well as individuals from different teams.

Sharing the Problem Definition in advance allows the participants to come to the meeting with ideas and background research.

Ideally, the group converges on one approach to solving the problem that can be further pursued. If not, another Charrette can be held to further explore all the approaches.

I typically use the following format to structure a Charrette:

1. Review problem definition
2. List ideas/approaches to explore on the whiteboard
3. Go through each idea and evaluate (list pros, cons and uncertainties)
4. Review and try to converge on one idea to pursue

Example Charrette Outcomes:
1. Document and expose current internal API
- Least amount of work
- Can't make breaking changes easily like we currently do
...
2. Build a brand new public API service
- Can design it properly from scratch
- Can be developed without possible disruption to our internal API
- Highest cost in terms of work involved
...
3. API Layer that proxies the current internal API.
- Can start by just proxying the relevant parts of the internal API, and incrementally add/modify endpoints without disrupting the internal API
- More work that just exposing the internal API, will have to maintain this separately
...
[#3 is the chosen approach to be pursued]

3. Tech Design Circle (Initial Validation)

The outcomes of the various Charrettes are discussed in the weekly Technical Design Circle consisting of developers and tech leads from across the company. It’s an open, recurring meeting for anyone interested in keeping up with the technical issues across the company. The purpose of this meeting is to provide visibility and gather feedback on the proposed solutions coming out of the Charrettes — not to solve the problems within the meeting itself.

The developer will come out of this meeting having further validated the approach with other developers in the company. If there are reasons to reevaluate the approach, the developer could go back and perform another Charrette using the feedback they received.

Unlike our old Weekly Tech Lead meeting, there is a conscious effort to make this meeting open. It is held in a large room in the center of the office, the agenda is editable by anyone and pop-ins are welcome.

Example Tech Circle Feedback:
- There is consensus on Option #3 as the chosen solution
- We should have a regression test suite to ensure we know if changes to the internal API have broken the external 'proxy' API
- Will need to co-ordinate with Ops to have rate limiting and monitoring on this 'proxy service' in production

4. Tech Design Circle (Follow-up)

While implementing the proposed solution, new issues or requirements may sometimes emerge. The developer can then decide to bring this to the Tech Design Circle for discussion, which might result in either re-evaluating the approach or continuing on the same path. In some cases, the developer may decide to start over at the Problem Definition step.

If the implementation goes smoothly and the problem is solved, the purpose of the follow-up is simple to share any insights that have been gained during the course of solving the problem.

Example Follow-up:
- Implementing authentication for the proxy API has been problematic because our internal API uses a different authentication mechanism 
- We're going to run a separate Charrette to figure out authentication and permission handling for the public API

The early results

We’ve been running this process to solve technical design problems at FreshBooks for just over 6 months now and the results have been very promising. Our throughput has increased, as evidenced by the number of architecture improvements we have shipped to production. It will take more time to objectively evaluate quality, but already, product managers are seeing better alignment between the technical implementation and product goals as a result of their early involvement in the process. It’s also very encouraging to see how much everyone has embraced this process. A mention of a Tech Charrette will invoke a flood of people wanting to participate — so much so, that we had to create a Trello board to manage the queue of eager participants.

As a technical leader, the process gives me the confidence that the decisions being made have had the appropriate level of evaluation and feedback applied to it. As a people leader, I love the fact that the process allows any developer to be involved in the architecture design process and build up those skills in a hands-on manner.

What’s really promising is being able to dispel the notion that only the senior most developers can solve the key technical design problems. In this process, the senior developers play a key role as advisors and mentors, but their job is to assist other developers in solving problems rather than solving the problems for them.

If you’re at a company facing similar growing pains, I definitely recommend trying out a process like this and I’d love to hear any questions or feedback you might have.

If you found this post valuable, I’d appreciate a ♡ below ;) and if you’d like to participate in this process, come work with me at FreshBooks.