,
21 tweets,
3 min read
Read on Twitter
2.1/ Technical Strategy: “Evolutionary Means For Revolutionary Ends: The Art of Changing Large Systems” Bunch of my career was spent building/tech-leading the abstraction stack that led to GraphQL. Operated mostly on instinct but formed a philosophy around what worked.
2.2/ So this means having revolutionary ambitions, but having incremental process in order to get there. It might seem like a from-scratch rewrite in retrospect; but more Ship-of-Theseus-style transformation. It was done piece by piece on a live system.
2.3/ Incrementality interacts with reality in a number of ways. First of all there’s no way for *you* the engineer to know *exactly* what to build without building it and seeing what happens in the hands of your users and customers. Vision changes/evolves as process unfolds.
2.4/ You also need to bring your users along with you. Incorporate them into the process ideally. If you do incremental chunks, *they* might come up with the next big idea. That makes the infra more collectively owned. Easier to sell; far more sustainable.
2.5/ Programmers are frequently very ideological, and they know exactly where they think the system should go, and want to proceed there in the most direct and efficient way possible. Unwilling to tolerate detours and compromises.
2.6/ If while proceeded along this path, they come against a non-technical barrier -- e.g. they can’t persuade someone to use, an influential lead blocks them from a system, people interested by time not right given other priorities -- and this can be absolutely *infuriating*.
2.7/ This is when you hear about “politics.” Engineers frequently blame some nebulous notion of "politics" for lack of progress. Any group of people deciding on collective action through a process is politics. Important to separate good politics and bad politics.
2.8/ Bad politics: sacrificing the common/global good for their private or parochial interests. Good politics: well-meaning people deciding a shared goal and course of action that satisfy their interests *and* the company’s. Don’t confuse the two.
2.9/ A company without politics would be either totalitarian or complete anarchy. Good politics are healthy. You must learn to navigate it.
2.10/ Next: pick the right users/customers. Start with a single client. *Deeply* engage with them. Have a trust relationship. You’ll make mistakes and have to change things. That’s fine as long as expectations are set.
2.11/ Next maybe expand to three clients. Make sure they aren’t too identical: “You want to kind of capture a minimal N-clients that represent, say, like 80% of the use cases in the company.“ You want high confidence that you have built the right thing. Then deploy at scale.
2.12/ “I used to tell people to think of this as a political campaign, but with extremely informed constituents that have a lot of skin in the game.” They vote with their code.
2.13/ So it's not just about having the right technologies. It’s having the right messaging that feels authentic and aligned with that technology. And then you’ll have to repeat yourself over and over again. By GraphQL we called these stump speeches.
2.14/ “It's just absolutely critical to be able to have message discipline and understand what
everyone needs. And to understand that people, when you say something, hear different things.
That can often be a fraught process to navigate.”
everyone needs. And to understand that people, when you say something, hear different things.
That can often be a fraught process to navigate.”
2.15/ Important to understand the underlying dynamics of your company/org. At Facebook, Feed was the center of the universe. My saying “As feed goes, so goes the app.” It was the source of engagement and revenue, and every team had to integrate with it.
2.16/ At FB, if it’s in feed *and* it’s generalizable (there are feed-specific things, obviously) it will tend to spread through entire product. If there is a similar dynamic at your org, be aware of it and use it as leverage.
2.17/ Also understand who the real movers and shakers are. Who actually does stuff. The whole 10x engineer thing gets a lot of criticism, but I believe it. I believe the dynamic range is bigger than that, actually.
2.18/ When I was more junior and trying to do ambitious things, I made sure that the most relevant tech leads were very aware of what I was doing and that I was proactively getting feedback and responding quickly. No way I could have been successful without that.
2.19/ FB was pretty insular, which in a counterintuitive way was an advantage at times (but not always). It helped as we frequently approached problems with a beginner’s mentality, without being burdened by orthodoxy.
2.20/ I like to say: “Honor and respect best practices, but don’t be captive to them.”
Final tranche:
