DevTools > Effective Execution

The tools we build are an end to a means: improving the efficiency of people working on the actual problem – and you should always have a strong bias towards immediate improvement.

Building value from the very first engagement helps give you a better sense of the problem space, builds trust with your customers – and motivates them to make time to engage with you and help you ramp up in a new domain.

You also immediately start changing the curve for solving problems, which has positive knock-on effects even if everything else fails.

Instead of building an entirely new tool that people then have to

1. find out about
2. be convinced of adopting
3. and then work through shortcomings or bugs or missing features

– make it easier on yourself and your customers.

Improve the tool they use the most: particularly in case of a proliferation problem, choose the most valuable tool and start building on top of it.

While working in a brownfield isn't as pleasant or fast as a greenfield project, it has a lot of advantages:

• Customers are going to start using your work immediately and giving feedback (often loudly) – and you'll immediately find out if it's valuable or not.
• Working directly on the existing solution means that you'll account for strange edge cases upfront instead of reaching 90% completion and then realizing you still have another 90% to go.
• Your customers are already in place because you decided to go meet them where they are: you don't need to do significant evangelization or education.

One argument I hear often is that brownfield development can constrain the solution and miss out on paradigm-changing efforts. I almost always argue that we can do both: building a path that lets us slowly stack incremental improvements till we have something an order of magnitude better, with a gradual ramp on for the customers.

Of course, this will be slower than doing a greenfield project: but you're much more likely to succeed, and you've been speeding up other engineers throughout this process – significantly increasing the payoff.

Our customers are developers: they're familiar with programming and the stuff that powers these tools in the first place. Freeing them to customize the tools to their particular problems will enable much more satisfaction and productivity.

Allowing end-users to customize tools for themselves helps break free of several painful constraints and design decisions that otherwise come into play. There are often features that happen to be extremely valuable for a tiny subset of people and obscure and utterly unusable for everyone else. Allowing that set of people to build and run that feature just for themselves completely sidesteps that problem. Keep the core tool composable to make it easy for customers to build – and maintain – workflows they want.

Keep the core of your tool simple: which will help with reliability, maintenance, and speed.

Make sure that time spent by toolsmiths acts as a true force multiplier for the rest of your engineers: directly trading off a toolsmiths time 1:1 for an engineer's time is most often a wasted opportunity.

Getting the most value from your time is pretty much the whole point of this series, but I wanted to remind you to make sure you keep this idea in the back of your head while making any decisions.

Add your comments to this Twitter thread, or drop me an email.

6/ https://t.co/y5JCxWvhX2

Recommendations for setting up execution: iterate where your customers already are, iterate quickly, and let customers make the tools into what they exactly need.

— Kunal Bhalla (@kunalbhalla) June 24, 2021