Effective Engineer – Notes

For example, there's an assumption that what works well at Google would work well for other tech firms. And yet Google is in the rare position of having gained so much from its early golden goose that success in terms of producing viable, valuable products and services has been almost irrelevant among most of its workforce for most of its existence.

There's also an assumption that the staff at a big, famous organisation like Google are generally better than those elsewhere, and therefore that being successful in such an organisation is something to be emulated. Working at one of the Big Five seems like a default aspiration for some parts of the tech world, and there's definitely an element of hero worship for those who have made it. I can't help wondering whether that is simply because of the amount of money they can throw at new starters in the hope that they attract some of the best people among the catch.

What I see here is that if you're in an environment where being good at walking the walk isn't always necessary, talking a good talk becomes the path to recognition and success. While this is almost certainly true, anyone who's ever observed the phenomenon of middle management could have told you that, without reference to any specific industry. What it doesn't tell us is how much being able to walk the walk matters in most other environments where it is necessary for success.

When I look at some of the giant wins of the last major tech wave, often times the key factors in their success were external events that happened after the formation of the company. AirBnB benefitted massively from the housing bubble & financial crisis (3 years after formation), which created a large class of people who were desperate for income and whose primary residence was their primary income-producing asset. Uber had to try the idea multiple times before cell phone batteries became good enough to run navigation continuously in the car (2 years after formation), and took off because of the publicity of getting sued by San Francisco. WhatsApp took off after the addition of push notifications to iOS (~18 months after formation) made it feasible to use as a messenger rather than just a status update.

All of these companies certainly did things to influence their success, in particular having a product on the market at the time the market changed to take advantage of the product. But for most of them the product was actually wrong in the sense that it was a complete failure in the market until that market changed. Brian Chesky's fond of calling AirBnB "the worst startup idea that actually worked".

It's like the formula for success = preparedness + luck. This cribsheet does a good job at preparedness, but you have to acknowledge the role of luck if you want to actually capitalize on that preparedness, and being afraid to work on the wrong ideas will often shut you out of ideas that require some luck to work.

One of my favorite stories from Drew was that when he first started Dropbox, he created a 4-minute demo video showcasing the product that functioned as an MVP for the product. The video drove hundreds of thousands of people to their site and grew their beta mailing list from 5,000 to 75,000 people overnight.

On the outside looking in, skeptics might have thought that it was nothing new. But the MVP provided validation around what future customers actually thought.

My main takeaway from that story (and that I share in the book) has always been to validate your ideas early and often, so that you can get more signal on whether the assumptions you're using to shape your behavior are accurate.

More about the Dropbox story here: https://techcrunch.com/2011/10/19/dropbox-minimal-viable-pro...

At that point, you're not really talking about being an effective engineer, though. You're only talking about being an effective engineer in a large organisation working on a large project.

I know plenty of people in the freelancing and startup world who can build and maintain very significant systems single-handedly. Take someone with the skill and experience to do that, give them a free hand in choosing whatever tools and processes work for them to get a good job done, and remove the overheads of micromanaging this and co-ordinating that. It's not unusual for that person to outperform an entire team working for a competitor under more traditional constraints, or for a small number of such people who can keep the overheads down to outperform a more traditionally organised but mediocre team an order of magnitude larger. Of course these people also need good soft skills, but those are not why they are so productive.

Edit: [guesstimated]