# Getting Big Things Done

DevFeed: [Getting Big Things Done](<https://devfeed.tech/articles/getting-big-things-done-12501.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2020/10/19/big-changes.html>)

Author: Marc Brooker

Published: 2020-10-19T00:00:00Z

Content type: opinion

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Availability](<https://devfeed.tech/topics/availability.md>), [Chain-of-thought](<https://devfeed.tech/topics/chain-of-thought.md>)

Tags: [availability](<https://devfeed.tech/tags/availability.md>), [complexity](<https://devfeed.tech/tags/complexity.md>), [cost](<https://devfeed.tech/tags/cost.md>), [leadership](<https://devfeed.tech/tags/leadership.md>), [reasoning](<https://devfeed.tech/tags/reasoning.md>), [scope](<https://devfeed.tech/tags/scope.md>), [solutions](<https://devfeed.tech/tags/solutions.md>), [writing](<https://devfeed.tech/tags/writing.md>)

## AI overview

The article presents a method for evaluating major technical changes: clearly describe the problem and its success criteria, then write down why the proposed solution is appropriate. This process can expose flawed reasoning, reveal missing data, identify alternatives, and produce greater confidence or a simpler solution.

## Source excerpt

Getting Big Things Done In one particular context. A while back, a colleague wanted to make a major change in the design of a system, the sort of change that was going to take a year or more, and many tens of person-years of effort. They asked me how to justify the project. This post is part of the email reply I sent. The advice is in context of technical leadership work at a big company, but perhaps it may apply elsewhere. Is it the right solution? I like to pay attention to ways I can easily fool myself. One of those ways is an availability heuristic applied to big problems. I see a big problem that needs a big solution, and am strongly biased to believe that the first big solution that presents itself is the right one. It takes intentional effort to figure out whether the big solution is, indeed, a solution to the big problem. Bold action, after all, isn't a solution itself. Sometimes, in one of his more exuberant or desperate moods, Pa would go out in the veld and sprinkle brandy on the daisies to make them drunk so that they wouldn't feel the pain of shriveling up and dying. (André Brink) Because I am so easily fooled in this way, I like to write my reasoning down. Two pages of prose normally does it, building an argument as to why this is the right solution to the problem. Almost every time, this exposes flaws in my reasoning, opportunities to find more data, or other solutions to explore. Thinking in my head doesn't have this effect for me, but writing does. Or, rather, the exercise of writing and reading does. The first step is to write a succinct description of the problem, and what it means for the problem to be solved. Sometimes those are quantitative goals. Speeds and feeds. Sometimes, they are concrete goals. A product launch, or a document. Sometimes, it's something more qualitative and harder to explain. Thinking about the problem bears a great deal of fruit. Then, the solution. The usual questions apply here, including cost, viability, scope and comp