š Hello!
Hope everyoneās doing well. Itās been a busy week at work this week, so this is coming out a little later than desired. I apologise for that.
If itās your first time reading, hereās a little refresher. The goal of this newsletter is to discuss techniques for building better software and being more effective in high growth companies. I mix in longer form content ā think a short blog post that you could read in 5 minutes ā with some of my favourite links.
Over the last few weeks, Iāve covered:
Iām matching donations to Black Lives Matter causes up to a limit of Ā£500. Please send me your receipts and Iāll match them straight away.
On with the show,
Stephen
How to scope work š¬
As a software engineer, youāll often be asked the following question: how hard would it be to do X?
Get used to it ā itās a very reasonable question! Weāre here to talk about scoping: a process of answering that question.
What is scoping?
Scoping work is the process of going from the vague to the precise: from the idea of a feature, to a plan for how you might build it. Itās a broadly applicable skill ā it isnāt unique to software engineering.
When you scope, the goal is to figure out and define what problem youāre trying to solve, and propose an idea for how youāll solve it. The problems youāre trying to solve might be:
Adding a new button to your homepage
Building a new authentication system
Rolling out an engineering progression framework
This is not estimation. Estimation is giving an idea of how long something will take to build. You need a clear scope to be able to give that estimate.
The output of any scoping work I do is always a proposal. Want to know how to write good proposals? Refer back to my previous post on them!
Why is it useful?
Scoping helps you:
Align teams on the problem to be solved and the extent to which youāll solve it in this version
Gain some level of confidence about what you have to do, and how long it will take
De-risk the process of building it
Scoping is half of the job of a software engineer. Your job is about translating things that people would like to exist, and figuring out how you make them real. You might think thatās what a product manager is for. Wrong ā itās your job.
How to scope
Decide what resolution you want to scope at
You can scope with different levels of detail in your scope. If weāre being really lazy, we can create two categories: vague, and precise. Itās helpful to start vague, get early feedback, and then go precise.
Vague, or āmagic box scopingā

In this model of scoping, you have a bunch of boxes that you draw out that will perform some behaviour. You donāt know exactly how it will work yet, but you have a good idea that this is the right āshapeā of the system. You define the interface, not the implementation.
This technique is really useful when it might not be totally clear what the problem is youāre solving, or many team members may have differing opinions. Itās a helpful technique to make sure you get on the same page early on. As Keynes said, āit is better to be roughly right, than precisely wrongā.
Precise scoping
This mode of scoping defines both interface, and implementation. Youāll be specifying data structures, RPC call stacks, flow diagrams of requests, and so on.

The goal of this type of scope is that you should simply be able to sit down at a keyboard and type. Thereās no unanswered questions.
ā ļø A word of caution. Do a āmagic boxā scope, before you get here. Otherwise, youāre sinking effort into something that you might have to throw out later. Define the interface, agree upon it, then define the implementation.
Break the problem up into smaller chunks
Larger problems are hard to solve. Decompose the problem into smaller ones. Letās take an example thatās dear to my heart: building a system for fraud detection. When viewed as on its own, itās really hard to figure out how youād scope out an approach to it. But think about it as a set of smaller problems:
Figuring out what data might be useful to have
Collecting that data from your users, and storing it
Building a system that can process that data and make estimations about likelihood of fraud
A dashboard to present those results to users
Itās much easier to figure out approaches to these sub-problems than it is to solve the whole. Itās somewhat like Elephant Carpaccio ā sorry vegetarians.
Focus on high risk components
As mentioned earlier, scoping helps de-risk the process of building. This risk is not evenly spread amongst sub-components of your system. You need to focus more attention on the central components of your system which you understand poorly. Components that are high risk, and poorly scoped can often lead to misunderstanding and pain down the road.
Letās go back to our food delivery service above. The highest risk box there is Stripe. Why? Well, weāre using an API that weāve never used before. It involves sensitive data. We canāt really launch our service without charging for it either! Itād be well worth spending more time figuring out precisely what information you need to collect to charge a card, and how the interaction with your billing service will work. The user service is more likely to be well understood: an email address, name, and so on.
Figure out what parts of your system you can leave at low resolution, and which parts need high resolution scoping, and spend time accordingly.
Know the edge of your technical knowledge
This is one of my favourite comics. The irony is that this is totally a solved problem, given how good computer vision is getting.

Know the edge of your technical knowledge. Highlight where you donāt understand something particularly well, and where you canāt figure out the details.
Write a proposal
What Iāve described above is the thinking process behind any good proposal.
Define the problem to be solved, and figure how youāll solve it. Then, take what youāve figured out, write it down, and share it.
Things to watch out for š
From experience, there are a few things that should set off your spidey senses of trying to get to a clear scope.
External third parties
Third parties can be amazing, or awful. One thing remains constant: you know less about the third partiesā business and way of working than you know about yours.
Assume that they are unlikely to operate at the same timescales that you do, and are unlikely to have incentives aligned such that they change to meet them.
De-risk early on by talking to them, and highlighting timeframes that youāre operating under. Try and to ensure that you arenāt in a situation where they can block parts of your process.
Scoping massive projects upfront
When a project is massive ā e.g. a multi-year engineering initiative ā scoping it becomes less effective. Uncertainties dominate. Youāre not going to do whatever was in your plan. In these situations, do a rough scope, and sequence work by time. As you progress along timelines, scope future work in more detail.
Best of the internet š
Every week, I collate some of my favourite links to share. Found something cool, or built something great? Send it to me by replying to this email and I might include it in the next edition. š§
Why software projects take longer than you think: a statistical model - Erik Bernhardsson
This is very topical after what weāve discussed today. Most projects take less time than youād estimate but some things are far, far longer. Tasks with the most uncertainty dominate. Use your scoping skills to reduce this uncertainty where possible.
Growing the Internet Economy - John Collison
The Collison brothers at Stripe are exceptionally clear and structured thinkers. I really loved this podcast with John: a whistle-stop tour through payments, the internet economy, and product.
Performance reviews as a story - Sean J. Taylor
This was a remarkably useful thread about helping your manager write a great performance review for you. Itāll take you a minute to read, but might increase your earnings substantially over the long run.
Thatās all from this weekās High Growth Engineering. If you enjoyed it, Iād really appreciate it if you could do one of the following:
Share it with a friend that would find it useful.
Follow me on Twitter: @sjwhitworth
Subscribe: just hit the button below.
All the best,
Stephen
Create your profile
Only paid subscribers can comment on this post
Check your email
For your security, we need to re-authenticate you.
Click the link we sent to , or click here to sign in.