The death of Agile comes with the face of Architecture

My point today is that, if we wish to count lines of code, we should not regard them as
"lines produced" but as "lines spent"
EWD 1036

Inspired by the avalanche of coding agent endorsements from legitimate coding experts like Liz, Steve, Salvatore, Mitchell, Addy and obviously Simon and Andrej - but also by the excellent o16g outcome engineering manifesto (via Charity), I felt it may be interesting to explain my view on two sides: o16g coming from integration engineering, and architecting for cost. I am not trying to come up with general ideas here - there is excellent work on making sense of agents, like Birgitta's Context Engineering for Coding Agents, already.

Beginning with the second one, cost - I always knew death of (capital-A) Agile would wear a familiar face, but not the one of (capital-A) Architecture. o16g says "The Backlog is Dead" but also the sudden swing back to Spec engineering, instead of Architecture and Management we just call it Plan Mode, is somewhat ironic, and maybe a sign of the wider socio-political times where compliance and loyalty are seen somehow equal with ethics and safety. Anyways, o16g goes on: "Cost not time". I am not nostalgic about coding, but what surprised me with the epiphany posts of coding experts above was, obviously they have no concern whatsoever for money, especially when calling out that only newest frontier models work. Cost is seen as just another metric, requiring multiple Claude accounts is the humble brag of the hour. It's hard to burn fewer than $100 USD credits a day, which makes a Max 20x plan for $200 USD per month seem a good investment. Certainly for corporations, given that's roughly the salary of an offshore software engineer per day, but for individuals? On the surface it is, and I admit vibe coding helps me a lot every day, but at the same time I feel this lavishness sounds too much like an anthropomorphized man month / lines of code metric, showing off how much can be produced rather than asking: why?

(the next paragraph is a bit ranty, you might want to skip it)

One of my side projects, a medium complex data pipeline that had time pressure, used ~700M tokens against ~700K tokens of code, a factor of 1000, in a week. Yes it's as much as other hobbies, like an expensive gym membership or gambling, but it's still a product for the privileged, where power and influence stand above money, just as addictive and even less sustainable. If you are not already privileged, like I am, you have to use cheaper tools such as OpenCode with Ollama, but that won't boost your productivity just as much and probably just intensifies your work. Never has leverage of privilege and virtue been clearer in our industry. Instead of Jevons Paradox we should talk about frontier models and disposable software in the same way as other hobbies, as Veblen goods and these endorsements as tantalizing, especially when they go along with status and virtue signalling in society: "I can spend on AI, I can build resonance far away from the environmental damage by Ralphing resources, I can communicate via AI,  because through my well paid job I am virtuous - my reach, my karma, is justified to be boosted".

Something big is happening for people who believe they can grace humanity with just another app, but as long as Anthropic's AI powered customer service still can't figure out my overbilling issue two weeks in and their 3 distinct billing systems are mutually incompatible it's clear they can't manage human bottlenecks either. Exploitation has reached its peak and skilllessness returns to its feudal origins where we have to be grateful to only contribute to secret police and not directly to carte blanche military use. The junior developer doesn't get a revenge because they are poor.

Sorry for the rant. So what are my patterns for saving cost and trying to stay sustainable?

I agree using the latest thinking models is unfortunately mandatory for many tasks, anything that's non-linear. I had Claude write undeletable files to my filesystem when stumbling to set a parameter with "--", kernel panic restart my Mac (without remembering, obviously), introduce a performance regression because it wrote the experiment result to file A but read from file B, destroy layouts by not understanding what a grid is, fork a library instead of suggesting to update it to the latest version, come up with endless loops while at the same time initializing a large transformer model inside the loop - and so on and so forth. And I don't even talk about the general issues with folders, modules, the bias to write more code and the tendency to create a garbage dump in root with a strong tendency to ignore rules especially due to context drift in long sessions (yes I still feel a codebase needs to be human readable eventually in addition to observability - ops bias). This class of weird linearity bias errors, out of all reasoning failures, can be significantly reduced by using frontier models with large context to build a harness or "doing the work twice".

So here is my current workflow with ~3 instances of Claude, plus agents, running in parallel, trying to go by universal principles (but skipping the obvious like one session per task, planning, review plan like a staff engineer etc):

1. I use flagship frontier models like Opus for planning, and that means I always let them write documents, rarely execute. Planning here means anything ordered, i.e. that targets a larger codebase, span of time, hierarchy or spatial understanding beyond linear steps. In other words anything with a larger than single task scope and can also mean documentation, visual design or refactoring like splitting a module. Experiments are multi-step so also planning - in all these cases I ask for a clear, stored writeup on main with specific file references and then restart context to avoid compaction or rate limiting in the middle of reasoning. It also helps human reasoning to not do something, or to simplify. I can decide if a refactoring is worth it, or if something really needs to be platform, framework or service and fan these out as experiments on separate branches. Refactoring like renaming a variable or method consumes a huge amount of tokens, are slow and unreliable - I often use IDE functions for that instead to be sure (until we have better tools).
2. Cost effective models like Haiku I use for anything highly localized, for example agentic background tasks (especially when based on skills, e.g. writing a "evaluate experiment using local Python environment" skill), running batches, tests or experiments, configuration changes or moving something trivial without type dependencies (because Claude just cannot stop using the root folder, regardless of how many rules one defines). Usually I use Opus to write a plan and split it in stages for different types of models - the ones for Haiku are usually also fine to be used with offline models, which is useful from a data governance perspective. I execute them on a different branch and occasionally ask Opus to judge the branch implementation. This plan I usually ask to persist in a gitignored folder with a running version number that experiments can refer to.
3. "best of both worlds" models like Sonnet I use the least, usually it's for smaller standalone tools like a quick data conversion or crawler, but I rarely see the benefit over cost effective models. I do start with Sonnet on a new task though because I feel the extra context helps with cost saving rules such as "always activate the Python3.14 environment in /venv first and only use existing dependencies" which saves tokens by reducing double work. Usually for these tasks I run them on a separate branch as the models still ignore rules. Sometimes I use them to summarize a larger task for a smaller model or make slightly bigger changes, like writing a changelog or skills after a session. But even writing a claude.md memory often missed important detail and is best done with flagship frontier models given the outsized downstream impact. Maybe adaptive thinking will solve that?
4. If possible I use offline models, preferably Qwen3 via Ollama when I know I will be offline, asleep, intermittent connected; when it's a quick question like a bash script that I want to be mindful of resources; or when I want to make sure no data is sent to a Cloud API, for example to investigate local data or test data, or even when looking at someone else's codebase. I tend to keep data and project specific documentation away as I don't trust local security settings and external libraries or code. Here and there I spin up a VM or Container with a snapshot to dangerously skip permissions aka yolo.
5. For inspiration I often use other models like Gemini Deep Research (in NotebookLM) or even ChatGPT* especially when it feels like a conversation is more helpful to arrive at a solution, e.g. in researching for a certain algorithm with tradeoffs - occasionally I use a "best of both worlds" model to write a summary (e.g. architecture.md) for a certain component to send to another tool in a conversation format making sure any identifying or sensitive data is removed.

Cost obviously connects to integration engineering and field engineering - we never had the luxury of strategic moonshot product budgets, like we also never had the luxury of nostalgia or romanticism for code - we kill with fire. As Benedict Evans said "there’s a huge gap between what looks cool in demos and all of the work and thought in the interaction models and the workflows in the actual product". Even though AI gives us as per Chad Fowler "industrial generation immediately. It does not automatically give us industrial regeneration", i.e. yield. Code does not create value in itself. Yes, you can reduce some engineering cost, but technology companies praise themselves on creating products with value, not on racing cost to the bottom. Which brings us back to the point of asking "why" despite code being cheap now. Integration engineering is about a sense of product, about stability, user trust. Anthropic's 3 broken and incompatible billing systems can't use an excuse of "move fast and break things" anymore - it's a sign  either of a product decision or that they have no control over their own technology. In both cases they outsource the risk to their users (not their investors who care about MRR) via "all credits just expire" rules. That's consumer product thinking, not a hack you can play on corporate users over the long term (hype aside), you can't just outsource the risk to the pointy end of the integration and then refuse support, stability and quality.

The death of Agile comes with the face of Architecture because it's more important than ever to consider Technical Debt and Cognitive Debt, in the same way that Task Isolation is positioned against Context Drift. Design decisions become brutally visible, and products expose their inner working, a material witness to business priorities, where cost of code is no excuse anymore. Charity is spot on that observability (o11y) is now the primary tooling to establish, monitor, experience, learn from and feed feedback loops. It never was Architecture of code, it always was Architecture of the product. Your user experience, and in probabilistic software user experience is your reliability - the future of engineering was always SRE.

*) uhm no, nevermind

Hope is not a strategy, it's a mission

I came across an interview* covering Palantir's Forward Deployed Engineer (FDE) model, which pointed to a trend I've definitely observed: Post-ZIRP many startups, specifically AI startups, didn't only scale with revenue very quickly, treating their business model with as much priority as their engineering work, but alongside revenue also treating their users as first citizen, and working much closer with them, through outbound-focused product management, deployment engineers, field engineers, solution engineers and similar roles. Actually one of the reasons I didn't continue my series on Professional Services a few years ago (yet) was precisely this shift.

At one point in the interview the interviewee says "that's services ... historically something you wanted to minimize". Amongst a lot of questionable points, this one is valid. Until Cloud became really big in the 2010s, Professional Services in general, and Consulting specifically, was seen either as something dirty (a cost center) or, worse, just another revenue driver (a profit center) - which often conflicted with the product due to its high margin contribution. Services heavy organizations often took hefty maintenance fees (around 20%) and on top of that required expensive business consulting services, often making it look like the product was not accidentally, but very much intentionally, complex - regardless whether it was essential or not. I think it changed with Cloud because it was the simplicity of AWS services, both in terms of integration and pricing model, that removed these entry barriers. Consequently, they turned Professional Services into a strategic cost center, an enabling function where margin was less important than adoption, and in turn reducing friction. That didn't mean it would be free (I strongly believe it should never be, but that's another post), but it was margin neutral. In such setups, SaaS businesses would often track the need for services as "sub-linear", growing slower than revenue, reflecting essential complexity.

While Palantir made the FDE model famous, around 2010 when it was called Delta (seriously, what's up with those military references, especially when you don't want to be the one Deltas land on), SRE had long been a thing inside Google with a similar user-first but less heroical mindset, and alongside it CRE not much later, just when I joined. Google at the time was not known to be a specifically user first company in the sense of being user specific, it had to be focused on extreme scale. Ease of use was important, but in the sense of universal accessibility. So it was an interesting cultural change to work much deeper with users. There wasn't even a place or process for SCEs to write code on the boundary between Google3 and user's systems, and when I was working in the BigQuery (Dremel) codebase, introducing use-case-, or even user-specific flags was heresy. AWS by that point in time had long written user-specific code, easier to do thanks to their multi-tenant architecture, often running custom tuned versions of a product for large users to build new features before rolling them out. In other words, in my mental model (I have no insight into either Palantir nor AWS), FDE was just one of the possible reactions to the "services over product" and outsourcing (BPO) trend of the late 1990ies / early 2000s, and fits into the countermovement started by SRE and culminating with AWS CAF around 2014 or so.

FDE was unique in one element, though - travel on-site. The Cloud providers wanted to prove, maybe too much, that local infrastructure is obsolete. Throwing out the baby with the bathwater, they missing that localization in itself had value, more often of than not being late to local markets and enterprises - a wedge that Azure was able to leverage, especially in Europe and the middle east. I see the current FDE hype more in line with Return to Office (RTO) mandates, where Microsoft is also setting a sad precedent. In a rare rejection of scientific findings about increased productivity, RTO is purely there to set the vibe "we don't trust you", burying competition and discontent in loyalty. Through this lens, FDE embodies the current Post-Twitter "working hardcore" style, with famously AI startups pushing for 007 work hours and embracing weird ideas about masculinity as some kind of "reaction" to DEI programs - when these programs, alongside remote work, actually proved successful. Tech is clearly irrationally reacting to changed politics and picking the prevailing loyalty over essence vibe.

I am glad for the DEI programs I participated in, and I don't miss high school gyms. I prefer scientific, rational, collaborative, unbiased and ultimately optimistic work. What made FDE unique was listening to their users wherever they are. Being users first on their terms. But the important part was listening - that's what FDE, SRE and CAF have in common. And while each had an edge in one or another area, for example Azure is clearly lacking the resilience of SRE culture, it's what they have in common that proves the success. They all reacted to a mindset that forgot the product, long term commitment, over short time margins, they forgot the strategy in exchange for tactical. Applying either of these models is not about more exclusion, taking shortcuts, it's about more inclusion, doing the hard work, staying with the trouble. That's a loyalty I can get behind, collaboration. Not sitting in front of your boss waiting for instructions. So please, don't turn into a military contractor, swinging war terms around and pretending to be a drill instructor. You're making the same mistake, forgetting a better product over short-term margins. Try to build products as if lives depend on it, not as if your goal is to destroy life. In SRE we used to say, "Hope is not a strategy". That's true - Hope is a mission.

*) which I am not linking because it was a tasteless piece of military propaganda normalizing how PayPal, Palantir, OpenAI and the US Army fit together - I really wonder if in the current spirit of renaming they soon call themselves War Combinator

Modern Professional Services - Part 1 - Types of Consulting Organizations

I am giving a talk at SRECon '22 APAC "Deploying Humans at the Edge of SRE". It's meant as inspirational, so I'm starting a 3-part series on Professional Services. The bigger context is the discourse on interesting career paths into tech, which I've been working on joining Google, particularly with my Awsome Tech Roles compilation (please contribute!).

A series on Professional Services

In this 3-part series I'd like to introduce "Professional Service" organizations in tech product companies. In times of standard convergence and consolidation, recession and and "cash is king", it's easy to observe product companies pivoting to offer services, usually paid, as a way to ensure success of implementation and provide additional value-add and thought leadership if products differences are minimal. But implementations can vary widely, and it's hard to compare how they work.

I'm excluding pure managed services, outsourcing and consulting firms and the traditional industry (in-house consulting, ops) here, same as in my Tech Job Titles List. Product implementation may be outsourced in some tech firms and therefore be relevant, but specifically in tech product firms is either internal effort based ("what can I get done with the SWE cycles I have") or covered by a "partner" organization who scopes projects in a similar way to what I am about to explain.

This series will be split in 3 parts:

• Part 1 on Types of Consulting Organizations
• Part 2 on Estimation, and Fordian vs Bayesian Timebooking
• Part 3 on Impact Metrics, including Cost

To be clear, this is neither driven by Stripe or Google, not represents Stripe's or Google approach. It is purely based on my observations when talking to my peers - and given I am not in Silicon Valley likely highly biased on not canonical at all.

Types of Consulting / Professional Services Organizations within Product Companies

When I say Professional Services I generally mean paid post-sales (post go-live / post-commit) services provided from the same company that built a product to the buyer or user of the product. That services goes beyond standard case-based support and troubleshooting or continuous customer success plans, and is defined by a project scope and business impact, not a product pipeline or effort SLA, and not billed outsourcing-style "time and materials" (like, say, an adoption-focused Customer Success Manager or Resident Architect or extended workbench).

Here is how I see the 4 extreme types of professional services organizations in tech product firms - this may sound negative, but the goal here is to show extreme cases, ymmv:

1. Separate organization or profit center with completely separate P&L contribution, often even a different brand or subsidiary with different contracts and benefits. Usually these are product firms with very strong partner ecosystem, making sure their consulting arm stays "independent", often due to a strong license lock-in ("stickiness") and fixed-support-fee business that does not depend on a SasS / usage pricing model. In other words customer's success is not actually relevant post-sale, customers may even be forced to pay a maintenance fee which puts the professional services organization close to "customer operations". As separate organization, they may often do real implementation and delivery work. Therefore, individuals are often incentivized in their performance process purely based on P&L, e.g. chargeability metrics or thought leadership generating leads and opportunities. Due to this it is not uncommon this is actually a different entity with different contracts and employment plans.
   
   IBM Global Services used to be the classic example, SAP Advisory Services and, until recently, Microsoft are others, but there is a general trend to blur the lines with the shift to SaaS and customer success metrics. Not even outsources prefer this model anymore as capacity planning is hard (more on this in the next post on estimation).
   
   
2. Separate team within a larger organization, usually either the Sales / Go-to-Market or Support / Customer Success organization, aligned to their goals but different methods. The lucky invariant is a prototyping, solution engineering or deployment engineering team, embedded in the rollout motion but connected to initial support. The less lucky invariant is an intermediate stage to (1), as the KPIs / metrics / OKRs need to be hacked to fit a fundamentally different culture e.g. via profit or revenue share in a value-selling approach. Therefore, individuals are often defined by roles rather than reporting lines, and incentivized in their performance process on metrics they have little control over e.g. product upsell or utilization. This may lead to frequent re-organization, strategy and leadership changes and associated employee retention issues.
   
   Usually these are SaaS usage pricing companies that at the same time have lock-in potential and therefore see professional services as a retention channel. The classic examples used to be VMware, Salesforce and ServiceNow. Cloud providers may fall back into this as default or crisis mode (as they often don't have natural "stickiness" e.g. license leverage, at best commit contracts), and while aspiring to profit centers in reality often turn it into a cost center by discounting or waiving cost for services e.g. for migration.
   
   
3. Horizontal enabling team, role, community of practice or speciality organizations with fluidity and some fuzzy lines to presales / solution engineering, developer relations, evangelism or support. Usually these are SaaS / usage pricing companies with real long-term customer success vision beyond quarterly goals. Often for more experienced / senior individual contributors like principal architects; individual contributors who are ok with swarm-style loosely defined reporting lines and define their own specialization e.g. holocracy. In the extreme case a catchall for all work not otherwise clearly defined even to the extent of building unofficial tools and integrations. Therefore, individuals are often incentivized in their performance process on metrics that represent this long-term vision like customer or partner happiness, public engagement, IP / asset generation or product enablement (e.g. sublinear support growth). In this model professional services may be close to developer relations or field engineering.
   
   Often de-facto operated "cost neutral" as cost or investment center and therefore smaller than in comparable firms. Amazon with its very independent team, customer obsession and embedded roles is the classic example. And every provider claiming to do "Digital Transformation" pretends to be here (e.g. Microsoft is moving from 1 to 3).
   
   
4. A rare hybrid between type 2 and 3 are professional services organizations aligned to the product feature engineering org, for instance combined with Product Ops for customer empathy (also here) strategic customer advisory and lighthouse customer launch support, or with DevRel to cover OSS tools and integrations. In the best cases these are actually rotation-based, starting with a residency program. Often they are smaller organizations where "everything customer facing" is grouped e.g. into Field or Deployment engineering.
   
   Often these are data companies who build very specific use cases and can monetize their reuse, e.g. Palantir, Databricks and Looker, also Google used to be like this. A recent thread shows Color seems to do Solution Engineering this way (the right way). Seen as an investment or profit center but via product usage or adoption, not direct payment for services. Unsurprisingly all of these sound familiar to Team Topologies - this type would be the Platform Team, the closest to how SRE works, just on the other end of spectrum as maximum customer empathy team (often Professional Services sees itself as "spearhead" or the product).
   

A fifth type would be an organization that does not have in-house professional services. The classic example here are Atlassian and Apple, arguably even Oracle, who always put self-services and partner network first, with their field engineers primarily being a glue between partners and internal engineering teams. In Apple's case there is also simply the product decision to not be customizable, so naturally field engineering is more like DevRel, evangelizing the ideas which are famously executed without considering the customer. Microsoft and SAP over the aeons oscillated between this model and type 1 above.

In part 2, I will talk about estimation, and how work is prioritized in Professional Services teams across those 4 models.

Letter to my future self 2022 edition

Reading my earlier “letter to my future self” from 2016 is interesting, because it still holds true, irrespective of how the pandemic changed the workplace: I wanted to work on delightful products with end-user impact, intelligent and intuitive products with a strong and clear vision. First class in technology, with information and technology as a “narrative”, meaning culture, and with a strong focus on operational excellence. Back then the SRE book had just not been released so it was hard to explain to classic “architects” what my role would be, yet I was keen to learn how to run things at scale. I wanted to be part of a global, distributed and diverse organization, a “swarm” with a focus on Asia, what I liked about consulting, not a manager.

All of that, and more, came true and I am grateful to Google for giving me this opportunity. I learned more about product development and excellence, customer empathy, tech leadership, reliability and eventually SRE than I ever expected - from the most brilliant and humble people I ever met. I was lucky to work on one the largest scalable, concurrent and low latency systems in the industry, diving deep into (data) observability and machine learning. Helping migrate some of them to Spanner I built up experience to help launch Cloud Spanner in Asia, and with that move from product technology management to strategic cloud engineering. I was again lucky to help integrate and migrate real-time streaming systems and data warehouses, and improve products like BigQuery, Dataflow / Beam and Kubernetes / Cloud Run. The only thing I couldn’t avoid was becoming a tech lead manager again - but I love building up teams and so I focused a lot on creating coaching, scaling (security and scoping), hiring, onboarding and culture programs, with a special focus on inclusion of diverse backgrounds and community and student outreach to make tech legible.

My Tech Interview style (and the Integration Engineer role) [backdated draft]

Note: This post is backdated to the date of the last draft (27 Dec 2021) as I changed my job and role and didn't want to bias / inform myself by that. It's an unfinished fragment of my thinking at that point in time that I just cleaned up a little and added references where necessary, but it's still rough and incomplete.

I've never been happy with the Tech interview process and burned by it many times - being under-levelled, in role I barely understood (a reason I launched the Tech Job Titles list), rejected for algorithm questions ("write a solver for Tetris but in n dimensions"), or simply not even screened for "no product experience". This form of gatekeeping in the tech industry is one of my pet peeves, but it's also simply unproductive and inefficient. It only works because of survivorship bias for people from top universities who are being prepped with special courses, books, test interviews and special coaching by tech firms - as such it functions more as a ritual than actual role fit and/or culture add. It is basically a code (e.g. speaking out loud during programming), and by knowing that code the interviewee signals the interviewer to be part of the same group ("likeability").

My interview style

I've done about ~250 tech interviews at Google and ~250-500 at Accenture, plus quite few in non-for-profit volunteering and my own startups - regardless whether the role was called programmer, engineer, consultant or architect. Instead of going into depth on what the current interview process is or what's broken with it (the list has a few pointers and there is great research by others), let me highlight what is important for me in tech interviews (leaving behavioural and hypothetical aside):

Tech Job Titles

One of the most common questions I get on career panels, mentoring or coaching sessions and after talks is to explain what my job, my role actually is. There is no easy answer, because it requires an understanding of the complex dependencies of roles in "Tech" (for lack of a better word, information technology product) firms.

Information Systems, Computer Science or Design Thinking courses or books for career starters typically focus on explaining the Software Engineer (SWE) job, sometimes the Product Manager (PM) and partially process-specific rituals and roles (e.g. in Scrum the Product Owner). But rarely do they mention the difference between performing the SWE role in non-tech industry (for lack of a better word - firms or public entities that primarily exist due to non-tech “hardware” products even though they might claim to "digitalize" afraid of disruption), in consulting (firms that provide services, usually to the former, to "digitalize") and tech (firms that sell “software” products and services to gain an advantage with speeding up "digitalization"), and within tech between startups and established firms. I've never seen any mention tech-adjacent roles that might have "engineer' in their title but are not SWEs.

With recent hypergrowth, a lot has been published on "upwards"* career management and manager roles in Tech. But I haven’t seen a good resource on the continued blending of these archetypes and roles and responsibilities - with a list of observations and this article as background reading I'm trying to do so. Maybe later I’ll do a variation for non-tech industry companies and consulting firms.

tl;dr I've created a GitHub repo "awesome-tech-roles" modeled after the "Awesome Lists" with the goal of showing typical clusters of tech-adjacent roles and references to good articles that illustrate the variety within the roles - for career starters in the tech industry. The links are examples, observations, not endorsements of my personal view. Given the bias towards SWE and PM roles I've tried to keep roughly the same number of references per role cluster and focus on established tech firms.

A view into state [backdated draft]

Note: This post is backdated to the date of the last draft (31 Jul 2021) as I changed my job and role and didn't want to bias / inform myself by that. It's an unfinished fragment of my thinking at that point in time that I just cleaned up a little and added references where necessary, but it's still rough and incomplete.

In principle, any stream processor could be used for materialized views

Kleppmann, 2017, p. 467

Martin Kleppmann recently gave a great keynote in which he summarized his ideas under a new framework of unordered vs. ordered events and mutable vs immutable state. In the accompanying paper he also gave an outlook on a new wave of tools that "abstract away" these consistency decisions in event-driven systems, in particular "Materialized Views" e.g. Materialize - a great overview on the different patterns is Jamie's article.

I've been a fan of this idea not only since the famous "database turned inside out" (1) quote but actually when I first worked with Spanner and saw firsthand how it turned into an SQL system which required a surprising amount of abstraction of internal (consistency) concepts. Most surprising was that fundamentally Spanner is a messaging system (in other words it is truly distributed and not built on replication paradigms), and could even be used as a queue by observing changes "inside out". In most databases those changes are row-based and often used (with CDC) as basis for event sourcing architectures, sadly mixing physical considerations with domain events. But I am interested in one level lower, of the changes within a domain event entity, and lineage, the reason why. This interest comes from Dataflow / Beam and its consistent view of temporal locality, something I've been keen on since agent-based simulation using Erlang's actor inbox (2). Beam doesn't use "wall clock" time but time in the sense of event-time, flow or an ordered sequence of events or the spacetime / promise-theory goal "to explain a process ... we need to be able to ... tell a story about its behaviours". I'm interested in exposing this state and making it legible and explainable.

Wouldn't it be great to have a database supporting per row state (consistency) metadata instead of state hidden in a stream processing system?

Observability, Debt or the Bret-Victor-Ization of distributed systems

I've been thinking how the different way of conceptualizing cost (in the broader sense of investment) in Cloud changes the tech debt metaphor. It never was a good metaphor to start with and allowed too many excuses, but I like the idea of expressing a suboptimal, incomplete or leaky level of abstraction somehow, as a dialectical, critical tool. I like declarative systems because they allow comparison of state over time, but they do limit expressiveness of our mental models, and omissions, when writing down code. Debt, with its pseudo-quantifiable touch is such a mental model limit. No one wants to keep ADR's for each of these*. How to solve this?

Product-as-code

It's exciting to see how the next step in polyglot programming is taking stacks apart and designating a layer to developer experience for humans based on “progressive disclosure of complexity”, and how we argument for this is feedback time or, in other words, Software Delivery Performance. What a16z recently called The Decade of Design (but combined with craft and lean), the best example probably being Stripe which shows that beautiful API's and documentation and a beautiful website (and beautiful books) might after all correlate, and maybe because they take empathy to their heart (no surprises here for anyone who has seen or used PayPal). 

When I first saw this at Google working with Dremel / F1 and all the Data Mesh tools around it, an ontological, rhizomatic approach to data - without oversight, yet with structure, as side effect of, essentially DDD (or set / category theory, referring to ontology below). And the same when seeing Borg and the Service Mesh around it. Both were built as products with a builder focus, with "a builder" meaning universally anyone who wants to build something, meaning to contribute to a shared idea. When we say everything-as-code we need to go beyond engineering components, we, and that means everyone and the maximum of diverse perspectives, need to look at the product and all of its users. Similar to medical doctors who moved away from seeing "man as machine", or architects seeing the city or the house as a machine, we are slowly moving away from seeing a software system as a machine, perfectly controllable. Technology is not neutral, and a constant process and struggle that goes far beyond engineering.

Operating Manual for the Ship of Theseus

science has always been jealous of art

Over the last 5 or more years I've had kind of an abstinence from conferences and software architecture books. Industry focus was on Cloud, Serverless and ML, leaving system design stalling, with the occasional, rare exception (KNative, Learned Structures, ISA and Simon's ongoing quest for explainability come to mind).

Conference speakers still explain Agile, DevOps, ADR's, EDA and Resilience, while people still pile up tech debt and big balls of mud, just now using Serverless or Kubernetes. The 20 year anniversary edition of The Pragmatic Programmer, which I hold in my hands, says it is “just as relevant today as it was back then”. Given that I saw the limits of Agile, I became more interested in the product operations, SRE side of systems and how observability, explainability, human collaboration and supportability spins system evolution to converge towards simplicity (or not) and builds a community-centric narrative that hopefully enables, in the long term, better socio-technological structures.

Over the last year or so, though, I found myself surprised by an influx of interesting material, in particular in regards to bias, culture, empathy, failure, discovery, resilience (SRE) and risk awareness in orchestration complexity of socio-technical systems.

A welcome change from a long overdue self correction of VC-fueled get-rich-quick startups culture. Concrete examples are my favourite book Accelerate, which inspired a great Böckeler / Fowler talk at Craft Conf and a very entertaining self reflection by Tilkov, and other nice perspectives like George Fairbanks Continuous Design Talk and Nygard thinking about state, Videla's, Wichary's, Steenson's and Ullman's thoughts about weird languages, Design It! (and the 2nd edition of Release It!), but also some really great distributed systems research by Howard and Kleppmann challenging our perspective on concurrency, and new, humble ways to create frameworks.

Empathy for Entropy

It's not simply that Microservices have made microblogging-driven startups suddenly realize the value of BDUF. It rather is the agile move away from Enforcement towards Observation with better tools, empathetic user-centric techniques and ways of thinking about consistency and concurrency. It reminds me of my W-Jax talk 7 years ago, when I first read about Spanner and its formalization of time. When Kleppmann argues for OLEP and Local First, that the queue is the database, it reminds me how Spanner argues that the database is the queue. Both arrive at the same insight: That information and time are entangled, and that entropy or consistency are derived from that. As Howard beautifully analyzed, for our systems it’s easy to replace the concept of time with state transitions (Lamport clocks). This allows us to step away from seeing the system as uncontrollable, and us reactive, to focus on the real, human cause for entropy.

An annotated Philosophy of Software Design

We build our computer (systems) the way we build our cities:
over time, without a plan, on top of ruins
Ellen Ullman

After much hype I've read John Ousterhout's A Philosophy of Software Design which he uses to teach his course at Stanford and presents as a personal experience "opinion piece". Its basic goal seems to be to develop an awareness and intuition about how and when to manage complexity emerging out of proper problem decomposition in Software Design.

Undergraduate students thus seem to be the main audience, which explains why, despite the title, architecture or non-abstract large system design, distributed systems, developer workflow and design thinking are not covered much, and why a prosaic, almost aphorismic writing style were chosen. My assumption is this is  also why barely any references or annotations are given. It's supposed to be the beginning of an iterative journey, similar to language learning. I figured it might help to share mine, though, to go the next step in that journey (Github would feel too official, so blog):

Preface, Iterative process to this book. Exercises in Programming Style 2014, Beautiful Code, 2008, Software Craftsmanship 2001 (Craftsperson) and before that The Pragmatic Programmer 1999 and even Programming Pearls 1986 developed iterative, small-wisdom, later developed into Kata's, based learning of software design.

Meshup

After a recent conference I had some good questions and discussions about the current state of services meshes (Istio in this case), thus decided to note down what I find interesting about them.

I'm a fan of infrastructure-level (polyglot) service meshes. The premise excites me as much as Android ten years ago. Working over those years with SOA, EDA, REST Hypermedia API's, API Management, Microservices and language-bound Services Meshes (Netflix / Pivotal, Lightbend's Reactive), I tend to be careful about the resolution of their promises though.

This post is about 3 lesser known effects of service meshes. My last post already covered complexity, emergence and observability in a more general way so I'll limit those topics.

Reasoning

Horizontal scalability in the multi-core age is one of the main arguments behind basically all modern stateless software architectures. Consistency in distributed systems, immutability and state-handling are often mentioned common properties, typically used to justify functional programming paradigms. To me it seems though, their most important common property is a complex, emergent network graph structure. Layers and tiers cannot represent contemporary systems anymore. Those systems have a complex adaptive graph structure in space (infrastructure, users, component interactions) and time (versioning / one codebase, rainbow releases, experiments, DevOps, event order, routing).

We could observe a lot of frameworks in the last years quietly move towards declarative graph alterations. The first I remember were Android Intents and Puppet. But more recently it was React, Tensorflow, Beam, Kubernetes, Eve (RIP) not to forget the re-emergence of SQL combined with flexible consistency models and stream processing.

All of those come with a robust, well-defined domain vocabulary and set of patterns that allows to precisely define desired behaviour. A graph encourages modularization and reuse, it allows for division of labor: Better specialization while making the overall concept better understandable. This, in turn, allows a wider, more diverse group of people to reason and converse about the behaviour of the system. The shared language and culture may hopefully enable them to learn alongside the system, what Nora Bateson calls "symmathesy". It requires all actors in the system to define goals and dependencies, versioned together in one codebase across layers and components, documentation, test (spec), customer support feedback and architectural decisions. That's why all good (micro) service-architecture principles contain continuous delivery and lean.

There is no single continuous integration and delivery setup that will work for everyone. You are essentially trying to automate your company's culture using bash scripts.

— Kelsey Hightower (@kelseyhightower) November 20, 2017

The biggest difference between those graph-based declarative approaches and Model-Driven concepts (MDD/MDA) is that they are bottom-up, and designed to support evolution*. Instead of requiring a canonical model, tribal ("bounded") domain language or strict interface contracts externally, it is very easy to implement domain-event messaging on the infrastructure level, because the infrastructure itself has meaning, allowing for independently composed distributed systems - in other words choreographed rather than orchestrated.

The declarative, domain-event-driven approach shares some advantage of MDA though: The vocabulary, patterns, and visible graph of dependencies. It makes it a lot easier to follow, though, and a lot harder to ignore. Once the implications of changes to the graphs are commonly understood, it's a lot easier to reason about the graph (see, for instance, the original Flume paper). On the low level that service meshes target, the infrastructure level, this quality makes it a lot easier to reason and iteratively learn the entire system (including the mesh itself and the DevOps process around), and to version, document, track and test the system.

Mandala or The end of control

A good friend of mine asked me why I don’t blog anymore, so I took my new-years flight as an opportunity to write some random thoughts down. Happy new year!

We used to build Information Systems or Control Systems. Sometimes, they were clumsily merging - but finally become something entirely new: Intelligent Intent Systems. I don’t like catchy slang, though, let’s just say we finally have universal “Systems”.

A sufficiently lean online shop is essentially an easy interface for sending a signal into an extremely complex, often entirely automated, logistics chain that translates information into physical control commands - the Information System part manages the feedback loop to humans. The more feedback, an idea from Control Systems, became incorporated into Information Systems, the smarter, faster, and more intuitive we were able to interact. Like frames in a movie, we’re now at the point where it becomes seamless and continuous. The IoT, spatial computing, but actually just technology becoming synonymous with information close the loop back into our world (the "real" world). We used to interpret our systems as essentially closed and deterministic, in both imperative and functional programming styles. But the new types of systems have rapidly become Probabilistic Systems.

With the planet-scale cloud of distributed services risk-driven models, from complexity and uncertainty theory, have taken center stage. With Machine Learning rapidly surpassing human experience in programming and research, we will ourselves have to model the real, human, world in a descriptive, probabilistic way as part of those systems, observing and inferring, rather than imperatively defining the message flows between agents, and its consistency properties, the data flows between processors or structural limitations (think column- vs row-oriented data).

We don’t observe outside of the system, but as a part of it. Much like quantum physics, psychology or sociology (especially of power), told us. We humans are only agents receiving signals in this system. We inhabit a second-order Cybernetics Technosphere we call reality, built on platforms that define what they want and value economically in entirely new, sometimes alien ways, like real-time exchanges including spatial and social dimensions - with the gig- and experience economy only being the tip of the iceberg. It’s not a matrix or a mastermind though, it’s just a real, techno-human ecosystem with its own, uncontrollable evolutionary goals.

Despite me not liking the gig economy, I like the idea of evolutionary systems. Most writing focuses on the iterative process to avoid unpredictability, though, assuming some external, given, linearity, to incorporate feedback. That’s important for organizations, but it’s not mentioned where the feedback comes from: The goal, the adversary, the predator, or the local maximum.

I mainly work on the integration between real world and software, the hard end of mobile / ubiquitous / spatial / pervasive computing. Building independent, distributed service meshes, in a DevOps and Design Thinking (or DesignOps, whatever the cool kids call it these days) way. In such systems, you’re always going after the local maximum, the goal is unclear, more often than not multiple conflicting ones. You’re naturally dealing with (domain) verticals rather than horizontals. Every day has a new trade off between best experience possible and the technical realities. Those systems are not linear evolutions, they are mandalas of expanding and contracting system boundaries. They have to be observable, though, as with observation comes empathy, and with empathy learning.

In the future, we may refactor the parameters of our systems based on deeper insights about their non-deterministic behaviour. That's what I like about SRE-style work. It's the non-deterministic, the probabilistic part of software engineering. It focuses on observability and serviceability, and ML RCA’s involve explainability - correctness becomes an optimization goal, not an axiom. When I spoke about Spanner first time publicly in 2012, compared it to the twisted experience of time in movies like Spaceballs and The Hitchhiker's Guide to the Galaxy. The powerful takeaway is: Nothing is fixed, if we can reason about it, we can change it.

To understand the magnitude of change to our profession, we have to understand the societal context. Of all the possible futures, a dystopian scenario is interesting here - I shorten my version after watching Charly Stross’ talk from 34c3 which tells it better: In this scenario, the we is not a harmonic, transhuman, unity. The new we is us and algorithms from us, for us. A dark (in the sense of dark matter) singularity not of eternal life but thoughtless, mutual uncertainty, where biased algorithms and biased, dumbed down or even corrupt, people push each other further into the edges, not becoming market segments but mobs which reinforce themselves. The algorithm is as helpless as their users, because the society and economy around it require the entropy as fuel making regulation impossible.

Quick, personalized, adjustment, unlearning, or one-shot learning, can maybe avoid this scenario - it seems AI is already forgetting easier than us, controlling and optimizing itself faster than us, collaborating and sharing surprising insights nicer than us. In a "thinking fast, thinking slow" model, maybe the human is ought to become the "slow" part - as Nate Silver once put it "complementary roles that computer processing speed and human ingenuity can play in prediction". Instead of turning away, the human needs to be enabled to act.

Right now, we train machine learning systems by saying “yes” - soon we will reach the point where transfer is so good that we’ll start saying “no”. That “no” has to be slow enough, it has to be thoughtful, and it has to weigh more than assumed silent consent. We have to introduce reason, empathy and ethics, not only into individual machine learning models, but into the whole system that is driven by technology, into all of the information and the human organizational complex around it.

What excites me about working with systems from an observability, serviceability, and explainability perspective is that we can bring all of that rich knowledge from physics, psychology or sociology, hermeneutics, but also art in, and start reasoning about the overall behaviour, rather than deterministic, imperative requirements. We only have to keep talking to each other - and try to understand.

On the other side of Certainty

"We have to create the preconditions under which

Exaptation can happen naturally...

which actually means introducing inefficiency into systems"

Dave Snowden

"The question is no longer how systems behave ...

but how to ask for the probability distribution

of the properties that change the system"

Helga Nowotny, The Cunning of Uncertainty

Moving from project- into product world last year, I wanted to experience the real long-term view, because only strategy can tackle complexity. And our software grows more complex, though arguably less complicated, every year. But I also wanted to understand uncertainty, the dark matter of complexity, better. After some time in, I understand it's probably more important for an architect* to have strong operations knowledge than very strong algorithmic skills.

Resilience is sometimes mistaken as being adaptive, or agile. It just means expecting uncertainty and disruption, but also working properly under normal conditions. Just calling everything disruptive, and reacting in an agile way to every random demand, is not resilient. For instance, "The datacenter as a computer"** came to us, rather unexpected, from a relatively "boring" infrastructure level, rather than from new frameworks and startups, but also not from consortium standards and language ecosystems. Similarly, in true grassroots manner, polyglot programming and JavaScript on top of Unix principles catapulted us into the 21st century and will eventually enable domain logic to exist, as Adrian Cockcroft calls it, in functions, unaware of most technological constraints. In order to understand resilience, you need to care about your product, and want to improve it, have a real goal, a story you want to tell. Ironically, you have to be a little bit un-adaptive, inefficient and un-agile in order not to overfit, but to really improve.

We are still waiting for the 4th paradigm of programming. My guess is it's going to be more than just goal-oriented, it will be probabilistic, in the sense of an abstract goal corridor. While engineers will live inside the goal corridor, making sure its workings are predictable, specializing in certainty, architects live on the outside, in the long tail of the probability distribution, the Multiverses where the Dragon Kings live, outside predictive models, specializing in uncertainty. That’s what makes a system resilient. It implies engineers have a fairly static/discrete/fitted view of a system, the perfect snapshot, the position, whereas architects have a time-smeared continuum perspective, the story, the momentum. It's the whole story, not only the goal, that differentiates between emergence and evolution. But it's also important to understand that both of those roles are equally creative and forward-looking, none is a "higher level", they are two sides of the same coin.

Helga Nowotny's distinction between risk and uncertainty fits nicely here - risk can be computed, uncertainty not. Risk a relation between snapshots, uncertainty is the continuum in between. A weather forecast has risk, the climate is uncertainty. In that sense, a risk-driven architecture involves everyone, but uncertainty needs a different perspective. The future leaves to the architect (the systems-of-systems-carer, archeological gardener, forensic librarian, ontological cartographer or whatever you like to call her) the role of the curator, and maybe narrator, of the uncomputable. Paraphrasing what Akka Architects say: Architects don't design system interactions, they curate the context for a discourse about system interactions.

"It is not a question of establishing limits with walls,

but by other means"

RCR Architects

Why is all of this important, why should we get used to speak in terms of probabilities, but, most importantly, tackle certainty and uncertainty differently, but with the same importance?

In my last job I learned the importance of maintainability and traceability. In every single one of my projects the first thing I introduced was proper monitoring, alerting and analytics - Robustness was core, as was accountability, to be able to become lean and agile. With new infrastructure, whether in the cloud or not, this has become the default. The battle for certainty, traceability, and robustness is won.

While we were busy fighting this battle, uncertainty has come back, as Ms. Nowotny would put it, "systemic risk", as risk deeply embedded in the complex relationships of our services: "Uncertainty switches gestalt". A cloud service going down is a risk that can be predicted - the dashboard not showing it, because it is hosted on the same cloud service is systemic risk, the type of Dragon King uncertainty which we don't expect. Soon it will be mainstream that coders will pair with AI, and operations and product teams will regularly train models rather than manually define metrics. The relationships between components will become so complex that, more often than not, it will take a long time to even recognize errors, or feature usage, let alone find the root cause or customer need.

Despite all the data we accumulate, Observability does still not mean Explainability (sometimes as beautifully visualized as our old architecture diagrams) or Introspection, the ability to rationalize the inscrutability of AI.

Most of our architecture diagrams are nothing more than Thomassons, useless depictions of a fictional state which we only keep because it took us so long to create them. But similar to code, it's actually more productive to delete them. What we need is a visualization of the statistical complexity of actual state. In my book, a good friend of mine wrote a story how we made network traffic audible in order to hear inconsistencies - that's what we need to understand the architecture of a system. A real-time explanation of what's going on, mapped to the architecturally relevant components, such as interfaces, deployment units (like functions) and, last but not least, rules inside machine learning systems.

I am looking forward to new, real-time programming and data toolkits, think Eve, Jupyter and Glitch, especially because they enable a different kind of coder to build software. And with serverless and deep learning we will be able to scale those apps and the data required quicker than ever before. But it will require architects to understand them, if something is wrong, if a use case needs to be developed or a feature is behaving unexpectedly - i.e. in operations and product development. These architects won't be able to look at diagrams anymore, they won't be certain about documentation (not that they ever were), and they won't even be able to observe the system in its entirety. Architects will indeed become archeological gardeners or forensic librarians. Most importantly, they will become like anthropologists or biologists in the early days, trying to understand evolution, with the help of experimentation and collection. We'll finally see architects developing models instead of diagrams. And with that, we will see very different people in this role too. Which is very exciting.

*) separating this from a Tech Lead here, sometimes it can make sense to combine the two roles, though
**) e.g. serverless computing platforms such as Lambda and globally distributed databases such as Spanner, with them a different approach to time, where evergreen becomes an axiom, but also a comeback of Spreadsheets through functional programming and k/v stores

Letter to my future self

This is a variation on a letter to my future self, just a public one. A reminder what I thought, written on the last day in my old job - exactly 6 months ago. I would write it differently now, so I’ve added many current links. Don’t read it as a manifesto, read it as a snapshot.

When I quit my first full-time employment in a start-up, after my own one, it was because I felt start-ups disguised the struggles for power under a hood of coolness and artificial problems.

I joined consulting to be outside of power structures, and tackle real problems (as real as it gets in corporations). Accenture Digital was inspiring, and t-shaped/widened my horizons - more than once. It allowed me to thrive in technology, strategy, product prototyping, Agile, design thinking and to trust liberal arts. I will always remember the learnings in those years: All the opportunities I had to meet great, diverse, truly interesting people across the globe, to learn about dozens of domains, to build digital-first, mobile-first, offline-first products, omni-chanel SPA, Microservices with vertical slices, API management and EAI, or CQRS systems. In short I am grateful to have been inspired and had the chance to inspire others.

Really building stuff around existing problems is what makes technology consulting so amazing. Seeing what you’ve built in the wild, changing the way an industry runs. Building a team around a problem, changing their perspective, and mine. Unlearning is just as important a skill as learning. We are constantly developing, iterating, behaviours, patterns and principles of good systems, including its human actors. These principles always come with a drawback, outweigh by the advantages. Microservices might manifest team separation and can lead to incoherent style in end-user product experience. Event systems enforce eventual consistency, and not every organization is ready for probabilistic thinking. Containers can degrade security (and with it privacy) to a part of commerical opt-in dependency-hell rather than reliable infrastructure; Design Thinking either glosses over faster horses or fakes ownership because agencies just rebrand; Patterns sometimes promote solutions that only look good on paper; CI, Lean and Feedback prefer simplistic, biased, measurable KPI’s over long term goals. OSS, Agile and DevOps can establish a status-quo burn-out treadmill of minor, over-hyped, pseudo-improvements, and holocracy could build a cast system; Opinionated often just means tribal or elitist (for lack of a better word); competing API, AI and Cloud standards with unexplainable, magic automation and integration can cement vendor lock-in; Cross-vendor services are still not solved, maybe due to academic REST and DDD being inherently anti-evolution with their focus on a Xanadu-ideal, fixed state. And simplicity does never illustrate success, while complexity does. Not everyone wants to hear those drawbacks, and few openly make the tradeoffs. Most want to hear the innovative, the disruptive, which sometimes simply excludes the best option for the largest group.

In addition, the problem with the typical project organization is that it takes a lot of effort to not disguise debt with another layer but actually change the underlying problem (a post on this is coming up). I always enjoyed this challenge, and I had the pleasure of being on many projects which achieved this, and turned into real, strong products. But kickstarting this "digital transformation" every so often started to nag on my belief in actual progress.

An unfortunate side effect of the project and OSS “publishing” treadmill seems communal wisdom is often discouraged in favour of new marketing slang. Or, like Maciej puts it:

"This is not the first time an enthusiastic group of nerds has decided to treat the rest of the world as a science experiment. Earlier attempts to create a rationalist Utopia failed for interesting reasons, and since we bought those lessons at a great price, it would be a shame not to learn them"

Sometimes it feels through lean and measurability the Peter Principle and pop-culture power struggles in the form of Deutungshoheit have eventually arrived in what used to be an idealistic geek world of IT, pushing practitioners from actual consulting into meta- and consult-speak. If software indeed eats the world, it seems to prefer junk food. To avoid this trap I took a step back on conference talks and wrote an obscure book. But I am interested in historical patterns, across disciplines, which is hard to communicate. The nagging feeling stayed.

So I decided it’s time to move away from a project into a product organization. I wanted to feel out of my comfort zone again, but still contribute to technology. A few of my considerations which company to join, in no specific order, were:

• It should be first class in building delightful products with end-user impact, where good design is a strategic asset. Not just gadgets. I see technology simply as a tool to materialize curiosity. 
• Many traditional enterprises consider themselves digital companies now and like to use “disruptive” technologies, but I haven’t seen many who actually care. Mostly it's a hedging strategy. I want to work in a real digital enterprise, maybe on intelligent and intuitive products (e.g. what I often miss in AI and technology as a whole is the capacity to trace the intent “why did you do that”?) 
• It should be first class in technology. I am more of an operational excellence person, so I don't care if it's boring technology, as long as there is a clear rationale and it makes a real impact. In short: An engineering mindset. 
• It should see information and technology as a narrative. Over the years I’ve got more and more interested in systems of systems, the polytechnic, involving people, and believe the role of an Architect is to enable strategic, uncertain, but fair, critique and decisions within the team. 
• It should have a strong and clear vision, not only building products but aligning those products to a long term goal. However, I would prefer that goal to be ethical, not to wipe out the middle class, centralize means of production and distribution, or make everyone dumber (Note: This was written before the US election, there would be much more to say on this in hindsight). 
• While I believe my strength is to be a good tech lead and manager, and I enjoy building teams, I’d prefer less hierarchical organization (ever wondered that squad is a military term?), rather a swarm - what I liked about consulting. I’d prefer a strongly influencing, not necessarily managing position and a slightly slower, maybe even less visionary, but more humane company. 
• It should be global, distributed and diverse. Living in many places, working with people from all kinds of backgrounds has enriched my life more than anything else. I have enough startup experience to not believe fast-moving (hierarchical) unicorns necessarily make better corporate citizens. Hence I prefer truly multinational, larger organizations. I like foxes, not hedgehogs. 
• And finally, for now I want to stay in Asia, with its multiplicity an ideal model for the ever more complex and uncertain systems in his world, the opposite of the power structures I encountered in the past. Someday I might want to leave corporate world, and work on the grass roots. Asia is the best place to keep this door open. 

Google’s 10 things always resonated with me. They maintain a hive-mind culture based on research while at least sometimes trying to improve the world (yes, I know Silicon Valley). I am continuously impressed which brilliant people work there, and the degree of freedom they have. Let’s see if I can meet a few and learn.