A few years ago I was in Altyn-Arashan, an alpine valley a few hours from Karakol in Kyrgyzstan, soaking in a thermal bath after a long trek. The bathhouse is nothing. Wood planks, a concrete floor, a rusted pipe running straight from a natural spring into the pool. Forty to fifty degrees, rich in minerals, no design, no branding, no interface. Somebody just ran a pipe from where the hot water is to where people needed it.

Nobody photographs the pipe. Everybody depends on it.

I keep thinking about that pipe because of something that happened over eight years at Salesforce.

I spent eight years at Salesforce. Some of the best years of my career.

One of the things I’m most proud of is the work we did on the automation platform. Flow Builder, process automation, event-driven architecture, IoT Cloud. At the time it felt like plumbing. Important plumbing, but plumbing. Connecting data to action. Letting a business say “when this happens, do that” without writing code.

What I understand now is that we were building the foundation that makes Agentforce possible. And the same foundation is what made Claudeforce possible too. The partnership announced a few weeks ago brings Claude’s reasoning together with Salesforce’s data, workflows, business logic, and governance so an agent can take real action wherever people work. That’s not a coincidence. An AI agent can sit inside Salesforce and do something trustworthy because of the years of work that went into the layer underneath. The data model. The permissions engine. The workflow logic. Without that, Claude has nothing solid to work with.

I’m proud of that work. It aged well. Big kudos to the whole team, and to those of you still building the platform engine at Salesforce or Mulesoft.

The other thing I worked on at Salesforce was Lightning. The complete redesign of the UI and UX platform. New design system, new component model, new way of building applications on top of Salesforce. Every app in the ecosystem rebuilt around it. It was a massive effort, and it defined how people interacted with Salesforce for years.

It might continue to. But I find myself wondering for how much longer.

What the Interface Is Actually For

When Marc Benioff introduced Claudeforce, he said “the UI is the AI.” It’s a big thing for a company to say about its own product. It’s an admission of where the interaction layer is going.

When an agent can sit between a user and a system of record, find the right information, take the right action, and close the loop without the user ever opening an application, what is the designed UI for?

My answer: governance, configuration, and oversight. The screens become less where work happens and more where work is set up, reviewed, and controlled. That’s still valuable. But it’s a different kind of value than what enterprise software has been selling for the last twenty years.

The automation layer we built becomes more valuable in this world, not less. It’s what the agent depends on. The experience layer, the navigation, the designed screens, the way humans used to move through software to get things done, that is the part under pressure.

This Is Bigger Than One Company

Salesforce is not the only company facing this. I’ve watched the same dynamic at other large enterprise software organizations. ERP platforms, HR suites, finance tools, CRM systems built over decades. All of them share the same assumption: a human sits at a screen and moves through a designed experience to do their work.

That assumption is weakening. GPT-6 Astra, released ten days ago, is built not just to reason but to operate. It browses, it uses apps, it fills forms, it updates records, it works inside spreadsheets and document editors and professional software. Previous models told you how to do things. Astra is built to do them.

This is the direction. Not one model, not one partnership. Every major lab is moving toward agents that don’t advise the person at the keyboard but do the work directly. The interface in between becomes less necessary with every release.

The companies that understand this are asking the right questions. What do we own that an agent needs? Where is our data irreplaceable? What compliance and governance role do we play that a new entrant would take years to rebuild? What stays valuable when the UI and more of the workflow move somewhere else?

The ones leaning into that layer, the data, the permissions, the integrations, the trust built over years, have a real path forward. The ones still betting mainly on the interface are in a harder position. Not immediately, not catastrophically. But the direction is clear and the pace is picking up.

And we are going to see more deals like Claudeforce. The model labs need the data and the trust infrastructure that enterprise software companies spent decades building. The enterprise companies need the intelligence layer to stay relevant. Neither side can build what the other has quickly. More partnerships are coming, and each one will move a little more of the work out of the application and into the agent.

The Part That Doesn’t Change

The tools are moving fast. Agents are getting dramatically more capable. Astra can run multi-step professional workflows, produce finished documents, check its own work, and operate software end to end. That’s real.

But none of these tools know what to build or why. They don’t know which workflow matters to your customer and which one doesn’t. They don’t know what your compliance obligation means in practice, or which integration is quietly holding everything else together. That judgment is still human. And it’s getting more important, not less, because the implementation is getting easier and the decisions are getting more consequential.

The engineers and product people who do well from here are the ones who understand systems, not just codebases. Who decide what to build next instead of only executing what they’re told. Who stay engaged with what the AI is doing instead of accepting its output.

Two Platforms, One Lesson

I helped build two platforms at Salesforce. One was the plumbing nobody saw. The other was the interface everybody saw. I was proud of both, and at the time I would have told you the interface was the harder, more visible, more important achievement.

Eight years later, the plumbing is what agents run on. The interface is what agents are starting to replace.

The layer where work happens is moving. The foundation underneath is what lasts.

Based on these learnings, and while exploring and adapting to this new way of working and creating products, I’m building ARTEX, a living digital art platform, from Milan.

More at codame.com

For my last year of high school, I left Naples through the AFS exchange program and moved to Monticello, Iowa. Naples: 2 million people, noise, organized chaos. Monticello: population 3,000. Italian name, nothing remotely Italian about it.

I was 16, an exchange student. Across Iowa there were maybe 30 of us total: from Germany, Japan, Brazil, Finland, Thailand. I couldn’t really speak English at that point, and that didn’t stop me for a second. I communicated, joined in, showed up for everything. Plenty of things went over my head, got lost in translation, or were simply misunderstood. But I was learning constantly, and not just the language. We didn’t share a language, a culture, or any common frame of reference. What we did share was curiosity, openness, a willingness to figure it out, and a lot of smiles. None of us knew what to expect, but we all embraced it. I became as Iowan as I could, and at the same time learned more about Germany, Japan, Brazil, and Finland than I ever would have from a classroom.

What made it work wasn’t that we were tolerant of each other. It was that we were interested. You learn to listen differently when you know your interpretation is probably missing something. You stay flexible because your default assumptions keep getting challenged. You develop empathy not as a concept but as a reflex, because it’s the only thing that gets you to the other person. When someone approaches a problem in a way that makes no sense to you, the useful question isn’t “why would they do that?” It’s “what do they know that I don’t?” At 16, before you’ve settled into a fixed way of seeing things, that instinct can take root. I got lucky that it happened to me then.

Those people are still in my life. Some of them were at my wedding in Turkey, and again when we celebrated a second time in Italy. That year in Iowa is where I got my real education in what it means to work with people who think differently than you. Everything after that was practice.

The Career That Followed

I didn’t travel internationally for work. I lived internationally for work. There’s a difference.

Italian in France, building systems for airports and the European Space Agency. A computer science degree in London, then my first lead engineering role in England, building interactive television before most people knew what that was. US companies in Germany. German companies in the US. International teams in Australia, where I also went back to school for a master’s. Fifteen years in San Francisco building products in Silicon Valley. Every single product I’ve worked on has been used across multiple markets. Every team I’ve led or been part of has been multicultural by default, not by design.

My marriage is multicultural. My kids were born in different countries. I’ve learned languages not because I had to but because I wanted to understand the people and places I was living in.

Now I’m back in Europe, based in Milan. Milan is more international than I expected. It’s the most international city in the country by a significant margin, and it’s moving fast. That matters for what I’m building now.

What You Gain

The obvious argument for diverse teams is that diversity is a value. It is. But that’s not why it works. When everyone in the room has the same background and the same mental model, you have a systemic blind spot, and nobody inside the room can see it. One person from a different context asking “wait, why do we do it this way?” is worth more than a full sprint of internal review. I’ve seen this play out too many times to call it a coincidence.

It shows up in the product. Users in different markets don’t just speak different languages. They have different relationships with technology, different trust patterns, different expectations about what software should do for them. If your team doesn’t look like your users, you’re guessing, and when you’re guessing at scale the cost is real. The same teams also build software that’s harder to break. Date formats, character sets, right-to-left layouts, local payment rails, GDPR versus CCPA, how phone number validation works in Brazil versus Japan. A monoculture team discovers these in production. An international team has already broken the product in their heads across a dozen contexts before anyone writes a line of code.

Then there’s what distance does to how a team communicates. When you can’t tap someone on the shoulder, you write things down. Decisions get written up. Context gets shared in writing. Specs get clearer. This feels like overhead until you realize it’s the thing that scales. And right now it matters more than it ever has. AI tools work directly with your documentation, your codebase, your written context. A team that already communicates in writing has a structural advantage. The discipline international teams develop out of necessity is exactly what makes them ready for how work is changing.

Time zones belong here too, even though everyone files them under problems. Yes, someone is always at a bad hour. But a team spread across time zones can run nearly continuously: a bug filed in San Francisco at 5pm is picked up in Milan at 9am and resolved before the SF team wakes up. Follow-the-sun support, development cycles that don’t stop. It takes tight handoff discipline to unlock, but the teams that figure it out move faster than co-located ones.

And your talent pool stops being one city’s job market. The best person for a role might be in Warsaw, Nairobi, or Buenos Aires. If you’ve built the culture and systems to work internationally, you can hire them. If you haven’t, you’re competing with every other company for the same local pool.

What Breaks

I’m not going to pretend this is easy. And I’m not going to give you the obvious list.

Start with the mistake I see companies make repeatedly. They translate the UI, adjust the currency format, maybe hire one local sales rep, and call it international. Then they wonder why it’s not working. Going international is not a localization task. It means understanding a market from the inside: how decisions get made, how relationships are built, what “good customer support” means in that context. That knowledge doesn’t come from a market research deck. It comes from people.

The deeper problem is that HQ culture becomes the default culture, whether you intend it or not. When the company is headquartered in one country, that country’s way of working quietly becomes the standard. Meetings run in HQ time. Career paths are visible from HQ. “How we do things” is really “how we do things in San Francisco” or “how we do things in Berlin.” The international offices feel it. They adapt to survive. And over time, you lose exactly the diversity of perspective you hired them for. I’ve been on both sides of this: the one adapting, and the one setting the culture. You have to fight it on purpose, and keep fighting it, because the default always wins when nobody is paying attention.

Part of what collides is speed. German engineering culture values thoroughness, documentation, and consensus before moving. US startup culture values speed, iteration, and deciding with 60% of the information. Japanese teams build consensus before the meeting even starts. None of these is wrong. But when they meet without anyone naming the difference, the American team thinks the German team is slow and risk-averse, and the German team thinks the Americans are reckless and chaotic. The frustration is real on both sides, and it’s almost never about the decision. It’s about the process.

Feedback collides the same way. In the Netherlands, Israel, or Germany, direct critical feedback is normal and expected, a sign of respect. In many Asian cultures, a public “no” or explicit criticism in a group setting is something to be avoided at almost any cost. This creates a kind of miscommunication that’s hard to catch: a team member signals disagreement clearly, just not in a way the rest of the room is calibrated to read. The signal gets missed. The decision goes through. Later you find out the concern was valid. The cost isn’t that one decision. It’s the erosion of trust in a team that never figured out how to hear each other.

Language does something similar, quietly. When a company runs in English, the people most confident in English drive the conversations, in meetings, in Slack, in documents. That confidence gets misread as competence or seniority. The person who needs a moment to find the right word gets talked over. The idea that takes two sentences in French takes five in English and lands differently. Over time, non-native speakers communicate less, contribute less visibly, and get passed over, not because they have less to offer, but because the medium doesn’t serve them. Companies that don’t design around this lose people. I’ve felt it from the other direction too. I still think about the years when the most interesting engineering and research papers were coming out of Germany, and I couldn’t read them as fluidly as I would have liked. Language is not just communication. It’s access to knowledge, to networks, to how people in a given place think about problems.

Distance compounds it. Promotions, the interesting projects, the moments that build a career, they flow disproportionately to people who are physically near leadership. Remote and international employees, even exceptional ones, are systematically less visible. And the same time zones I just called an advantage become a pressure when nobody designs the rotation: someone is always on a call at an inconvenient hour, and it’s usually the same someone, the one furthest from HQ. Neither of these shows up in a dashboard until people start leaving.

Underneath all of it, trust across distance and difference takes longer to build. That year in Iowa where a group of teenagers from completely different backgrounds figured each other out, that happened because we had time and proximity. In a distributed global team, you don’t get that for free. You have to engineer it.

Part of engineering it is accepting that some things don’t happen over a video call. A team dinner. A walk around a neighborhood you’ve never been to. Eating something unfamiliar with someone whose city you’re visiting for the first time. This isn’t team-building overhead. It’s the work. I’ve made a point of visiting the places I work with, not just for meetings, but to spend real time there. Meet people in their environment. Sit at their table. See how they live. The trust that comes from having been in someone’s city, even once, is different from what you build over months of messages. Both matter. But you can’t get to the second without at least some of the first.

Where We Are Now

The tools are better than they’ve ever been. Engineering and digital work have compressed geography in ways that weren’t possible even ten years ago. Collaboration tools, async-first workflows, shared codebases across time zones. A lot of the old friction is gone.

AI is accelerating this further. The gap between building for one market and building for many is closing. Translation is better. Documentation is more accessible. The surface area a small team can cover internationally is larger than it’s ever been.

But here’s what hasn’t changed: you still need people who understand different markets from the inside. The judgment that comes from having lived somewhere, worked somewhere, failed at something somewhere different from where you grew up, that doesn’t get automated. That’s still a human thing. And teams with that depth have a real edge over teams that don’t.

We’re more connected than we’ve ever been. We’re also still different from each other, in how we think, what we value, what we expect. That’s not a problem to solve. It’s the whole point.

The photos I’m posting with this are from that year in Iowa. Most of those people are still in my life. If you want to understand why I think multicultural teams work, it starts there.

We accepted the distance because it was the price of scale. One person can only type so much, review so much, sit in so many rooms. So we built layers, and the layers did their job, and slowly we became readers of reports about a thing we used to touch with our hands.

For me, the way to fight that distance was always people. Staying in contact with the team at every level, listening to engineers, designers, new joiners. That has always been my way of working and collaborating, and it kept me in touch with reality when reports and dashboards could not. But even the best conversations are still a window into the work, not the work itself.

And the human factor has become even more relevant now. More critical, more important than before. When machines produce the volume, it’s the people who carry the meaning. The judgment, the trust, the taste for what is worth building. Staying close to your teams matters more than it ever did. What changed is that we can now also stay close to the work itself.

That deal just changed.

The distance was a cost, and the cost moved

The reason we stepped back was never that our judgment stopped mattering at the level of the code, the design, the architecture. We stepped back because our time was the most expensive thing in the building, and typing was slow, and reviewing everything was impossible.

AI tools changed the economics of that. Building ARTEX, I can now sit with the actual system, probe it, ask questions of it, sketch an alternative architecture and see it take shape in an afternoon. What used to take me a week of borrowed engineering time takes a conversation. These tools do more than make engineers faster. They shorten the distance between a CTO and the product itself.

This is an invitation, and most of us haven’t opened it yet. You can be close to the product again. Close to the design. Close to the architecture. And you can do it without becoming a bottleneck or taking work away from your teams. Close enough to see clearly what’s really happening, beyond the hype and beyond the doubts.

One thing I want to be clear about, because it shapes everything else. Being closer to the work does not mean taking control back. At Salesforce, trust is the number one value, and after my years there it became part of my DNA as a leader. Getting close to the product only works if your teams know you’re there as a partner, not an inspector. Empowerment matters more in this new world, not less. When context is the fuel and judgment lives everywhere in the team, the leaders who trust and empower their people will always outrun the ones who pull decisions back to the top.

Your experience just became exponential

I expected decades of experience to matter less in this new world. The opposite happened.

When generating code is cheap, everything you’ve learned about what makes systems fail, what makes teams work, what correct actually means in your business, becomes the scarce resource. The machine produces volume. You provide the judgment that sorts it. Every hard lesson you accumulated, every incident you owned, every architecture you regretted, all of that carries over. And because it now gets applied across far more output, it compounds.

What survives is what someone has to sign. As CTOs, we have been signing for years, and we know the weight of it. That skill was always the core of the job. Now it’s almost the whole job.

And yet, think like a kid

Experience compounds only if you keep learning. I have watched people use their twenty years to explain why the new way won’t work. Those twenty years turn into a liability.

Not everything is sorted out. Nobody has solved the junior pipeline. Nobody really knows how much faster we are, versus how much faster we feel. The metrics we trusted are now actively misleading. The ways teams work together are being redrawn in real time, and anyone who claims to have the final answer is selling something.

So the posture that works, I think, is a strange combination. Carry your experience like a compass, and approach the terrain like a kid. Curious. Open. Willing to be wrong in public. Willing to sit down with a tool and be a beginner again, in front of your own team. That last part is uncomfortable. It’s also, I believe, the most powerful signal a technology leader can send right now.

The opportunity

Smaller loops. Fewer layers. Context shared deliberately instead of filtered by default. Teams that are trusted and empowered to own their decisions. Leaders who can touch the product again, guided by everything they’ve learned, humble about everything they haven’t.

The org chart will catch up eventually. It always does, late. What you can change today is your own distance from the work. Close it. Sit with the product. Ask it questions. Bring your scars and your curiosity in equal measure.

The best part of this job was always building. We finally get to do it again.

I think about this shape a lot lately, because I see it everywhere in how we build things, and in how we build careers.

No engineer, no leader, no team is complete on their own. We are all looking for the ring that closes our gate. A mentor. A team. A tool. A company that finally lets us do the work we always knew we could do. And here is the part that took me years to really see: the same mechanism that completes you can also be the thing that traps you. The hook does not know the difference. It just closes.

The good kind of incastro

I have spent years as an engineering leader, building products and teams long before AI entered the picture. More recently, on a new project called ARTEX, I have gone deep on AI coding tools like Cursor, Codex, Antigravity, GitHub Copilot, Claude Code. Each one has its own strengths, its own blind spots. None of them replace the engineer. What they do is close a gap that used to take a small army to close. Suddenly one person with a clear mental model can move at a pace that used to require a team of ten.

That is a hook finding its ring in the best possible way. The tool gives you speed and reach. You give the tool judgment and taste. Neither piece is enough alone. The AI cannot tell you if the architecture is right, if the direction serves the product, if this is the version worth shipping. You cannot type fast enough to build it all by hand anymore, not at the pace the market now expects. Put together, something holds that neither could hold alone.

The same is true of a good team, or a good mentor. When it works, you come out of the relationship more capable, not less. You borrow their pattern recognition for a while, and eventually it becomes yours. The good incastro, the good interlock, always lets go when it is done its job. It leaves you bigger than it found you.

The kind that quietly takes over

But the same shape can close the wrong way, and from the outside it looks almost identical at first.

I have watched engineers let a tool make architecture decisions nobody is really reviewing, not because the tool is bad, but because they got attached to it. The suggestion came fast, it looked clean, it shipped, and somewhere in there the human stopped asking if it was actually right for the product or the business. That is the real failure. It is never the tool. A tool has no opinion about your product, your users, or your company. The moment we let our attachment to a tool, a process, or a way of working make the call for us, we have handed over the one thing that was never the tool’s job to hold.

I have seen leaders build teams that cannot function without them in every room, and call it good management, when really it is a dependency dressed up as leadership. I have seen people cling to one company, one title, one identity, long after it stopped fitting, because letting go felt like losing a part of themselves.

The test is simple, even if living it is not: after the good interlock, you feel more capable. After the bad one, you feel smaller, and a little more stuck than before. Craft that leans on a tool still grows. Craft that gets replaced by attachment to a tool quietly disappears, and you often do not notice until someone asks you a question you can no longer answer without it.

What holds, and what just closes

This is why context, critical thinking, and curiosity matter more now, not less. As these tools get better at closing gaps for us, the real differentiator stops being who has access to the sharpest tool. Everyone will have access. It becomes who still has the judgment to catch the moment attachment starts making the call instead of them.

It is never the tool’s fault, and it is never really about the tool at all. What makes the right call on architecture, on product, on the business, is the same thing it always was: critical thinking, awareness of what you are actually building and for whom, curiosity to keep questioning your own choices, and staying open enough to change course when the evidence says you should. The tool can carry you fast in a direction. Only you can tell if it is the right one.

The accumulated experience, the principles you have built over years of shipping real things with real teams, does not shrink in value as AI gets stronger. It becomes exactly the thing that decides whether a fast tool is being used well or badly. Collaboration matters more too, not less, because a team that thinks together, openly and critically, catches the bad interlock faster than any one person alone.

None of this is a reason to slow down or hold the tools at arm’s length. It is a reason to stay awake while you use them. Build the habit of asking, every so often: am I making this call, or is my attachment to the tool making it for me.

The gate is always going to want to close on something. The work of a career is learning to tell the difference between the ring that lets you go when you are ready, and the one that never planned to. Get that right with a tool, and you have gotten it right with almost everything else that ever tries to complete you.

I’ve been deep in the trenches with AI coding tools lately, building ARTEX, a space for living art across experiences and collections. Art that lives, responds, and evolves. Cursor, Codex, Antigravity, GitHub Copilot, Claude Code. Each has its quirks, its strengths, its blind spots. And each is genuinely powerful on its own, plugging into the wider ecosystems of tools you already use across your workflow and with your team.

But here’s what I keep coming back to: tools alone aren’t enough.

As AI builds your software, you still have to be the engineer. You need a sharp mental model of what it’s actually doing under the hood. You need the instinct to redirect it when it drifts. You have to be an active architect, not a passive approver, of the system taking shape. And you have to develop something almost like intuition: forming suspicions, then probing and experimenting to verify them. All without drowning in exhaustive code reviews.

Three things matter more than any tool

Context is king. The quality of what AI produces is almost entirely a function of how well you frame the problem. Garbage in, garbage out. But with AI, it’s subtler than that. Vague in, plausible-sounding garbage out.

Critical thinking is irreplaceable. AI can execute brilliantly. It cannot judge whether it should.

Curiosity is the engine. It’s what pushes you to probe deeper, question the output, experiment when something feels off. Without it, you’re just accepting. With it, you’re actually engineering.

It’s no longer just about writing code

What’s also shifted is the scope of what these tools touch. The same mindset now extends to design, delivery, marketing, finances, business models, the full arc of building a product and running a business. That’s extraordinary. But it also means the bar for everything has risen.

When it’s easier for everyone to build, being different becomes the new hard. Quality, trust, speed, and genuine creativity are the real differentiators now.

And none of what I learned over the years got left behind. The values, the principles, the best practices built up through experience across teams, industries, and cultures. All of it still holds. More than holds, actually. It’s exponentially more relevant now. The fundamentals don’t disappear when the tools get smarter. They become the foundation everything else is built on.

Your team is still the multiplier

And your team? More important than ever. You can move further alone or in a small group than ever before, but the people you think alongside, debate with, and build with remain the multiplier that no tool can replicate.

The work isn’t shrinking, it’s expanding into new dimensions. More complexity, more factors to juggle, more to navigate. But with the right mindset, that’s not a burden. It’s what makes this moment fascinating, fun, and genuinely rewarding.

We should all be a little more artist

And that’s why I believe artists have all the ingredients to thrive in this new renaissance. Not artists as a profession, but as a mindset and a way of moving through the world.

Think about what makes a great artist. They obsess over their craft. They question their own work before anyone else does. They see what others walk past. They feel the difference between something that’s finished and something that’s truly done. They take risks, stay curious, and refuse to copy what already exists. Now read that back and tell me that isn’t exactly the mindset this moment is asking for.

Curiosity, discipline, originality, the courage to be different and the humility to keep learning. No tool teaches you that. No model gives it to you. It’s built through experience, through failure, through the people you meet and the places life takes you. And right now, in this moment where the barriers to building have never been lower, that human depth is the thing that actually sets you apart.

We should all be a little more artist.

Driven, curious, and aware. That’s the discipline. That’s the culture.

That is what CODAME has always represented to me. Not content. Not branding. Not just events. A real community, one I’d want you to experience for yourself.

A place where experimentation is not an accessory, but the point. Where art and technology are not treated as separate categories, but as parts of the same cultural force.

A place where people can make things before they are easy to explain. And maybe you’ve felt this too, that urge to explore something before it fully makes sense.

I think spaces like this matter more now than ever. Because we are entering a future shaped by AI, automation, platforms, and systems that can scale faster than our ability to ask what they are doing to us, to culture, to meaning, to each other.

In that kind of future, community is not a nice-to-have. It is infrastructure.

We need places where people can gather across disciplines. Where ideas can be tested in public. Where technology is not only optimized, but questioned. Where art is not decoration added at the end, but part of how we think. Where new possibilities can emerge through collaboration, friction, intuition, and play.

Places where you can step in, not just watch from the outside.

That is one of the reasons I believe so deeply in CODAME.

Because CODAME creates the conditions for that to happen. Not by pretending to know the future. But by making space for people, people like you, to imagine it together.

And that is also why I’m excited about what we are opening in Milan.

On April 24, during Design Week, we are bringing The New Human to life, not as a finished answer, but as something I’ve been personally searching for.

And something I’d genuinely love to share with you, in person.

A space where art, technology, and people don’t just coexist, but actually meet. Where you don’t just observe, but feel part of it. Where you can move through it, interact with it, play with it, and see what it gives back.

The New Human begins its journey in Milan, then continues to San Francisco, Berlin, and Shanghai.

Because no single place, no single perspective, is enough to imagine what comes next.

It only starts to make sense when it moves. When it’s shaped by different people, different cultures, different ways of seeing the world.

If you are in Milan, or know someone who should be there, I’d love for you to come experience this with me.

To share a moment. To feel something. To explore. To play. To be part of it, not just around it.

Join me

The future does not only arrive.

Sometimes, it gathers.

My daughter is graduating this year from San José State University, and I could not be more proud.

From a very early age, she knew what she loved: telling stories, drawing worlds, creating characters, and bringing emotion to life through art. What surprised me most was how certain she was when she chose SJSU. She knew the department, the school, and what she wanted to do with her life.

I was skeptical, not because I doubted her talent, but because that kind of clarity is rare at such a young age.

Over time, she proved it was real.

She stayed true to herself, to her craft, and to the stories she wanted to tell. Today, seeing her graduate and help bring a project like To Turn a Tide into the world feels incredibly special.

When change feels impossible, what inspires someone to become the change themselves?

Sometimes the answer begins with something small: a memory, a story, a moment that refuses to fade.

For Sofi, part of that inspiration comes from a memory we share.

At the center of it is a memory I still carry very clearly: collecting clams as a child to bring home to my mother, and then cooking them together. I remember how proud that made me feel. I remember how good they tasted, how simple and beautiful that moment was, and how something so small could hold so much love.

And now, to see my daughter bring those memories back to life through her own art moves me deeply.

There is another part of this story too. Over the years, those clams disappeared. Pollution, neglect, and the ways we have too often failed to care for the environment damaged that little world. Nature faded, and with it, those beautiful and delicious moments that once felt so abundant.

But the good news is: they are coming back.

Maybe not in the same numbers as when I was a child, but they are returning. And to me, that feels like hope, the kind of hope that inspires someone to imagine a different future and, sometimes, to become part of the change themselves.

That is part of why this project touches me so much. It is not only about memory. It is about what we lose, what we carry, what we repair, and what can return.

To Turn a Tide, pitched for SJSU’s BFA 2026 program, is more than a comic anthology. It is rooted in family memory, in generational experience, and in the hope of breaking difficult cycles. Sofi helped shape the overall creative vision, led a team of fellow students, and brought the guiding story to life with both talent and heart.

She has also been a dedicated advocate for community and representation, serving the SJSU WIA Student Collective first as Graphic Designer and then as President.

I am proud of her talent, her discipline, her leadership, and above all, the heart she brings into what she creates.

Watching her grow into herself, with such clarity, care, and creative force, has been one of the greatest joys of my life.

Seeing her turn family memory into art, pain into meaning, and the possibility of return into story makes me even more proud.

If you would like to support the project, here is the Kickstarter:
https://www.kickstarter.com/projects/1091924088/to-turn-a-tide

Back this Project

My time as CTO at TeamSystem has come to a natural close.

When I joined, the objective was clear: strengthen the engineering organization, modernize the platform, and help prepare the company for its next phase of growth. Over the past years, we scaled the engineering teams, improved delivery reliability, advanced the transition toward cloud-based systems, and built a stronger technical and leadership foundation that will continue to support the company going forward.

This kind of progress is always the result of teams working together over time, solving problems step by step, and staying focused on a shared direction. I’m grateful to everyone I had the opportunity to work with and to what we achieved together.

When a cycle completes, it creates space to step back and look carefully at what matters next.

For now, I’m choosing to use that time deliberately.

I’m dedicating time to celebrating and reconnecting with family, friends, and CODAME—the ART+TECH community I care deeply about and that continues to inspire me. We are often busy building and moving forward, and it’s important to find time to reconnect with the people and environments that give direction and meaning to what we do.

This year, CODAME is exploring a theme called The New Human, reflecting the changes we are experiencing as technology becomes more capable and accessible. I’ll be participating directly in the Creative Hackathon in March as a builder. I’m excited to have the time to build again, to experiment, and to learn through making alongside artists, engineers, and creators. It’s a rare opportunity to step back into the process itself and rediscover what emerges from curiosity and collaboration.

This is also an important moment for my family. My three children are entering new stages of independence—one starting university, another finishing this summer, and the first preparing to graduate. These transitions happen only once, and I want to be fully present for them.

And for my wife, the love of my life, who has been beside me through every step of this journey. This time is also for us—for the conversations, the quiet moments, and the shared future we continue to build together.

Technology will continue to evolve quickly, creating new possibilities and new responsibilities. The fundamentals, however, remain the same. Progress depends on people who understand systems deeply, who take responsibility for what they build, and who stay focused on long-term outcomes.

I’m proud of what we accomplished at TeamSystem. I’m taking this time to reconnect, to build, and to prepare for the next chapter.

The work continues.

Code wasn’t always meant to be read.

Before elegant syntax and abstractions, there was assembler. And before that, raw instructions spoken directly to hardware. Early programming wasn’t a shared language between people. It was a negotiation with machines. If we wanted something to happen, we had to bend our thinking to match theirs.

High-level languages changed that. They were an act of empathy, not for the machine but for us. As systems grew more complex, readability became essential. Code became something we could explain, review, and reason about together.

For decades, the primary reader of software was another human.

The New Reader

Now, a new reader has entered the room.

Large language models don’t just execute code. They read it, rewrite it, explain it, and increasingly maintain it. And they read differently than we do. Where humans rely on context, convention, and tribal knowledge, models rely on what is explicitly present.

They don’t fill gaps gracefully. They don’t assume intent unless it is stated.

That creates tension. Many features we value, like implicit behavior, dynamic patterns, metaprogramming, and subtle conventions, can confuse models operating with partial context. We can hold a mental map of an entire architecture, but models operate in windows. If intent is not local and explicit, the model hallucinates a bridge to nowhere.

Where we infer, LLMs must guess.

This is why explicitness, strong typing, and formal contracts are resurging. Languages like Rust or strictly typed TypeScript are not only safer for teams. They are easier for models to reason about. When a new kind of reader joins the conversation, clarity becomes a different kind of necessity.

From Implementation to Intent

This shift changes what programming actually is.

Historically, programming meant telling machines how to do things, step by step, line by line. But LLMs are increasingly capable of determining the how, as long as we are precise about the what.

Our focus moves from implementation to intent.

In this world, the most important thing we write may not be an algorithm, but a clear expression of outcomes, constraints, and assumptions. Tests become more than safety nets. They become executable intent. Documentation stops being an artifact and becomes part of the system.

Not free-form natural language, and not rigid code either. Instead, something in between. A structured, constrained way of saying this is what we want, this is what matters, this must never break.

The Contract Language

It is not hard to imagine what comes next.

We can picture a language where a service is not defined by its control flow, but by its guarantees. A module begins not with imports, but with declared intent. What it is responsible for, what constraints it must respect, and what “correct” means in observable terms.

We can imagine a function body with no logic. Only a strict return schema and a detailed contract, where the compiler is a model resolving the implementation at runtime.

Such a language would not look like Python or Rust. It would read closer to a formalized contract written in constrained natural language, backed by executable specifications and verification hooks. We define the space of valid behavior. The machine explores it.

The Architecture of Intent

This raises a practical question. When the machine writes the implementation, what do we actually read? And how do we debug it?

The codebase splits into two layers: the Source and the Artifact.

The Source is what we touch. It looks less like a recipe and more like a legal agreement fused with a test suite. It is concise, high-level, and explicit about what must happen.

The Artifact is what the model generates. It is verbose, defensive, and heavily instrumented code, perhaps in Python or WebAssembly, that actually runs. We will rarely inspect it, just as we rarely debug assembly unless we are desperate.

Debugging shifts from inspecting state to inspecting reasoning.

When a bug occurs, for example a payment is approved when it should be declined, the code will likely be syntactically perfect. Instead of stepping through lines, we examine a Decision Trace: observed user flag, referenced policy, overridden constraint based on ambiguous precedent.

The bug is not in syntax. It is in ambiguity. We do not fix it by editing generated code. We fix it by tightening the Source contract.

The Death of Refactoring

This separation implies the end of refactoring as we know it.

Today, code is an asset we polish and maintain. In this future, implementation code becomes disposable.

To optimize a module, we do not rewrite functions. We adjust constraints in the Source and regenerate the Artifact. Throwing away ten thousand lines of code costs nothing. Technical debt in implementation disappears. Intent debt remains, in the form of imprecise definitions that no longer match reality.

Our tools will need to evolve. A traditional git diff becomes meaningless when a tiny change rewrites an entire file. We will need version control for meaning, not text. The pull request of the future will not ask us to review code. It will ask us to review simulations of intent.

The Human Shift

Our roles will change as quickly as the tools.

For decades, a Senior Engineer was someone who knew the deep corners of a standard library. That skill is depreciating. The new Senior Engineer is an ambiguity hunter.

Their strength is not syntax. It is systems thinking. They spot the edge cases a model would misinterpret. They express complex systems in constraints so tight that misunderstanding becomes impossible.

Security shifts as well. Vulnerabilities will not only be buffer overflows. They will be psychological. Attackers will not break the stack. They will try to persuade the model to ignore its constraints. Security becomes adversarial semantics.

The Prediction

I predict that within the next few years, languages designed explicitly for collaboration between humans and LLMs will emerge. Most will fail. One or two will quietly succeed, and they will redefine what good code means. It will become less implicit, more explicit, and more intent driven.

These are only a few of the changes LLMs will bring to the software development lifecycle. From design to testing, deployment, and maintenance, nearly every stage will be affected as models participate in reading, generating, and maintaining code. The examples we discuss here illustrate the broader transformation, but the full impact is likely to be much wider and still emerging.

This will not happen only because such languages suit machines. It will happen because incentives align. Vendors gain tighter integration and lock in. Developers gain predictability and a shared vocabulary for human-machine collaboration.

Assembler gave way to C. C gave way to Python. Python may give way to something that looks less like a language and more like a contract, a shared understanding between humans and machines.

This change will not arrive with fireworks. It will arrive as relief, as clarity, as a system that simply works alongside us.

Only later will we realize that we have crossed a line. We will have moved from programming machines directly to programming intent in systems that think with us.

Whether thinking as an engineer, a CTO, or a founder, one theme stayed constant: the systems we shape quietly shape us back.

In AI 2027, I explored a trajectory that’s moving from speculative to tangible: AI not just as assistant, but as autonomous agent. We’re beginning to see these glimpses now, tools that generate code, chain actions, and navigate loosely defined tasks.

We are, after all, actively building the future right now. The only question is: will we build it wisely?

That theme continued in The Future of Enterprise Software, where I argued that software is no longer just a tool we use to do work, it increasingly is the work. Our interfaces, workflows, and platforms have become the execution layer.

Software is no longer just tools, it’s becoming the work itself.

This shift raised deeper architectural questions. In Choosing the Right Architecture, I shared how data and events offer distinct but complementary strengthsand how designing for change requires systems that are not just scalable, but legible. In Rethinking Systems: What MCP Means, I looked at coordination patterns for multi-agent environments and what new kinds of context-aware infrastructure might enable.

Inter-agent context is the new interface.

But not all the questions were technical. The Hackathon Effect reminded me that momentum often begins with permission: to explore, to prototype, to move without over-justifying. Sometimes the greatest constraint is the absence of one.

They stop talking about innovation, and actually experience it.

In Unlocking Creativity in Your Software Team, I explored the quieter blockers that stifle teams, uncertainty, over-editing, loss of purpose, and how reintroducing clarity can restore flow.

Leadership, I realized, isn’t confined to job titles. It shows up in the architecture of decisions. In Protect the Purpose, Evolve the Rest, I argued that strong systems aren’t rigid, they’re anchored. Purpose offers the clarity that everything else builds around.

Protect the purpose. Evolve the rest.

And in Leading with Conscious Awareness, I reflected on how awareness, not speed, not certainty, is what gives us leverage in complex environments. The ability to pause, to observe without judgment, and to respond with clarity.

Awareness is what gives us range.

Looking back, the unifying thread wasn’t prediction or control. It was intentionality. The willingness to meet complexity with attention, and to design systems that scale without unraveling.

What’s next in 2026?

I won’t pretend to have predictions. What I do have is a commitment to paying attention, to staying curious, open, and anchored in the questions that matter.

2026 will ask us to be more adaptive, more aware of edges and boundaries, and more deliberate about how we use our tools. It will reward those who stay grounded, yet open. Who listen well, reflect often, and act with care.

I remain optimistic about what’s ahead. Not because it will be easy, but because I believe we can meet change with clarity and design it into something worthwhile.

Thanks for reading. Here’s to building systems, and organizations, that are worthy of our trust.

What signals are you paying attention to as we head into the new year?

Change isn’t coming; it is already here. In a world where intelligence is limitless and speed is the new gravity, the only real advantage is our willingness to evolve.

We are living in an age of unmetered intelligence.

Ideas move faster than infrastructure. Creation is no longer limited by access, tools, or time. The boundaries between human intuition and machine reasoning are dissolving, revealing new territory where possibility expands faster than certainty.

With that acceleration comes instability, but instability is not a flaw. It is the advantage of this era.

I learned this through years of working across emerging technology, design, and art, including founding a startup where every project felt like a prototype and every collaboration a living experiment. Nothing stayed the same for long. Formats shifted, tools evolved, expectations changed as soon as they were understood. Yet something deeper remained constant: the intention behind the work.

Experimentation became less of a method and more of a worldview.

A belief that transformation is not an interruption but a signal.

A reminder that evolution is the natural state of creative systems.

Over time, I realized that the world we were designing for was changing faster than the structures we relied on. Old models felt too rigid. Traditional frameworks couldn’t keep pace with possibility. So I stopped trying to protect the forms and began focusing on the purpose behind them instead.

With the rapid acceleration of artificial intelligence, social shifts, and fast consumption cycles, this pressure now feels exponential.

Purpose is what makes reinvention coherent.

It is what turns disruption into direction.

Across fields, whether a platform refining how we connect or an artist reinventing a creative process for the twentieth time, the same truth appears: those who thrive are not preserving what worked yesterday, but creating space for what wants to emerge now.

Nostalgia comforts, but it also constrains.

Progress asks different questions:

Not “How do we maintain this?”

But “What can this become?”

Design becomes orchestration. Tools, ideas, and collaborators become instruments that tune themselves to a shifting world. Disruption becomes an invitation to re-examine what truly matters. Each shift becomes a return to clarity.

Purpose is the anchor. Everything else is meant to evolve.

Strategies, tools, and structures must remain fluid. Authenticity becomes the compass. In a world overflowing with intelligence and shrinking attention, coherence becomes the strongest signal we have.

Among many others, this is why I am excited about this year’s Festival and its theme, The New Human.

As part of the Festival, at the Creative Hackathon, we are invited to build something that honors how we change. Not a static artifact of the past, but a living reminder of growth. Not a fixed representation, but a quiet companion to our evolution.

True evolution does not erase what came before; it sharpens it.

When we let change guide us rather than scare us, we create work that grows with us instead of aging behind us.

Hold your purpose tightly and your form lightly.

Recently, I have been reading The 15 Commitments of Conscious Leadership by Jim Dethmer, Diana Chapman, and Kaley Warner Klemp, and these are the reflections it sparked for me.

I am far from mastering these commitments, but they have become guideposts that help me navigate complexity with greater clarity and humility.

Here are a few that have been especially meaningful lately:

1. Radical Responsibility

Big companies have structure.
Startups have chaos.
The ART+TECH community has its beautiful unpredictability.

It is easy to blame external conditions.
This commitment invites a different stance:

Instead of asking, “Why is this happening to us?” try asking, “How am I creating or allowing this?”

It does not solve everything, but it opens a constructive way forward.

2. Curiosity Over Being Right

When pressure rises, curiosity is often the first thing to disappear, yet it is essential for innovation.

The ART+TECH community thrives on curiosity as we explore new ways for artists to bring their work to life.
Startups depend on curiosity to avoid false certainty.
Large teams benefit when curiosity softens rigid thinking.

Being right closes doors.
Being curious opens them.

3. Feeling Feelings (Even at Work)

As an engineer, I have always valued logic, and I still do. Logic is foundational to everything we build.

But the book reminded me that teams rarely struggle because of technical challenges. They struggle because of the emotions around those challenges. Bringing some of the ART+TECH community’s emotional openness into my corporate life has strengthened collaboration.

Emotions are not the opposite of logic.
They are part of the data.

4. Speaking Candidly and Eliminating Gossip

This is a daily practice, not an instant skill.

Speaking directly is uncomfortable.
Resisting gossip is uncomfortable.
But both create trust, clarity, and momentum.

As the authors emphasize, clarity is kindness.
I highly value this one.

5. Living in Integrity

Integrity, as described in the book, is not about perfection. It is about alignment.

For me, this means keeping commitments when possible and being honest early when I need to renegotiate. It means fewer automatic yeses and more intentional ones.

Less heroic effort.
More grounded clarity.

6. Sourcing Approval, Control, and Security Internally

This is one of the most humbling commitments.

In corporate environments, worth is often tied to performance.
In startups, to speed.
In the ART+TECH community, to creativity and experimentation.

But when approval or stability come only from external signals, fear takes the lead. Building internal steadiness, even slowly, changes how I show up for others.

Most likely, it is a lifelong practice.

7. Play and Rest

Simple to understand.
Hard to embody.

The ART+TECH community reminds me that play fuels creativity.
Startup life reminds me that rest prevents burnout.
Corporate work reminds me that neither happens unless it is intentionally protected.

Play is not frivolous.
Rest is not a reward.
Together, they create resilience.

Why I Am Sharing This

We are all navigating massive shifts: AI, distributed teams, new expectations, and new pressures. Technical leadership used to be mostly about architecture and execution. Now it requires emotional intelligence, communication, and staying present under uncertainty.

The 15 Commitments of Conscious Leadership has given me a more grounded way to lead, imperfectly but more consciously.

It has helped me:

• reduce unnecessary pressure

• avoid drama

• communicate with greater clarity

• support healthier team dynamics

• stay aligned with what matters

• create more space for creativity, both in tech and in the ART+TECH community

If you have read the book or practiced any of these commitments, I would love to hear what you learned.

We are standing at the edge of a structural shift in how work gets done and how software gets built.

For decades, digital transformation meant upgrading tools—better interfaces, faster workflows, more features. But the fundamental assumption never changed: humans did the work, and software supported them.

AI agents break that assumption.

For the first time, we’re designing systems that don’t just enable work—they perform it. They interpret data, coordinate operations, make decisions, and reshape workflows dynamically. This isn’t a UX improvement or a productivity enhancement. It’s the emergence of a new execution layer inside the enterprise.

And as this layer takes form, everything we know about building, delivering, and operating software is being rewritten:

• architectures

• integration patterns

• security models

• pricing

• support

• product strategy

• customer relationships

• and the entire enterprise ecosystem

This is not a technological update—it’s an evolutionary jump.

AI agents are redefining the physics of enterprise software, and the companies that adapt fastest will shape the next decade of digital work.

What follows is a vision of that future—not as hype, but as an operating thesis for how software product companies will build, deliver, and sustain autonomous work inside the enterprise.

1. The Shift From Systems to Workflows-as-a-Service

For decades, software product companies delivered tools while customers were responsible for extracting value.

AI agents dissolve that boundary.

When an agent reconciles financials, processes claims, reviews contracts, or executes compliance checks, the software no longer sits beside the workflow—it becomes the workflow.

This triggers structural shifts across the business model:

• Contracts evolve from access to outcome guarantees

• Pricing moves from seats to volume, accuracy, and task classes

• Vendor consolidation accelerates because operational trust becomes a scarce asset

• Integrations go deeper because superficial APIs cannot support autonomous work

Enterprises won’t buy tools.

They’ll buy workflow execution, delivered reliably through agents.

2. Domain Intelligence Becomes Infrastructure

General-purpose models aren’t enough for enterprise autonomy.

Agents require:

• industry ontologies

• embedded compliance logic

• domain-informed reasoning

• deterministic fallback behavior

• contextual understanding of tools

This creates a new competitive layer:

domain-native intelligence infrastructure.

Software product companies that own this layer will effectively become the operating systems of their industries.

3. Evals Become the Control Plane of Enterprise AI

Once agents perform real work, evals become the governance backbone.

Effective eval systems must include:

• benchmark suites

• adversarial tests

• reproducibility

• regression tracking

• safety scoring

• accuracy SLAs

This fuels a new ecosystem:

• eval clusters

• continuous verification pipelines

• third-party certifications

• eval-driven deployment gates

Evals are no longer optional—they are the control plane for trust.

4. Quality Becomes Contractual

When software creates work output, quality becomes:

• measurable

• reviewable

• contractual

• enforceable

Software product companies must deliver:

• accuracy guarantees

• error budgets

• safe rollback paths

• risk-scored decisions

• traceable execution logs

Quality stops being aspirational.

It becomes the product.

5. Security & Policy Enforcement Become Zero-Trust for Agents

Agents operate across multiple systems and actions, increasing risk.

This requires a new security substrate:

• scoped permissions

• policy-aligned reasoning

• tool isolation

• credential boundaries

• anomaly detection

• behavior attestation

The old perimeter security model collapses.

Enterprises adopt zero-trust for autonomous operations:

• zero-trust tools

• zero-trust reasoning

• zero-trust execution

Security is no longer a layer—it’s the foundation.

6. Traceability Becomes the New Compliance Stack

To adopt agents at scale, enterprises demand “click-through traceability”:

• data lineage

• policy events

• tool invocation logs

• eval scores at execution

• alternative reasoning paths

This creates an emerging category:

Agent Observability & Audit Infrastructure.

Where DevOps gave us logs, metrics, and traces,

AgentOps delivers reasoning trails, policy metadata, and execution forensics.

This becomes mandatory across regulated industries.

7. Implementation Shifts to Workflow Refactoring

Deploying agents requires refactoring the workflow itself, not configuring software.

This includes:

• process decomposition

• tool orchestration

• data alignment

• context pipelines

• simulation of edge cases

• multi-agent workflow design

Enterprise ecosystems will need new partners:

Agent Integrators that combine engineering, AI operations, and workflow re-engineering.

8. Support Evolves Into Operational Reliability Engineering

Support shifts from UI troubleshooting to:

• diagnosing agent behavior

• analyzing drift

• resolving workflow-level incidents

• tuning policy and context

• improving operational accuracy

Support becomes a shared operational discipline—part engineering, part business operations, part safety management.

The New Identity of Software Product Companies

AI agents push software companies into a new role:

→ Providers of autonomous workflows

→ Custodians of digital labor

→ Stewards of accuracy, compliance, and truth

Value migrates upward—from features → workflows → outcomes → trust.

The companies that win will be those that deliver:

• deep domain intelligence

• eval-driven governance

• contractual-quality autonomy

• zero-trust agent security

• full traceability

• workflow transformation

• outcome-based support

We are leaving the era of tools.

We are entering the era of intelligent execution.

And the companies that embrace this shift will define how enterprise software—and enterprise work itself—evolves in the decade to come.

I recently spent time in both San Francisco and New York, two cities that couldn’t feel more different right now, yet both say a lot about where we’re heading.

In San Francisco, everything revolves around AI. Every event, panel, pinboard, and conversation circles back to it. The city feels like it’s living inside its own feedback loop, tech feeding tech. There’s a density of innovation there that’s hard to match anywhere else. It’s raw, restless, and inevitable. You can feel the next chapter of human progress being prototyped in real time.

Yet outside that AI bubble, San Francisco still feels fragile. Many storefronts remain closed, streets are quieter, and that pre-pandemic spark, the serendipity and chaos that once defined the city, hasn’t fully returned. It’s a place in transition: brilliant minds building the future inside, while the outside world waits to catch up.

Then I landed in New York. Instant contrast. The city feels alive, buzzing with energy and diversity in a way that’s impossible to replicate. I arrived in the middle of the mayoral elections and the marathon, and the city was practically vibrating, a reminder that civic energy and human connection are still the ultimate catalysts for progress.

Every corner, every accent, every interaction reminds you that creativity doesn’t just come from tech, it comes from people colliding. While San Francisco is engineering the future, New York is living it.

SF will never be NY, and that’s fine. But AI might be what brings San Francisco’s heartbeat back. The same force that’s transforming our world could be what reanimates its own hometown.

For me, this tension between cities, one building the tools of tomorrow, the other embodying the creative chaos that keeps humanity moving forward, captures the story I keep returning to: the intersection of art, technology, and urban transformation.

Cities evolve like living systems, shaped by innovation and imagination alike. And as AI reshapes what we build and how we express ourselves, it’s clear that the future of creativity will belong to places, and people, that find a way to fuse both.

A special thank you to TeamSystem and our investors for making these regular US visits possible, and to partners, friends and former coworkers we connected with along the way at Google, Apple, Adobe, GitHub, Pixar, OpenAI, Shopify, Qualified, Databricks, Glean, Zendesk, MongoDB, and many more. Those exchanges, of ideas, experiences, and perspectives, are what truly keep innovation alive.

And, most importantly, I’m grateful for the time spent with my kids, the best reminder of why all of this future-building ultimately matters.

Hackathons have shaped the way I think about innovation, culture, and creativity.

They’re proof that when people are free to explore without permission, amazing things happen, ideas grow, teams connect, and innovation becomes a shared language.

Here’s why I believe everyone, no matter your industry, role, or level in the company, should experience one.

It often starts with an idea, small, uncertain, maybe even a little wild. A few people gather around it, sketching, experimenting, testing what might work. No one’s following a plan. No one’s asking for approval. They’re just building, together.

That’s a hackathon.

And I’ve seen what happens when people are given that kind of freedom. The room feels different, lighter, louder, alive. Hierarchies fade, silos dissolve, and collaboration becomes instinctive. People start connecting in ways they never do in meetings or structured projects. They stop talking about innovation, and actually experience it.

That’s the hackathon effect.

And it builds something far more lasting than code. It builds culture.

If You’ve Never Been to a Hackathon, Here’s What It’s Like

Hackathons trace back to the late 1990s, when open-source communities began experimenting with faster, more collaborative ways to build software.

Developers would gather for 24 or 48 hours to create something new, not for profit or fame, but for the joy of making and learning together.

The name says it all: “hack” in the sense of clever, creative problem-solving, and “marathon”, a focused sprint of imagination and endurance.

The early ones were simple: laptops, snacks, sleepless nights, and a shared sense of possibility.

But they sparked a new way of working, where collaboration outpaced hierarchy and experimentation led to breakthrough ideas.

Some of the world’s best-known products and features, from social media tools to startup concepts, began in hackathons.

But the real legacy isn’t what was built; it’s how people learned to build together.*

It’s the realization that innovation starts with exploration, and that great ideas rarely come from certainty.

Why You (and Every Company) Should Join One

I’ve been part of hackathons across companies, teams, and creative communities.

Every time, the outcome is the same, not in what gets built, but in how people think and feel afterward.

Hackathons create space for what modern work often forgets: freedom, curiosity, and shared discovery.

They spark creativity. When people are encouraged to explore, ideas multiply, fast.

They accelerate learning. In two days, you can test tools or approaches that might take months in a normal workflow.

They break silos. Designers, engineers, marketers, and dreamers work side by side. Hierarchy gives way to shared purpose.

They renew motivation. There’s an energy that comes from building something from scratch, from seeing your idea come alive in hours instead of quarters.

And they ripple outward. Even if a prototype doesn’t ship, the spark it creates travels, influencing future projects, products, and collaborations.

That’s why I see hackathons not as side projects, but as engines of innovation and culture.

They remind people why they joined in the first place: to imagine, to create, and to build something meaningful.

No matter your title, team, or background, there’s a place for you in that process.

When Collaboration Becomes a Force

One of the most memorable hackathons I joined was in Las Vegas, during one of the huge AT&T Hackathons often hosted around the Consumer Electronics Show (CES).

These events are something else entirely, massive creative playgrounds where developers, designers, and innovators come together to build the future in just a weekend.

The focus is on 5G, IoT, and public safety technologies, connecting everything from smart cities to connected health devices.

I teamed up with José Antonio Márquez Russo and , and together we dove into the challenge with the same intensity and curiosity that define every great hackathon.

What we built we called RELATE, an app that combined the best of LinkedIn, Foursquare, and Groupon, designed to help people discover meaningful professional connections through shared interests and nearby to build a team.

It was fun, fast, and a little chaotic to build, the kind of creative sprint where ideas evolve in real time and everyone learns something new. The app itself never went anywhere, but the experience and learning stayed with us all.

That’s the real value of hackathons: even when the project did not win or survive, the mindset does. It changes how you think, how you work, and how you collaborate.

The energy was contagious, long nights, bold ideas, fast prototyping, and spontaneous collaboration between people who had just met but shared the same creative drive.

Beyond Technology

Over the years, I’ve realized hackathons aren’t really about technology at all. They’re about people, and the shared drive to make something new. A musician remixing sounds, a designer rethinking materials, a teacher inventing new ways to engage students, they’re all hacking in their own way.

Exploring through making.

Learning through doing.

Turning limits into inspiration.

The hackathon mindset belongs everywhere: in classrooms, studios, labs, and boardrooms. It’s about curiosity. About turning “what if?” into “why not?” And about realizing that creativity doesn’t wait for perfect conditions, it thrives in motion, collaboration, and courage.

“Creativity doesn’t belong to a department.

It lives wherever curiosity meets courage.”

We tend to talk about creativity as if it’s a role or a process, something that happens in a specific place, owned by a few. But it isn’t. Creativity happens in the moments we step into the unknown, when we experiment, when we connect ideas that weren’t meant to fit, when we dare to ask “what if?”

It’s not a skill reserved for designers or developers, but a mindset that belongs to everyone:

• the accountant who automates a task in a smarter way,

• the teacher who reimagines how to engage students,

• the marketer who tells a story differently,

• the engineer who looks beyond requirements and asks why not?

Creativity thrives in curiosity, and it grows when we have the courage to try. That’s what hackathons celebrate: not expertise, but openness. Not perfection, but exploration. And that’s where true innovation, and culture, begins.

The Real Impact

That’s why I believe in hackathons, not just as events, but as a philosophy of innovation. They remind us that technology is most powerful when it amplifies creativity. That culture isn’t written in processes or policies, it’s built in shared experiments and bold ideas. And that impact, real, lasting impact, happens when experimentation becomes part of who we are.

So whether you work in engineering, design, business, art, or education, join a hackathon. Experience what happens when you stop waiting for permission and start building. You don’t need to code to belong there. You just need curiosity, openness, and the courage to create.

Because innovation doesn’t belong to a few. It belongs to everyone, no matter your industry, role, or level in the company.

The future won’t be written by those who wait. It’ll be built by those who experiment, before they’re ready.

A Real Example of the Hackathon Effect

I’ve seen this spirit come to life firsthand.

Years ago, during a hackathon with my team at Salesforce, we decided to use LEGOs to simulate a Smart City using our IoT Cloud Platform in 2017. It started as a playful idea, a way to visualize connected devices communicating through Salesforce data in real time.

This fun hack project quickly gained attention. Our project was later showcased at Dreamforce in San Francisco, where I had the chance to share the experience with our CEO, , who stopped by to see it in action.

And there was another surreal moment I’ll never forget JR, the artist known for his monumental public works, captured a photo of our hack as part of his documentation of the event. I would be thrilled to see the photo he took of our hack one day!

It was the perfect reminder of what hackathons can spark: when creativity, play, and technology intersect, they don’t just generate ideas, they create energy, connection, and culture that spreads far beyond the room.

Building the Next Hackathons

Today, I’m helping build that same spirit of experimentation at TeamSystem, a company that shares this belief in creativity, collaboration, and continuous learning.

We’re designing hackathons not just as events, but as platforms for exploration, places where teams can test new ideas, experiment with emerging technologies, and connect across departments.

Just like the best hackathons I’ve joined before, the goal isn’t only to create prototypes, it’s to build a culture of curiosity.

We’re encouraging people to explore ideas that stretch beyond their daily work, to experiment boldly, and to learn by doing.

Because innovation doesn’t happen in isolation or inside a single team.

It happens when diverse minds collide, challenge each other, and imagine something new together.

That’s what we’re nurturing at TeamSystem: not just innovation through technology, but innovation through people.

Continuing with CODAME

And that same spirit continues to live on through CODAME, where we’ve always believed that creativity, technology, and collaboration belong together.

We’ve hosted countless hackathons over the years, each one blurring the lines between art and tech, between imagination and implementation.

Our next one, “Exploring the New Human”, is coming soon, and it embodies exactly what hackathons are all about: curiosity, courage, and community.

💬 Reflect with me:

Have you ever joined or hosted a hackathon, in tech, art, or life? Reply and tell me what you built, what you learned, or what surprised you most.

Modern architecture like Bosco Verticale from Stefano Boeri rises beside traditional facades, while green spaces and playgrounds stitch the neighborhood together. It felt — and still feels — like a vivid expression of Milan’s spirit: bold, layered, and open to reinvention.

That impression stayed with me.

Today, I work in a space overlooking Biblioteca degli Alberi Milano (BAM) here at Teamsystem. What was once a rail yard is now one of Europe’s most visionary urban parks. But this time, I’m not just passing through — I’m part of the rhythm of the place.

BAM is more than a park. It represents a vision of urban development that brings together design, ecology, and community. Its story is worth reading 🔗 https://bam.milano.it/en/la-storia/

Art played a pivotal role in this transformation. During the 2015 Expo, the Riccardo Catella Foundation and the Fondazione Nicola Trussardi commissioned Wheatfield — a 5-hectare wheat field planted by American artist Agnes Denes. The act was poetic and provocative: a golden field growing in the shadow of cranes and concrete. It invited the city to pause, reflect, and imagine new possibilities. A reminder that art can not only inspire — but also shape the future of cities.

That vision is still alive today.

Most recently, BAM hosted Circus – Il Festival delle Meraviglie al Parco, a three-day celebration of contemporary circus, performance, and aerial art that transformed the park into a dreamlike realm. One of the highlights was SYLPHES – Aerial Poetry in Motion, a breathtaking ballet in the sky that evoked the elegance of synchronized movement and the emotional richness of classical dance. The air itself became a stage — an ephemeral and moving tribute to human fragility and grace.

🔗 See more from that magical moment

Experiences like these reaffirm the role of public space not just as infrastructure, but as canvas — open to all, alive with meaning.

But moments like Wheatfield or Sylphes only reach their full potential when followed by sustained programming, accessible participation, and long-term care. Urban transformation isn’t a one-time installation — it’s a continuous cultural commitment.

Full Circle to ART+TECH

This connection between art, technology, and public experience is also at the heart of CODAME ART+TECH — the nonprofit I founded in San Francisco and recently brought to Milan.

At CODAME, we explore the intersection of creativity and emerging technology not just to push boundaries, but to connect with humans — always placing people at the center of the experience, the inspiration, and the creative process.

We believe that creativity is a powerful tool for building not just products, but perspectives. For sparking dialogue. For imagining futures that are inclusive, expressive, and alive.

Just as cities invest in public parks, museums, or libraries, we believe technology should be treated as cultural infrastructure — designed intentionally, shaped ethically, and rooted in human experience.

Bringing CODAME to Milan has also meant listening first. While the energy of creative experimentation is universal, each city has its own rhythm, constraints, and cultural DNA. Here in Milan, I’ve encountered a deep respect for tradition, balanced with a strong appetite for innovation. The tension between the two is fertile ground for meaningful, human-centered experiences.

The Other Side of Innovation

As with many stories of urban renewal, there are complexities. The transformation of Isola has brought innovation and beauty — but also rising costs, shifting demographics, and the risk of losing the unique character shaped by long-standing communities.

But this doesn’t have to be the cost of progress.

What gives me hope — and what sets Milan apart — is how thoughtfully the city and its community have approached this evolution. From design and architecture to programming, events, and preservation, there’s a clear effort to balance change with care.

The city’s commitment to inclusivity is visible not just in cultural programming like Wheatfield or SYLPHES, but also in everyday details: open-access green spaces, diverse public events, and the playgrounds at BAM where children of all backgrounds play together, while families and grandparents gather, relax, and reconnect.

These spaces are not exclusive. They’re designed to be lived in — by everyone.

BAM, and the broader Porta Nuova district, reflect a vision of urban life where innovation doesn’t just serve aesthetics or capital, but community. Milan is far from perfect — but the intention to include, to preserve identity while embracing change, is there. And it shows.

As we continue building, innovating, and creating, we must ask: Who is this for? And how can we design futures where more people belong?

When art and technology are guided by these questions, they become more than tools — they become bridges.

If you’re working at the intersection of public space, creative technology, and community — or asking these same questions — I’d love to connect.

Over the years, I’ve worked on building software platforms and automation tools to make complex systems more manageable. I moved from monolithic applications to microservices, later adopting micro frontends to gain flexibility and scale. Event-driven and data-driven designs brought even more adaptability—but one issue persisted: integration was always the bottleneck. No matter how modular we got, connecting disparate services remained fragile, slow, and costly.

That’s why the Model Context Protocol (MCP) caught my interest. While I’m still exploring and experimenting with it rather than using it in production, I can already see its potential. MCP isn’t another tool or library. It’s a proposal for a deeper foundation—one that gives intelligent agents the ability to maintain shared context and collaborate coherently across services and platforms.

And if it works, it could change everything about how we build distributed systems.

From Microservices and Workflows to Agents

If you've worked through the evolution of software systems—from monoliths to microservices to event-driven platforms—the emergence of autonomous agents feels like a natural next step. But this shift introduces new architectural requirements. AI agents aren’t just microservices with intelligence; they need to reason, hold memory, negotiate with peers, and operate independently while maintaining consistent context.

That’s where agent protocols come in. They serve as the connective tissue—defining how agents communicate, share goals, delegate tasks, and align on outcomes across distributed systems. What HTTP did for the web, agent protocols aim to do for AI interoperability.

How MCP Could Transform Development

One of the first shifts MCP encourages is moving from rigid, predefined workflows to systems that evolve through interactions. Agent-oriented thinking invites us to see software as a network of decision-makers rather than a pipeline of function calls. Agents operate in a shared memory space, negotiating behavior based on real-time context instead of waiting for someone to call them.

Another appealing aspect is interoperability. Instead of building a custom adapter every time two systems need to communicate, MCP proposes a universal layer—a common contract for how agents talk to each other. That kind of shared language has the potential to cut integration time dramatically and reduce the complexity that plagues multi-system environments.

There’s also something powerful about context persistence. With MCP, agents can react to the world around them as it changes. Imagine a compliance agent observing an update in a billing system and independently triggering downstream checks—no orchestrator needed, no predefined flow to follow.

Strategic Benefits

The appeal of MCP goes beyond technical elegance. Faster development cycles become possible when new features can be composed from existing agents. User experiences improve as systems feel more coordinated and context-aware. Maintenance gets easier when shared standards replace glue code.

And from a business standpoint, the idea of plugging in a new third-party agent rather than building a feature from scratch opens up new possibilities for collaboration and marketplaces.

The State of AI Agent Protocols

Agent protocols are still in early development, but momentum is picking up. Several key players have proposed competing—but sometimes complementary—frameworks to bring coherence to the agent ecosystem.

Model Context Protocol (MCP)

Anthropic’s MCP is one of the earliest and most widely discussed efforts. It enables stateful, context-sharing between agents and defines structures like tools, prompts, and resources. Microsoft is developing a C# SDK for MCP, while companies like Block, Apollo, Replit, and Stripe are experimenting with it. But implementation remains complex, relying on persistent connections and often using stdio transport, which limits scalability. Many parts of the ecosystem—especially client-side primitives—remain underexplored.

Agent2Agent (A2A)

At Google Cloud Next 2025, Google unveiled A2A, an HTTP/JSON-based protocol with over 50 enterprise partners. It focuses on capability discovery, structured task management, and user experience negotiation. A2A introduces the concept of JSON-based "Agent Cards" and is positioned as a higher-level abstraction that complements lower-level frameworks like MCP and LangChain’s Agent Protocol.

LangChain Agent Protocol

LangChain’s protocol aims to bridge structured tooling and LLM orchestration. It integrates tightly with Python agents and is widely used in open-source experimentation. While still evolving, it's already a popular choice for researchers and hobbyists looking to spin up basic agent behaviors.

What's Clear (and What Isn’t)

The existence of multiple protocols isn’t a problem—it’s a sign of rapid innovation. But we haven’t yet converged on a single standard, and each protocol comes with trade-offs. Some prioritize enterprise security and HTTP transport (like A2A), while others are more LLM-native but harder to scale (like MCP).

The takeaway? Protocols are now central to building intelligent systems. And while it’s too soon to bet on a winner, it’s the right time to understand the landscape and get involved.

Final Thoughts

The race to define how AI agents collaborate is very much underway. Whether it’s Anthropic’s MCP, Google’s A2A, LangChain’s Agent Protocol, or something else entirely, one thing is clear: agent-based systems need standards.

As someone who's built backend systems, workflow engines, and distributed applications, I see agent protocols not as a hype cycle but as an architectural necessity. They won’t solve everything, and none of them are quite ready for prime time. But even today, they offer a window into what the next generation of software might look like.

We're witnessing the TCP/IP moment for agents. And while we don't yet know which protocol—or combination—will dominate, this is a space worth watching closely. If even half the promise holds, agent protocols will become a foundational layer for AI-first software in the years ahead.

In my line of work, staying close to the cutting edge of AI research is part of the job. But sometimes, a scenario comes along that pulls you out of the day-to-day and forces a broader view. That’s exactly what happened when I read AI 2027 by , Scott Alexander, Thomas Larsen, Eli Lifland and Romeo Dean, a speculative yet rigorously reasoned forecast that outlines the possible emergence of artificial superintelligence (ASI) within just a few years.

Kokotajlo, formerly of OpenAI, developed this scenario in partnership with the AI Futures Project. The document reads like a time machine into the near future—one where AI doesn’t just assist or augment human work, but fully surpasses it.

The Timeline

The full AI 2027 report is a richly detailed scenario—I highly recommend reading the entire document for its narrative depth and technical insight. But for your convenience, here’s a short summary of the projected milestones:

• Early 2027: AI systems exhibit superhuman coding performance, significantly accelerating the speed of R&D across industries.

• Mid-2027: The rise of autonomous AI researchers—agents that not only generate knowledge but guide their own experimentation.

• Early 2028: The arrival of superintelligence, where AI systems surpass human reasoning across most cognitive domains and begin automating their own advancement.

These milestones may sound dramatic. But as Kokotajlo points out, this trajectory is not entirely speculative—it's based on observed trends and informed extrapolation.

The Context

Some critics are understandably cautious, I am too. The AI 2027 report blends scenario modeling with speculative fiction, using storytelling to explore what such a world might look like economically, geopolitically, and technologically. But there’s a precedent: Kokotajlo’s 2021 scenario, What 2026 Looks Like, successfully anticipated several major AI developments, including the rise of foundation models and increasing concerns over alignment and capability control.

That track record makes this latest forecast harder to ignore.

From My Perspective: Urgency Without Panic

As someone engaged in the development and deployment of cutting-edge systems, AI 2027 reinforces a tension I’ve been feeling for a while: progress is happening faster than our institutional capacity to manage it. While much of our current work focuses on improving performance and capability, we’re simultaneously being pulled toward a horizon where control becomes the core challenge.

This is where alignment becomes not just a research goal, but an existential one. We need systems that are:

• Corrigible: Able to be corrected, redirected, or shut down when needed.

• Interpretable: Transparent in reasoning and behavior.

• Aligned: Consistently acting in ways that reflect human intentions and values.

These aren't theoretical concerns. If autonomous AI research agents become viable in the next 24 months—as AI 2027 suggests—they could begin amplifying their own capabilities in ways that outpace traditional oversight mechanisms. Governance, safety research, and inter-organizational coordination must scale in tandem with capability.

Governance Is No Longer Optional

The report also highlights the growing risk of international competition. If superintelligent systems are seen as strategic assets—on par with nuclear or cyber capabilities—the incentives for transparency and restraint could vanish overnight.

We’re already seeing early signals of this dynamic play out. Regulatory frameworks are emerging, but most remain reactive. One notable exception is the EU AI Act—the world’s first comprehensive AI regulation, recently passed in 2024. It categorizes AI systems by risk level and introduces obligations for transparency, safety, and accountability. While imperfect, it represents a serious attempt to get ahead of the curve and could serve as a template for other jurisdictions.

Still, no national policy—however well-crafted—can address global-scale risks on its own. That’s why now is the time to support international efforts for coordinated AI governance. We need robust frameworks, shared safety benchmarks, information-sharing protocols, and perhaps most critically, an ethos of restraint in deployment.

The AI 2027 scenario may be aggressive, but if it serves as a catalyst for thoughtful and collective preparation, it will have done its job.

Closing Thought

Whether or not you believe artificial superintelligence will emerge by 2027 or 2028, the scenario deserves attention. Preparing for high-impact possibilities—especially ones with irreversible consequences—is not alarmism. It’s responsibility.

The AI 2027 scenario also reminds us that the consequences won’t just be technical—they’ll be geopolitical. As AI becomes a central lever of economic and military power, the decisions made by national leaders, regulatory bodies, and international coalitions will shape the trajectory of the entire planet. That brings an added layer of responsibility to democratic processes: who we elect matters more than ever.

We can’t afford to treat AI governance as a niche policy issue. The people we put in power will increasingly be tasked with navigating technologies that could determine global stability, economic structure, and civil liberties. That means it's not just their responsibility to lead wisely—it's our responsibility to make sure we’re putting the right people in those positions.

If you haven’t read the report yet, I strongly recommend exploring it here:
ai-2027.com/scenario.pdf

We’re building the future right now. The question is: will we build it wisely?

After spending 15 transformative years in the ever-evolving San Francisco Bay area, returning to Italy has been an extraordinary personal and professional growth journey. It’s hard to believe a year has passed since my homecoming. This past year, I’ve gained valuable insights into the fascinating contrasts between Italy and Europe and their views on work and life.

There is so much to explore in this realm. I’ll begin with a small yet curious topic: the evolving Italian language. Having been born in Italy, speaking Italian is second nature to me, and my proficiency in English—honed over more than 30 years abroad—allows me to navigate between cultures effortlessly. Language is a living entity, constantly transforming, especially in the tech world, where English terms often supplant traditional Italian ones. I've encountered English words that take on different meanings in Italian, sparking moments of realization and connection.

For example, you might all know that "football" means American football in the S, while in the UK, it refers to what Americans call soccer. In Australia, "football" can mean Australian Rules Football (AFL), a different sport, but it can also refer to soccer, depending on the context. Thankfully, in Italy, we still use "Calcio" for football, so there’s no confusion!

Here are some English terms that I am still struggling with, especially in the tech field:

Governance

In Italian, terms like "governo" or "gestione" exist, but they don’t fully capture the meaning of "governance."

Governance means managing a project in tech projects. This includes controlling the scope and budget and making decisions. Governance helps engage stakeholders, reduce risks, and ensure results meet organizational goals. It also ensures that tech projects achieve business objectives, follow regulations, manage stakeholders well, and control risks.

In the U.S. tech sector, people often use different terms instead of "governance" to describe processes and management systems. While governance is important, here are some other common terms in U.S. tech:

Management: Often used in place of governance to describe the general administration or overseeing of operations, projects, or systems. Examples: Project, IT, Risk Management.

Oversight: This refers to supervising or monitoring activities to ensure compliance with standards or objectives, such as data Oversight and Compliance Oversight.

Control: More focused on enforcing rules, standards, or practices within an organization or system, for example, Access, Change, and Quality Control.

Strategy: Used when referring to the high-level planning and direction-setting aspects of technology or business systems. Including IT, Digital, and Cloud Strategy.

Compliance: It ensures that systems, processes, and operations adhere to legal, regulatory, or industry standards, such as compliance Programs, Security Compliance, and Data Compliance.

Framework: A structured set of guidelines or best practices to support decision-making and operations. Like the IT, Governance, and Security Framework.

Policy: Refers to the principles or guidelines that shape decision-making and behavior in a system or organization, such as Security, Privacy, and Data Management Policies.

Administration: Like management, system administration focuses on the practical aspects of running systems or processes, particularly in the tech and IT domains. Examples include system and network Administration.

Regulation: Refers to establishing and enforcing rules and standards, often in legal or compliance contexts—examples: Regulatory Compliance, Data, and Financial Regulation.

Risk Management: Identifying, assessing, and mitigating organizational or system risks. Examples include Cybersecurity and Operational Risk Management.

Though these terms are similar, they have specific meanings for managing technology in the U.S. tech industry. In Italy, “governance” is the preferred term for all areas of IT, data, cloud services, cybersecurity, and digital governance. This choice reflects the structured nature of Italy's tech landscape.

From what I have noticed so far, “Governance" Is Preferred in the Italian tech sector for the following reasons:

Global Consistency: The term "governance" is commonly used in the tech sector worldwide. Using it in Italy helps align with global frameworks, standards, and terminology, which is especially important for multinational organizations or those aiming for international compliance.

Formal and Technical Connotation: "Governance" suggests a structured, formal, and technical approach to managing complex IT and digital systems. Unlike more general terms such as "management" or "oversight," it implies a higher level of strategic decision-making and accountability.

Regulatory Alignment: Italy has stringent compliance requirements related to data privacy (e.g., GDPR) and cybersecurity. Consequently, governance is essential to ensure organizations manage their IT systems according to legal and ethical standards.

Clarity and Efficiency: In professional settings, the English word "governance" provides more precise and efficient communication than longer Italian phrases like "gestione delle risorse informatiche" (management of IT resources).

Software Factory

I find it hard to accept the term "software factory" because I spent most of my career in the US. This view comes from different historical and cultural backgrounds. In Italy, the word "fabbrica" was translated to "factory" to describe teams or departments that create software. The software industry has taken on industrial terms.

In Italy, "software factory" is commonly used in its original English form. It means a structured environment for software development that uses standardized tools and frameworks. This approach aims to improve efficiency, quality, and scalability.

Unlike the US, where the development approach is more flexible, software factories in Italy have strict frameworks and clear roles. Creating software is treated like a manufacturing process. The term represents a systematic way to develop software in Italy, focusing on repeatable processes and scalability. There are fewer software product companies in the US. In Italy, many software projects, especially large or government ones, are outsourced. This reflects a need for predictability and standardization, showing an industrial engineering view of software development. This contrasts with the agile, startup-focused culture in the US tech scene.

So, in Italy, "software factory" refers to a more formal, structured, and industrial approach compared to the flexible and casual US environment.

Smart Working

Although the term "smart working" is not commonly used in English, it reflects how languages adapt borrowed terms to local cultures and laws. I don't mind this term; I'm starting to like it and find it entertaining.

In Italy, "smart working" describes flexible work arrangements that do not depend on location, such as remote, hybrid, and telecommuting options. After the pandemic, "smart working" became popular after the legislation called Lavoro Agile gave it legal recognition. Now, it is viewed as modern and innovative.

In English-speaking countries, "remote work" is the standard term, but Italy prefers "smart working," especially after the pandemic. This term shows a cultural change toward productivity, collaboration, and the use of technology beyond just working from home.

Product Owners and Product Managers

Overlap in job titles is not just an Italian issue; I have seen it across Europe.

The Product Owner and Product Manager in Europe have different and specific duties. In the U.S., the Product Owner is a Scrum team member, while the Product Manager is the primary job title for leading product strategy.

The Product Manager role is broader and includes both strategy and execution tasks. U.S. companies often use the PM title to combine these roles, while European companies usually keep them separate. This distinction can be confusing if you are used to the U.S. system.

For example, companies like Google and Amazon use "Product Manager" for both strategic and tactical roles but use "Product Owner" for focused execution. In Europe, organizations like Spotify typically separate these roles, with PMs focusing on strategy and POs managing execution.

To my understanding, the key Differences Between Product Manager and Product Owner are:

Product Manager (PM):

• Scope: Oversees the product’s vision, strategy, and lifecycle.

• Focus: Aligns business objectives, customer needs, and market opportunities.

• Responsibilities:

  • Defines product strategy and roadmap.

  • Engages with stakeholders and executives.

  • Balances priorities to maximize value for the business and customers.

• Context: A high-level, strategic role found across industries, regardless of methodology.

Product Owner (PO) in Europe:

• Scope: Tactical role focused on execution within Agile or Scrum frameworks.

• Focus: Manages and prioritizes the product backlog to maximize value delivery.

• Responsibilities:

  • Maintains and refines the backlog.

  • Acts as the primary point of contact for the development team.

  • Ensures alignment with the Product Manager’s vision.

• Context: Recognized as a distinct job title in Agile organizations, often reporting to a PM.

Product Owner (PO) in the U.S.:

• Scope: A role within a Scrum team rather than a formal job title.

• Focus: Prioritizes tasks and manages the backlog as part of their Scrum responsibilities.

• Responsibilities:

  • Works collaboratively with stakeholders and developers.

  • Focuses on execution rather than high-level strategy.

• Context: Typically, a responsibility is assigned to someone already in another role, such as a Product Manager or Business Analyst, rather than a dedicated position.

Why the title of "Product Manager" is more common in the U.S.:

Broader Applicability: PM is a universal title used across industries and methodologies.

Strategic Focus: U.S. companies often prioritize strategic roles like PM over execution-focused roles like PO.

Agile Nuances: Many U.S. companies blend Agile with other methodologies, making PM a more adaptable title.

Market Familiarity: PM predating Agile has been entrenched in U.S. business terminology for decades.

Welfare

In Italy, "welfare" often refers to employee benefits that improve workers' well-being. These benefits help create a happier workplace and boost productivity. Examples include health insurance, meal vouchers, childcare support, gym memberships, transportation help, and access to cultural or recreational activities. Italian welfare aims to support a good work-life balance, often influenced by government programs or labor agreements.

In the U.S., "welfare" has a different meaning. It usually refers to government programs that assist low-income individuals or families with their basic needs. These programs include food stamps, Medicaid, unemployment benefits, and housing support. In this context, welfare acts as a safety net, giving financial aid, healthcare, and other essential services to those in need.

Key Differences:

1. Scope of Benefits:

   • Italy: Focuses on enhancing employees’ well-being and productivity through company-provided programs.

   • U.S.: Provides essential support to those in financial hardship through government assistance.

2. Provider:

   • Italy: Welfare is typically employer-driven and tied to workplace policies or labor contracts.

   • U.S.: Welfare is managed and funded by federal, state, or local governments.

3. Perception:

   • Italy: Seen as a positive, forward-thinking initiative to attract and retain talent and promote corporate social responsibility (CSR).

   • U.S.: Often viewed as a lifeline for individuals in need, but also a topic of political debate around its role, scope, and impact.

4. Cultural Implication:

   • In Italy, the term welfare aziendale reflects the country’s strong focus on employer responsibility and social cohesion within the workplace.

   • In the U.S., welfare evokes broader societal issues around poverty and inequality and the government’s role in addressing them.

The different meanings of the term "welfare" show how it can change based on a country's social and economic needs and culture. In Italy, welfare focuses on improving well-being in the workplace. In contrast, in the U.S., it emphasizes the government's responsibility to support vulnerable groups.

Competence Center

Competence Centers are specialized hubs in Italy that focus on expertise, innovation, and research. They play a key role in technology, academia, and business and act as central resources for advanced knowledge and development. The term became popular through government programs like Industria 4.0, which established Centri di Competenza to help businesses adopt new technologies. These centers often work through public-private partnerships and are considered prestigious institutions representing modernity, specialization, and collaboration.

The term “Competence Center” is rarely used in the U.S. In American English, “competence” refers more to individual skills than an organization's expertise. Americans typically use terms like “Center of Excellence, “Innovation Hub,” or “Research Center” to describe similar entities. These terms better fit U.S. cultural and linguistic norms, focusing on innovation and collaboration without the ambiguity of “competence.”

The difference between the terms reflects European influences on the Italian language. In Italy, "competence" suggests collective organizational expertise, similar to "Kompetenzzentrum" in Germany. Italians often adopt translations from EU policies, shaping their local language. The Competence Center conveys modernity, specialization, and professionalism in Italy, making it appealing in tech and industrial fields.

While Competence Center is a respected term in Italy and Europe, Americans prefer alternative names like Center of Excellence, Innovation Lab, or Research Center.

The use of the Competence Center in Italy shows its connection to global trends and a professional outlook. However, the different terms highlight how language evolves in various cultures worldwide.

Wrapping it up…

Italy closely follows global technology trends, even though it has some unique terminology. Job titles such as software engineer, developer, and data scientist are common and easily recognized in Italy, just as in the U.S. and Europe.

Here are some general reasons why English terms are used in Italy:

1. Global Industry Standard: English terms are often adopted in tech to align with global trends and are recognized internationally. Even if they do not always have the same meaning elsewhere.

2. Professional Appeal: Using English terms makes the field sound modern and aligned with cutting-edge practices.

3. Brevity and Clarity: Unlike longer Italian translations, the original term is concise and easily understood in the tech industry.

4. Cultural Adaptation: English terms are often used in technology and innovation due to their association with Anglo-American practices.

The good news is that Italian engineering teams are as skilled as those in Silicon Valley or Germany. After many years of experience in both places, I can confirm Italy is strong in the technology industry. Italian teams' mix of creativity, social skills, and entrepreneurial spirit makes them unique.

Even though we use terms like “software factories,” I like that our work is not just a simple assembly line process. Italian teams are very skilled and are not restricted by strict rules. Freedom and creativity are essential in an industry that relies on innovation.

After a year of returning, I appreciate being part of Italy’s lively work scene again. Although the language around work has changed—terms like governance, “Fabbrica,” and smart working are now common—the heart of Italian culture is still creativity, passion, and a strong sense of community. It feels great to be back home, and I hope this message encourages you to consider returning or moving to Italy.

If you’re still with me, it’s clear you find this topic intriguing. I’d love to hear your thoughts! Do you have your own experiences to share? Do you see things differently, or is there more you’d like to dive into? Let’s chat!

If you need help, feel free to contact me anytime! Have I mentioned that TeamSystem is looking for new talent?

In an increasingly digital world, the intersection of art and technology has become a fascinating playground for creativity. The CODAME ART+TECH Festival is more than just an event—it's a movement designed to bridge the gap between artists and technologists, encouraging collaboration and innovation. Now that I've moved to Milan, it felt like the perfect place to expand CODAME’s vision, blending the city’s rich cultural tradition with its growing tech scene. Milan, a global hub for fashion, art, and design, offers the perfect backdrop for fostering creative energy, making it a natural choice for the festival’s next step.

A Bit of History

CODAME began in San Francisco, a city renowned for its technological innovation and vibrant art scene. Since its inception, the festival has brought together some of the brightest minds in both fields, blending cutting-edge tech with artistic expression. As I transitioned to life in Milan, it was clear that this city was ready to host the ART+TECH Festival, continuing the tradition of cross-cultural collaboration.

What’s Coming Up?

This October, CODAME ART+TECH Festival 2024 in Milan will host a series of exciting events exploring the intersection of art and technology. Here’s what’s on the calendar:

• October 3rd: Is this Art?

  The festival kicks off with an Experiential Dialog to explore the fundamental question, “Is this art?” followed by MatchBox Speed Dating—a unique opportunity for artists and technologists to meet and collaborate. As always, BYOB (Bring Your Own Beamer) will give attendees the chance to showcase their digital art.

• October 25th: Are you connected?

  This event will feature an Experiential Dialog on connection in the digital age, along with MatchBox Presentations showcasing projects born from our collaborations. Attendees can once again bring their art to share in our BYOB segment.

• October 31st: Are you smarter than me?

  Halloween is for more than just costumes! This night will feature an Experiential Dialog around intelligence in the digital world, a MatchBox Show, and BYOB. To wrap it up, we’ll celebrate with live music and a costume party!

Connecting San Francisco and Milan

This festival is a tangible bridge between San Francisco, where CODAME was born, and Milan, my new home. It’s more than just a series of events—it’s an opportunity to foster global connections through creativity, art, and technology. We hope CODAME ART+TECH Festival will inspire other cities to join in the future, building a worldwide network of collaborative innovation.

See You Soon, Milan!

We can’t wait to kick off this unique exploration of art and technology on October 3rd. Whether you're from San Francisco, Milan, or beyond, this festival is a call to creators everywhere to come together. Don’t forget to bring your art, your prefered tools, devices, projectors, and your creative spirit to the event—BYOB is all about showcasing art in its many forms!

For the full program and more details, check codame.com

The event is free, but donations are greatly appreciated. Thank you 🙏 for supporting ART+TECH. All profits will be shared with the artists.

Tickets