Positive stress. Yeah. Smooth. Yeah. Okay, anything else? Anybody wants to have their larynx used right now? Rush! Okay.

Last chance. Last call for flow.

Clarity! Yes. Flow. Did you say glow or flow? Okay. Alright, so, for the autumn, autumn kids and the winter kids. What words came to your mind?

Wait. Frustration! Stress again. Okay, here?

Tension.

Sorry?

Blockers. Yeah, blockers. Yeah. Huh? Multi-load. Mental load. Oh yeah. Okay, yes, that’s true. Yes. Anything else from the,

Solo work. Oh, okay, that’s absence of flow. Okay. Some people might disagree. Okay. Hierarchy. Okay, interesting. Getting more and more interesting. Alright, so, I really, I hear some words coming, popping out, it’s about personal flow, right? And others are about, you know, collective flow and, and, and so forth. Some people even solo work is flow. Other things, not so much. So, let me share, so, for me personally, you know, when I’m in flow, I feel that, okay, there are few, few words popping up, when I’m in flow, I feel connection. Right? Connection to myself and to that thing I’m doing. Okay? So, and then also I’m in movement, I’m not stuck, I’m not stagnating. And, what else, um, I think also there’s a kind of lightness when I’m in flow. Right? I’m light, I’m even, there’s even a a kind of softness. Like I’m not managing or, or, controlling the results. Because usually managing and controlling is what pulls me, you know, I’ve got to show you the slides, right?

Uh, it pulled me out of the flow like, like a kinked water hose, garden hose, right? So, this was a little bit, of a, it’s not a icebreaker, it’s something called connection before content, thanks for poking that frog with me. And going to the first part, where does flow meet architecture? Well, one suggestion is that it does, as they do in the 11th agile principle. Which says, the best architectures, designs and requirements emerge from self-organizing teams. And the rationale is really quite simple, right? When you have skin in the game, you, you understand what’s been designed, then you’re more motivated and you’re more empowered and then you’re more engaged, right? So, but really, let’s, by a raise of hands, who has seen in practice truly emergent architecture in their lived experience? Yeah? Yeah. Great. And who has mostly seen up front architecture? More hands coming up. Who thinks it depends?

Mm, that’s the majority, I guess a lot of you are architects or consultants. Yeah? Alright. So, anyway. So, right now, another invite, so activate your imagination and imagine sort of a seesaw, if I see a seesaw, you know what I mean, the teeter-totter in a children’s playground. And imagine you have up front architecture on this side, and that’s, that’s like hard to change decisions, right? And on this side, let’s imagine truly emergent architecture, that’s where the Agile principle 11 wants us to be, right? That’s, you know, when, when software gets more complex, you know, disregarding Greenfield or Brownfield, our organization also gets more complex, and coordination gets harder and harder. And therefore, complexity sort of pivots this seesaw more to the up, up front side, right? And, um, Jean Kim and Stephen Spear, captured this tension in their 2024 book, learn from winning organization. And in that book, they asked this question, how do Jean and C move a couch in a scaled organization? This might seem a very straightforward task. But moving a couch actually needs some design, right? You need to find the center of gravity, and if you have this narrow winding staircase, you need to work out, you know, which side goes first, at what angle to rotate it, who goes forward and, and, and who goes backward and that sort of thing, right? But many other things can get in their way, right? You know, they, they might have to get, um, the room the couch is going, it may not be ready yet, it needs to be cleared for furniture. And that’s another team, and might, it needs to be painted. That’s a third team who’s, who are working on different tasks. And maybe it’s all that contextual information, they need to get that filtered through five different, um, people, right? So, those people need to coordinate this very zero task about theirs, that moved a couch in a context dependency graph, um, so things can, you know, get coordinated in Scrum of Scrums and PI planning and that sort of thing. And maybe their architects want them to break this couch into small microservices, moving one part at a time, or worst of all, perhaps they have no idea why they’re even moving this couch. That’s the worst, right? So, once I heard a developer rant online, you know, agile was from. Really stifles my agency and squeezes, me into this mould of an obedient and micromanaged factory worker. So talking about factory, that’s actually where the concept of flow actually, you know, originated, right? Um, that’s where, you know, lean thinking, reduced waste, limit with input process to output predictably, repeatably, and that sort of thing, beautiful when what you move is material. In software development, we do not move material, we move information. And the flow of our work depends on the flow of understanding. And therefore, you know, in our agile value streams, in our CD pipelines, delivery pipeline, we try really hard to move those, that information into the actual, decision points, action points for the humans to act on. But humans have this thing called bounded rationality named by Herbert Simon in 1955. And that means, you know, as humans, we cannot load the entire information of the whole system into our brains at once. And even if we could, this computer of ours, it doesn’t run, you know, it doesn’t calculate perfectly, right? Under time pressure, it will take shortcuts and it will fill in the blanks with biases. Right? Under time pressure, if any of you have done, you know, coding with, AI agents. Do you notice a difference when you review a genetic code early in the morning and late in the afternoon, when you’re tired? You would tend to think, oh, that’s good enough. You know it isn’t. You know, that’s how bounded rationality works. So, This computer of ours, it doesn’t run, you know, it doesn’t calculate perfectly, right? Under time pressure, it will take shortcuts and it will fill in the blank with biases. Right? Under time pressure, if any of you have done, you know, coding with AI agents, Do you notice the difference when you review an agentic code early in the morning and late in the afternoon? When you’re tired in the afternoon? You would tend to go, that’s good enough and you know, it isn’t. You know, that’s how Conway’s law on emotionality works. So, Martin Fowler once said something that fundamentally changed how I think about architecture. Architecture is a social construct, he said.

It is about shared understanding of the important stuff. Right? So, what is important here is really to flow that shared understanding

to the decision points, not by dumping information, but by somehow facilitate the contextual understanding of the big picture. So, here is that seesaw again, right? Visualized. On one side, we have the upfront architecture, the hard to make decisions. And that’s the agile discipline. And on the other side, we have the emergent architecture, that’s principle 11, that’s, that’s the real agility. Right? And to keep the teeter-totter in movement fluently, we need to cultivate architecture as a social practice to make sure we have, we can flow the shared understanding

to the actual decision points. So from that point of view, architecture is a socio-technical seesaw. Right? So, coming to, moving on to the next part. Are you still present? No one’s falling asleep? Okay, great, just checking in. Okay, so, in this, in this next part, um, a little warning, because there will be a few frogs, I’m suggesting that we poke that might feel a little slimy or just a little comfortable to touch. So, um, let’s see how it works. So, all of us, I think, know what Conway’s law is, right? So, basically, software design follows the organization the communication structure in organization that builds the software. So we have three, if you have three teams, then you probably end up with three architecture parts with their own subsystems components, etcetera, etcetera. And now, recently, some companies have tried something called the inverse Conway maneuver. Which is to say, you know, let’s design the software architecture up front and reshape the organization to match that, basically flowing software architecture into the organization. And now, in this particular example, we want vertical slices and we want independent services and we want reusable platforms. And therefore we use team topologies to design, care getting too loud. to design stream-aligned teams supported by platform teams. So, in practice, something interesting happens in some companies. platforms gets bypassed sometimes, usually it’s because, you know, these these platforms they don’t have good the dev the developer experience. And so logic gets duplicated anyway, it becomes inconsistent and integration gets messy. So the architecture we wanted at design time and the architecture we observed at runtime seem to drift apart. And why does that happen? One explanation is that architecture tends to, you know, reflect culture far more reliably than culture will obey architecture. Fundamentally, it is also because, you know, organizations and software systems, they are completely different kinds of kinds of systems. An organization is a living system that re-creates itself through this process called autopoiesis. And that’s a Greek word, auto means self. And poiesis means creation. So a rainforest is autopoietic, right? It creates, it, it produces trees, soil, humidity cycles, and most importantly, it creates the conditions that allow it to remain a rainforest.

In contrast, a car like a Ferrari, is created through a process called allopoiesis. Allo means other.

So a Ferrari is created by something other than itself. So is a microservice.

So, organizations and teams keep reproducing the same communication patterns, decision habits and even their mental models or narratives, right? Again and again. But software organizations are also a combination of these two kinds of systems. We have these, we have our software system which are technical systems and they are allopoietic, meaning they can’t generate themselves, well not yet at least. Um, they are embedded inside the organizations and teams that are creating them. And so this, this embeddment basically implies that social complexity subsumes technical complication. And so in that earlier example, inverse Conway, what we see happen is that a backlog-driven feature factory is reorganized into a product, virtual slice product teams and organization. But then the structures change, but the organizational habits haven’t. You know, basically what the reason why I knew it is because I’ve been there. What happens is that product, project managers

in the old times were basically re-purposed to product owners and DBAs become product teams. But, you know, product still means prioritized tickets and value still means throughput and performance still means delivery speed.

Right? So, basically, for autopoiesis, this organization will keep reproducing silo thinking and local, local optimization and the narrative of autonomy can even, you know, lead to more fragmentation. So, here’s the frog that to poke next. That is to say, Conway’s law is a one-way street. Period. End of story. So, to try to fit a human system, you know, inside a technical target architecture, is like trying to contain a rainforest inside a Ferrari. A living system cannot be contained by a mechanistic structure. Okay. So, if organizations keep just keep reproducing themselves for autopoiesis, does that mean nothing can change? Does that mean we’re simply all trapped inside systems? And that is where the conversation about autopoiesis can somehow get uncomfortable. Um, because, um, it somehow tips into fatalism, right? So we kind of all know these stories. Oh, it’s the system. It’s the management.

Those people, they don’t care. They have to change.

Me? Yeah, the system is so big, I’m so small, what can I do? It’s above my pay grade anyway. Right? So, and the externalizing ones, right? we don’t have clear roles. Not the right skills.

And, you know, ah, nothing’s going to change, it’s, it’s always been like this. Workplaces are never safe. And then, you know, when our favorite interventions like DDD, like team topologies, or Wardley Maps, or you name it, lean, agile, whatever, don’t work, our disclaimer number one, you know, seems to be blame it on culture. Culture eats strategy. And everything else for that matter, for breakfast. Right? It’s not our fault. Right? So it’s all culture. Um, right. So Peter Block invite us to, um, basically turn the question around. Instead of asking, what’s wrong with the system? What’s wrong with these people? You know, I can say, do I want to be the cause or the effect? A victim of the system or participate in creating something new?

Um, and so because if, if organizations are re-created by the interactions in the system, then every single interaction I am personally part of has the potential to either keep the system as is, or change it. Whether we like it or not, we have an inevitable part

in the autopoiesis by being part of the system. And so that’s a conversation, ownership conversation we can have with ourselves and with each other. So Peter Block has a set of questions, uncomfortable, inconvenient, but important. One of those is that what is my contribution

to the very thing I am complaining about? What is my contribution to that very thing I’m frustrated about?

And so, you know, um, I ask you to do that clo no clo again. Now recall that time when you, when work really, really flowed for you. Like you are not only doing the work, it’s not because the work needs to be done, but it’s like you are creative and you’re connected and the work is like pulling you forward. Then recall that time when nothing flowed for you, right? You’re like a task being allocated and you’re like, you know, you’re like a resource, you know, just moving through the pipeline onto somebody else’s dashboard. So that question about cause or effect, effectively, that one becomes, am I being flowed, or am I flowing something that I want to be part of?

And so, the that question actually points at two states that are related to two types of flows in our software development. One is delivery flow. That is an allopoietic flow, where value is created in the nodes, right? In each of the sub-process steps. Right? And here we assume that information, un-material for that matter, can be objectively processed, stored and, um, transferred from node to node, from component to component and from team to another team. So beautiful if what you flow is really material, right? And another thing is that we really want to minimize the lines, we want to minimize the interactions, you know, the lines between these nodes, because that’s where the waste is, that’s where the wait time is. And we don’t want that. Okay. The other kind of flow is a generative flow, and that is an autopoietic flow, where value lives in the nodes and in the lines, in the connections. Yeah? And so Jake Bloom describes it this way, it’s not that I add value in the process of creating information and handing it downstream to someone else. It is in the handing of my thing to someone else that creates the information. So that’s J Loom.

And so here, the lines are where the actual encounter happens, right? That’s and the interactions are value adding, they are not waste. The handoffs need to be softly designed. That’s the generative flow.

And so now we see this seesaw again with, you know, deliver flow on this side, and that’s the stable throughput, that’s our lean practice, that’s our predictable CICD pipeline, that’s our measurable door metrics, that’s what whatever that our dashboards can see, right? And then on the other hand, we have the general, generative flow, right? That’s the relational, the conversational, sometimes the relational, um, and that’s, you know, that’s, that’s the energy we have. That’s the energy in the room when we collaborate, when we do collaborative modeling. And that’s, that’s sort of the feeling that we are pulling weight together towards something greater together. And in the delivery flow, we’re moving work. And in the general, generative flow, we’re moving meaning. And to architect for flow, we need sociotechnical architecture. The thing we need to take care of, it’s still the shared understanding of the important stuff so that we can have people care, um, their energy and their creativity to flow alongside output and outcome. And that is sociotechnical design. we collaborate, we do a collaborative model. And that that’s sort of the feeling that we are pulling weight together towards some great stuff together. And in the delivery flow, we’re moving work and in the generative flow, we’re moving meaning. And to architect for flow, we need social-technical architecture. The thing we need to take care of is still this shared understanding of the important stuff. so that we can have people’s care, um, their energy and their creativity to flow alongside output and outcome. Again, that is socio-technical design. Um, and so, the next thing is to ask a question about socio-technical architecture. So when we talk about technical architecture, software architecture, we work often with something called quality attribute for architectural characteristics. These guys, like these abilities, they are the conditions for delivery flow, right? And the socio-technical system around the software, it also has its own quality attributes, like business connectedness, belonging, aliveness, freedom, and wholeness and openness, right? These are the conditions for the generative flow. Right? So this is kind of like

the social-technical architecture. You see the difference and there is a paradox to navigate. Because when we look at again, when we look at technical architecture, the emphasis is on decoupling, is on decoupling, right? Modularity, separation of concerns. It’s almost like a declaration of independence. And now the social side, what we emphasize is connection, shared context, common ground. Right? These are kind of a declaration of interdependence. And so the paradox is, sometimes to decouple software properly, we have to connect the people better, not divide and conquer them better.

So, this is actually a quite difficult paradox, and I feel that this sandbox metaphor has helped me navigate, um, um, the the distinction in my work. And so, for to architect for delivery flow, we often need this the left side, which is the deliberate alignment, which is usually a centralized up-front effort, to architect for the generative flow. We what we often need is a coherent emergence.

Alignment looks me to the left-hand side, and coherence looks like it looks alive, right?

And the the sweet spot between these two, that’s where, you know, that that’s where I see the frontier of my work. And that is very close to my heart. And so, you know, the if you if you only if we only have the alignment, we only have, you know, diamond meetings, strategy and tree structured everything. We get people to watch with great intellectual interest, um, and they can follow the rules. But if we also have, you know, if we also have coherence, then we can get the kids into the sandbox and play and engage. So that’s that’s that’s the sweet spot. So, um, so if I I’ve done so many talks about socio-technical architecture. And so, I think if I claim to be a socio-technical architect, I’ve got to put some definition on the table. And it’s it’s about time. This is too long. This is the TLDR kind of the definition. Um, this image says exactly the same thing. And so, socio-technical architecture is the intentional design of conditions and the scaffolding of in the moment interaction. What are we designing and scaffolding for?

Deliberate emergence. And what that means is to jointly

optimize the well-being of the software systems and the well-being of the social systems so that stability and change can co-arise in co-evolution with the environment because we’re talking about open systems.

Okay. Are you still with me? Okay, great. That’s a lot of heady stuff, a lot of brain stuff, right? So let’s briefly switch to storytelling mode again. This is my own moving the couch story. When I was, um, when I was the lead architect of a really large product initiative in a Nordic financial institution a few years ago. And this product initia, so this organization has been reorged using the Spotify, model. And, um, you know, every, and this is across 27 squads and five tribes, I think. And every single workflow in this initiative involved deeply nested API call chain and continuing event cartography. There are seven, 27 of them, right? So, um, so the effort to coordinate and create that shared context, which was partly my job as the lead architect, was enormous. Um, no couch can be moved as an independent action in that initiative. But that story was also a backdrop for me to understand the two kinds of socio-technical blockers for flow.

So, one is delamination. This is J. Bloom’s term. So, the delamination, as you can see in the image, you know, it’s just kind of like the the water hose kinked in different ways, right? The blockers, um, the here the vertical flow is, is cut off basically, right? So, um, and so we have the strategy layer and the and the execution layer disconnected from each other. The people setting the directions and the people doing the work are no longer in the same conversation. And all the layers, you know, also middle management, they keep moving, but they’re not not moving together anymore. And so, in my moving the couch story with those 27 teams, that that is that is what we’re trying to mitigate, right? So, not to delaminate, to do something about it. The other blocker for flow in J.K.’s terms is called disintegration. That’s where the the horizontal flow is cut off, right? This is when teams are disconnected from each other, execution is fragmented, we have local optimization, we have silo thinking. Each of these 27 teams have their own OKRs. And they need to operate their, you know, prioritize their own stuff alongside the, the, the, from the product initiative, right? So that is this integration.

And so, one antidote to delamination is is is this, right? So, basically, what we need to do is to re-establish the vertical flow, and scaffold the conversation so the people that person working on this task, here, can understand how that task can complete the experiment, validates the hypothesis, supports the strategy, and realizes the user’s need. That chain from task to user need, that is what J calls pooping the wide back. And that is what that was my mental model at that time when we were dealing with the delamination in that product initiative. And and the reason, so I’ve correlation, the reason why this works is what Danny said, right? Joy in work comes from the understanding why your work is important. Not from the work itself, but how what difference your work makes in another person’s rate, right? So, basically, that’s the North Star, and if you think about all the confusion AI is giving us, we need something like a human-centric North Star always, as humans. So we’ll come to that back to that later. An antidote to this integration could be this thing called re-combing it. It took me several iterations myself to understand what this thing really is. It’s also from J Bloom. It’s called the three economies.

So, on the left-hand side, we all know this, right? We have the speed economy. The the question that matters here is that how do we differentiate as a company, how do we compete in in the market? No differentiation, you’re going to die. And on the other side, we have the, um, the scale economy, right? Economies of scale. And this is the question that matters here is that how do we standardize, reduce cost, reduce, you know, limit with, um, reduce waste and increase reuse, right? That that sort of question. I in the middle, we have the scope economy.

And here the question is, how do we standardize to differentiate for the common good?

And so, the capacity for scope economy thinking and for recombination, that is not something that can be mandated, trained, um, or specified.

It can only be achieved by architecting for the generative flow so that people teams can choose to take ownership.

You know, to optimize for the common good, not their individual OKRs, right? Not those, you know, those 27 teams, how can they jump out of their own road maps and start to see what is good, what is good on the common layer, yeah? So, basically, that that generative flow capacity is what can turn the tragedy of the commons to the joy of the commons. And that’s that’s why it is called recombine it.

And the capacity of recombining also depends on if socio-technical architecture can become everybody’s business. And what is meant by that is architecture is a set of skills that need to be embraced by, you know, software engineers, ops engineers, product managers, and agile coaches. All these people, they need to understand the consequences in order for architecture to arise.

Not come from top down. And architecture is about policies and interactions and not about technology. And it reminds me of what Jim White said about software development is an exercise in human relationships.

Okay. Those are the dry, dry, dry theories.

I hope you’re still awake.

And now, let’s do a quick check-in. So, on a count of three, I, um, can you give me a thumbs up for I’m doing great? And on a count of three, not not now, okay? So, a thumbs sideways is a, or any angle, I’m hanging in somewhere, right? And thumbs down, where’s the door? I I need to leave now. That’s that’s this, right? So, one, two,

three.

Oh, wow. Okay. Thank you for your honesty, and and I see most of the thumbs up, I’m actually quite surprised.

Uh, but there are, okay, risk signals and and and thanking for sharing that with me.

I’m almost off the hook. But here, this is the final thing. This is a socio-technical experiment, we did last year at an insurance company. It’s still a work in progress, and this company doesn’t want to have its real name, um, disclosed. So we’re just calling them Flux Care. So, last year, around September, Flux Care, um, organized a multi-day offsite to, um, you know, reimagining their future AI. A lot of companies have have done that. Right? So, the question they threw on the table is basically, you know, how do we embrace agentic architecture in their core domain workflow, which is, um, for in this particular case, it’s the insurance claims workflow. And so, I guess everybody has an intuition about how insurance claims work. When, for instance, your the windshield of your car gets damaged, then an address will go through it. It potentially could involve many actors and many steps. And imagine adding, you know, AI agents, agents to to that workflow, right? So, agents, um, assisting assessment, arranging, coordinating inspection, booking time, and, supporting decisions, um, and even, you know, coding core domain software. So, all of it. Um, and so, the the architect guild in that company, um, suggested we, explore this through some what they call collaborative API, ADR workshops, architecture decision record workshops. Basically, it’s a variant of Njus, um,

you know, architecture advice process, but they just call it this. So, I’ll just use their terms. Um, anyway, so, um, to discover architecture, um, requirements, we did something called emotion mapping or empathy mapping, which is a lightweight version of customer journey mapping. Who has done customer journey mapping here? Oh, wow. Nice. Good to have you here. Um, anyway, so, it’s basically you plot the customer’s, you know, emotional journey across touchpoints. Right? So, and when we put this question on the, calendar, in might, a lot of people got curious. What is making great emotional journey for. Actually, the architecture guilds had the highest turn turnout rate in in those workshops because it’s voluntary and sometimes people just don’t show up. So, this obviously has created some attraction. So, day one of the, I don’t have much time, so day one of the workshop is basically focusing on two things. People, moments and emotions. And, what we ask people to do is basically map the actors and the key moments in the claims workflow and, um, you know, in the end, the emotional ups and highs and lows when AI becomes part of the workflow. As you can imagine, this triggered quite some, you know, um, tech uh skills that, they have the highest turnout rate in in those workshops because it’s voluntary and sometimes people just don’t show up. This is obviously has created some traction. So, day one of, I don’t have much time, so day one of the workshops basically focusing on two things: people, moments and emotions. And uh what we ask people to do is basically map the actors and the key moments in the claims workflow and um, you know, in the end uh the emotional ups and highs and lows when AI becomes part of the workflow. As you can imagine, this triggered quite some, you know, um, Oh, I’m sorry.

this triggered some vulnerable conversations. And for instance, let’s take Sam, the customer support agent for for example. So when a claim is denied, um, Sam might want might have to explain the the the denial, so the the decision to a frustrated or even angry customer, right? So, but then because the decision was probably made through multi-agency systems which Sam probably don’t fully, it doesn’t fully understand. And at that moment he could feel quite helpless. So that’s that’s a narrative. And so, now on day two, this is basically the the pipeline we follow, it’s the road, the moments emotions and then to architectural question and then architectural requirements, um, or architecture characteristics. And so in the case of uh Sam, the emotion would be then, you know, helping this, right? And and and that leads to the architecture question, you know, how how do we avoid putting Sam in a position where he feels um um um um helpless explaining AI assisted decisions to to a customer calling in. And those questions are kind of framed as a conversation starter, which eventually lead to uh the architecture requirement stated first in natural language in this case. The system should be able to trace decisions across across agency systems. And eventually that distilled further into that label we want, right? The architecture, I don’t want to say that word, decision explainability or traceability. So that’s kind of the project.

And what’s the discovery there is that the when we document, when we basically consolidated the findings across different workshop groups, the architectural characteristics seem to live, a lot of them seem to live on the right hand side. So basically they’re both about um, you know, uh quality attributes of technical systems and functional attributes, but also the social, the relational, the organizational, it’s about, you know, how people, the relationship between people and the system and between people and people. If you look at the bullet you’d have a meeting about that.

And so the insights we gleaned from um, from that uh exercise is that emotions and questions become or can become architecture, um, material. So if we take emotions first, if we if we like to think these decisions are rational, right? They’re they’re not emotional. But you know, it turns out, if you take out the emotional center of a person’s brain, this person cannot make any decisions, not even what uh color pen to use or what clothes to put on. The reasons neural science actually um shows that we human beings, we are not thinking machines that occasionally feel. We’re actually feeling machines that occasionally think. And so to have emotional authenticity, we also need psychological safety. And therefore it’s important that the executive team came in on the first day of the workshop and gave this permission. Let’s all talk about how we feel about AI, no taboo, no judgment. So bottom line, the the that one-liner we we put down, actually, I didn’t do it, it’s their architecture team. It’s architecture characteristics are compressed answers to human emotions at critical moments.

Great. So, you better.

All right. Um, so on a personal level, if we want to have flow, we need emotional uh flu emotional fluidity. The capacity to feel all our emotions and allow them to move through us without resistance, because what you resist will actually persist. Avoided emotions do not just disappear, they show up as blocks in our body and in our conversations and in our architectural decisions. You know, these these guys, these elephants in the rooms and these undiscussables in our working sessions, they are usually there because we do not want to feel these guys. fear, blame, judgment and resentment. And these emotional elephants in our architecture workshop, you know, they are ruling the decisions every single time. The only question is that do it visibly or invisibly, right? And, you know, Luxpair’s leadership um team they they they were keenly aware of the ambivalent emotions people had, um, you know, in their relationship with with AI. But I think it’s really not only Luxpair people, but we have all felt the FOMO in relation to AI, right? The confusion,

the cognitive overwhelm, right? Running really, really fast, as fast as cushions. And probably somewhere underneath, you know, also the shame of missing the good old days when I can a whole day, when I can I can spend a whole day on one design problem, right? Sketching on paper,

take a shower, and come back with clarity. Right? So these guys are also undiscussables. And they’re impacting our personal and architectural decisions in every company right now.

So, to do that, you know, their phones. Okay.

And so we’ve seen this image before, right? the war to hope being uh by the lack of under shared understanding. And now it is here again, in a different way by avoided emotions. The thing is that again, from neural science we know that when, you know, all our addictions and and and and lead to doom to doom scrolling to Facebook, right? It it we make decisions to avoid feeling certain emotions. So when the emotions don’t flow, decisions also don’t flow. Okay. Okay, get ready now, what’s something interesting that you do? Take your picture. I see a lot of there must be a lot of being experts. Who has heard of the Gamble Walk? Oh, this is the audience. Quite a lot. Okay. I I’m half well, I’m not half, I am uh Chinese, I’m born Chinese and Japanese is inherited from Chinese again the in Japanese. Uh and in Chinese. That’s the real place, right? In manufacturing that’s where value actually gets created, right? So when you do the gamba walk, you go see, you ask why, you show profound respect if you’re a manager, you’re managing not from status reports but from first-hand observations. And so, but when work is invisible in software, what you have to do the gemba walk in a different way. And that will be our conversations. where we can bring our difficulties, where we can negotiate our re-common those shared things and we can name these undiscussable. And that’s the word being socio-technical architecture.

And so, a philosopher wrote an autobiography called In My Own Way. And this title captures the

attention that I personally keeps returning to. If you have personal flow, right? You are doing things in your own way. You are keen, you are uninterrupted and you um you’re getting out of each other’s way. But when we have social flow, we’re creating something that nobody can create alone, right? So, But the catch 22 is that um, you know, doing things purely in my own way can get in my own way. Do you get that? So the personal flow and the social flow are not opposites to dissolve. It’s a tension that we we need to hold and celebrate and, you know, profit from. Um, and so, we have talked about emotions, but for questions, really, question um the what we experienced in that experiment is that the the workshop’s outcome was different because of the questions asked about Sam, about Claire, about Dave. And basically literally the questions asked changed what was to come next, right?

So it changed the future of the workshop. So I know you are kind of all overwhelmed and tired at the end of the talk. What are the first five letters in the word championship?

Yeah. So questions send us on a shared quest. Answers stop them. So imagine if we did what we did in the workshop is to, you know, give people the list of abilities and ask them to analyze the tradeoffs of and prioritize, the results would have been much different.

So questions are for me basically edit buttons for the future. And so, you know, but we have to believe that that is a possibility.

Uh, yeah, so this is a question that uh you can uh try on your own. What’s one question that you that would bring more flow to your work? Because if you if you are able to ask that question, you are actually rehearsing the future. It’s uh think about it in the age of AI, questions are, you know, answers are getting cheap, right? with depreciate us, is the question, the quality of the question. Anyway, here are the key points. Workflows, when and their standing flows. decouple the software, connect the people and questions and emotions are architecture materials. So this is the opening image for the talk. You might be wondering what is this? This is the Ubuntu philosophy, Southern African philosophy and open source philosophy. Anybody remember what this means?

Ubuntu.

Together.

Yeah. I am because we are. And so a person is a person through other people. So our ingenuity and our creativity co-arise with others in our shared gamble walk, right? In um in this socio technical dance between delivery flow and generative flow, right? So my last invite is of course to all of you, get more interested to become your in your own way a socio-technical architect. finding flow together as a committee.

That’s it. Thank you so much.

Okay, I’ve used up the whole hour, unfortunately, so, but I’m I’m going to be around and you can find me and have a have a chat if you want. Thank you very much for

your attention. Have a great conference.