Speed (of execution)

A task is completed quickly when it is finished in a short amount of time. The solution will have multiple shortcuts. It might not be the most automated or scalable solution to the problem but solves 90% of the problem. Tasks that prioritize speed fall under the category of MVP (minimum viable product).

For example, an analytics report on product performance developed in MS excel which runs manually every time it is required, hard coding values of variables, use of v-lookup instead of index-match in MS excel, etc.

Scale

A problem is solved at(for) scale when the solution deployed is robust enough to handle all the scenarios and remains useful even when the complexity of the problem grows. Approaches that prioritize scale element get into the depth of the problem and solve it with perfection considering all the elements in mind.

For example, an automated analytics report on product usage which can be scaled to 100x users, or creating a data pipeline that seamlessly integrates with various data sources and is built with error detection,resolution and scalability in mind.

When it comes to problem solving, ‘execution speed’ and ‘solving for scale’ tend to have an inverse relationship with each other in the initial phase.

When to choose between ‘speed’ and ‘scale’?

The choice between scale and speed is often a trade-off. Finding a clear-cut answer on whether to prioritize speed or scale in problem-solving is not easy. As with most management concepts, the decision depends on the problem at hand and the specific requirements. Unfortunately, there is no silver bullet.

There is no one-size-fits-all solution. However, it’s possible to identify situations where one should prioritize speed over scale and vice versa by developing the skill of recognizing these situations.

Fictional background

Bob works as a product manager at Currency Software Inc (CSI) in New York. Currency Software Inc is a global FinTech company developing software solutions for the banking industry. All the big banks are customers of CSI.

Scenario 1

One fine day, Bob’s boss Ray(Director of product) asked Bob to analyze the transactions of the top 50 customers and share the key trends to view the product performance next week. Bob was extremely happy that Ray had asked him to do the analysis.

Bob saw this as a chance to show his analytical and product skills. He went to the engineering team to get the transaction level data of the top 50 customers across all the products they use (~took 3 days). He then went to the data science team to run various analyses to produce statistically significant results. The data science team gave him an ETA of 14 days.

In the meantime, Ray reached out to Bob requesting results. Bob mentioned that the analysis was pending on the data science team.

Ray was upset and took the project away from Bob. Bob followed all the proper steps but his boss was upset with him. What was Bob’s fault?

Scenario 2

A few months later, Ray asked Bob to work on a product-level regulatory report to be submitted to an external regulatory agency monthly. This report would include the transaction volume of the top 50 banks highlighting the specific deviations per government guidelines.

Bob knew from his previous experience that Ray would want the report quickly, so he asked the engineering team to get the transaction level data of the top 50 customers across all the products they use (~took 3 days). This time he did all the analysis in MS excel and presented it to Ray before sharing it with the external regulatory agency.

Ray was happy with the report and asked Bob to share it with the regulatory agency monthly. The first month was fine, but in the second month, there were some errors in the report, and Ray was not happy with Bob. What was Bob’s fault?

These are common scenarios that play out every day in organizations. Employees are not sure what they did wrong, managers are not sure if they gave the proper instructions, and in the end, the organization suffers. The irony is that both Bob (employee) and Ray (manager) wanted to do the right thing.

How should organizations solve the issue of speed vs scale? Are there any common patterns in these situations? Are there any frameworks that can be applied to solve these?

Intrinsic bias to solve for scale

Many people I have met tend to prioritize scalability in their solutions. Some common reasons I have heard from them:

1. Showcase of ability: Getting deep into the solution and solving it for scale is a good way to showcase individual’s ability. It also helps in career growth.
2. Salary justification: Expert resources get paid a lot. Doing work which highly technical and deep is a good way to justify the salary.
3. It was needed: Recognizing that a scalable approach was necessary for the problem at hand.
4. The problem would quickly grow: There was a need to implement a robust solution as it was anticipated that the problem would rapidly expand.
5. Avoiding criticism for taking shortcuts: Choosing shortcuts and focussing on hacks doesnt look good. It raises a lot of red flags and individuals do not like to be called out for those by their peers.
6. Solutions build with speed can make the organization happy in the short run but it introduces technical debt in the long run which is negative for the company.
7. No one got fired for building a scalable solution

I understand the reasoning behind prioritizing scalability, but I believe it’s important to find a balance between prioritizing speed and scalability.

Situations where speed(of execution) should be the preferred option

1. Exploratory phase: Solutions designed in the exploratory phase should give preference to speed of execution as we are not sure what will need to be built eventually.
2. One-time need: For one-time needs, prioritize speed as there is no need for future use.
3. MVP development phase: Quick and multiple iterations are required when the project is in Minimum Viable Product (MVP) development phase.
4. Product market fit yet to be achieved: Spending a lot of resources on a problem when the product market fit is not achieved is not the right approach. When product market fit is not yet achieved, avoid heavy investment in solutions
5. Time is critical: Speed of execution should be preferred when time is of the essence.
6. Not sure if the solution needs to be scaled
7. Resource constraint: Speed of execution takes the front seat when there is a resource constraint.

Situations where scale should be the preferred option

1. (PMF)Product market fit is achieved: Solutions can be deployed at a scale where the product market fit is already achieved.
2. The solution is well defined: Solutions can be built at scale when the solution is well defined and thoroughly tested.
3. Ample time: Although time is not the primary consideration, scalable solutions take longer to build.
4. Frequent usage: Solutions that need to be used frequently should be built for scale to avoid manual interventions and errors.
5. Scalabe systems should be built post the initial solution is approved for larger deployment.
6. Errors are not acceptable: Mission-critical systems where errors can not be tolerated needs to be thoroughly designed and implemented at scale.
7. Resource availability: Although not the main consideration, scalable systems can be built and deployed when there is no resource shortage.

How to use this information in daily life?

1. Evaluate the problem: It is very important to evaluate the problem and the situation. Evaluating the situation and the needs is the biggest element to selecting an approach.
2. Understand the situation on the below parameters:
   • Solution stage
   • Error tolerance
   • Time requirements
   • Frequency of use
   • Other parameters from the above section as needed.
3. Share your initial analysis of the situation with your manager/client.
4. Create the document on both the speed (of execution) and scale (solving for complexity) approaches. This is important because this will help your manager/client understand that you know how to solve for scale and with speed but are trying to balance/decide the right approach.
5. Share your solution approach explaining the factors for your decision.
6. Share the roadmap of your solution development along with time estimates. Please ensure to be flexible to change the approach if you get more information in the future while developing the solution.
7. Choose the approach and ensure you have buy-in from your manager/client.

Disclaimer: https://vinaysachdeva.com/disclaimer/. The opinions expressed in the blog post are my own and do not reflect the view(s) of my employer.