Neat piece on inversion as tool for problem definition and solution.
20 years of product management experience in 25 minutes by Dave Wascha. As all good advice, easy to get, hard to consistently do.
Recently stumbled into this five part series drawing on analogies between improv theatre and consulting work. Read it in one go, will revisit for sure. Highlights: Well, consulting as improv, “Yes, and…” as strategy for collaboration, capacity building as ths consultants roe, (as opposed to problem solving) and the power of an outsiders perspective.
Work (and life) is as boring as you make it.
1. Always take the initiative.
2. There is nothing wrong with spending a night in jail if it means getting the shot you need.
3. Send out all your dogs and one might return with prey.
5. Learn to live with your mistakes.
9. Carry bolt cutters everywhere.
10. Thwart institutional cowardice.
14. Ignite the fire within and explore unknown territory.
15. Walk straight ahead, never detour.
16. Manoeuvre and mislead, but always deliver.
17. Don’t be fearful of rejection.
22. Guerrilla tactics are best.
23. Take revenge if need be.
24. Get used to the bear behind you.
Full list @ kottke.org.
It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.
This truly struck a cord with me. You can try being brilliant, being excellent, being the best, and I guess this is not the worst aspiration for a team. But, in the end, success in completing projects and shipping products is less about being exceptional but being non-exceptional. Not about getting one thing perfectly right, but about getting many things not wrong. Success sometimes is less about winning and more about not loosing.
Inspiring piece. The better and more advanced you get at testing your code for all eventualities and scenarios, the easier it is to loose out of sight that you will never produce perfect software, there are just too many modes of failure. Hence “Testing in Prod” is not an artifact from times long gone, it is a reality and your org needs to be able to do it.
A system’s resilience is not defined by its lack of errors; it’s defined by its ability to survive many, many, many errors.
Still wonderingvwhen your org will finally reap the benefits of agile? When you will get better value sooner, safer and happuer? This talk by Jon Smart holds a couple of really good pointers (Maybe skip the intro).
Leading a succesful team requires clarity - a leader communicating the framework for the teams performance, the vision, goals, rules and key parameters so they are easy to grasp and presence - a leader engaging, emphatizing with and enabling his or her team during said performance. David Tates Clear and Present Leadership provides a great backdrop to reflect, learn and grow in this regard.
I am a firm believer that a couple of key decisions at the very start of a project have a tremdendous impact on a teams ability to succeed. And while my personal checklist is a bit tighter and focused, Atomic Objects’ 15 Questioms to Ask at the Start of a Software Project provides a pretty neat guide.
“Managing humans” means getting two things right: The very big and the very small. Michael Lopp offers plenty of advice for both.
Often overlooked while staffing: Most people excel in very specific situations, some prefer to make, some to maintain. But projects/products require different skillsets througout their lifecycle.
“[At the start] it needs builders, pioneers who come up with clever ideas and execute upon them fast. They improvise … are opinionated [and] make their own decisions.”
“[Later] it needs a lot of incremental improvements, nitty-gritty […] details […] and a developer team which […] only needs some fine-tuning.”
Really good example from Oliver Eidel.
Classic presentation created by Sequoia Capital created in 2008 on How to survive a crisis. In essence: Get real or go home. I think I can get behind that, no matter the times.
For my next make vs buy decision, a simple structure risk, value, cost by Will Larson.
Super apps may enjoy a distinct advantage in markets with the following characteristics: cost-conscious consumers with low but growing purchasing power, high relative costs of internet data, relatively recent adoption of smartphones, and ‘mobile-first’ leapfrogging of the PC era.
Interesting analysis into how and why, after first appearing in Chinas and India with WeChat and Gojek, the Super App pattern - with one app as an ecosystem, instead of an ecosystem of apps like in “the West” - seems to repeat in other emerging markets across Asia and Africa.
How long since you have been in a bad meeting? A week? A day? An hour? Unfortunately it is really, really easy to botch a meeting, to make it the worst part of any given day for a whole group of people. Fortunately it is also not that hard to make it a positive and productive experience.
What a gem! The reasoning and mechanics behind building an authentication system (Kerberos) in this case.
Athena: Well I’ve figured out how to secure an open network environment so that unscrupulous folks like you cannot use network services in other people’s names.
Euripides: Is that so? Have a seat.
If ever I find an excuse to dabble more in big stashes of log files: awk in 20 minutes.
What better way to learn about systems then by attempting to break (into) them?
Best quote and Twitter thread on “artificial intelligence” so far:
Our field isn’t quite “artificial intelligence” – it’s “cognitive automation”: the encoding and operationalization of human-generated abstractions / behaviors / skills. The “intelligence” label is a category error
– François Chollet / @fchollet