I look back six months and I already struggle to remember how we used to work a year ago. Not out of nostalgia, out of sheer strangeness. Like when you go back to a house you once lived in and don't recognise the rooms.
It started as an experiment with no name. Today it still doesn't have one, but it has a recognisable shape. At Dcycle, the entire company contributes to the product codebase. Not just the engineers. Customer Success deploys automations. Marketing builds its own data flows. Ops assembles dashboards that used to require three meetings and a ticket. Nobody has to explicitly ask them to do it. The tools simply allow it and curiosity does the rest.
What happened, during that experiment, is that speed changed the culture. Not the other way around. It wasn't that we first designed an autonomy manifesto and then people started building. It was that someone from CS got tired of waiting two cycles to solve a problem they knew well, opened Claude Code, and fixed it. When the team saw the result, nobody asked if that was "their role". They asked how to do it.
We already had the autonomy gene inside us, but the tools made it explode.
What is a conscious decision is to maintain it. I hope every person on this team has the reflex to solve before the reflex to delegate. If you see a problem and you can fix it, fix it. You already have permission. If you can't, learn enough to be able to next time. Look for a way to learn; if you can't find one, ask for help. You'll always find a friendly hand nearby.
Your title no longer describes what you do
There's something that isn't said enough about what happens when everyone can build solutions: your title stops exclusively describing what you do.
Marina is still in Customer Success. But last week she deployed a bot that cross-references usage data with churn signals and generates Slack alerts suggesting actions. Juan is still in Finance, but he built a financial reconciliation system that used to take us two days and now takes ten minutes. They haven't stopped doing their jobs. It's that their jobs now include designing the machines that do part of their jobs.
I know this can sound like a LinkedIn entrepreneur. But living it has a very different flavour from reading it. Living it feels more like a productive disorientation: the feeling that what you knew how to do is no longer enough, but what you can do is more than ever. Tell me about it.
Managers of one and many
We call it "managers of one and many" and I know it sounds odd. But it captures something real.
Every person at Dcycle manages their own work. That's the "of one". They have the autonomy to decide what to build, how to solve anything, or when to iterate on something. They don't wait for approval to improve something. The bias is towards action.
And every person also orchestrates agents. That's the "of many". Not in a sci-fi way. In a practical way: they design prompts, define flows, break things and fix them, supervise outputs, correct errors. They have a team of agents that amplifies their capacity. We went from "doing" to "designing how it gets done" and then verifying it was done well.
The "Agent Manager" isn't a new job title (if you see it out there, be suspicious, it's the new 'Director of Innovation'). It's a new skill layer that sits underneath everything else. It doesn't matter if you're in CS, product, or sales. If you don't know how to orchestrate agents, you're using twenty percent of your capacity and impacting ten percent of what you could.
This isn't optional. I expect everyone to dedicate time to learning how to work with agents. It's the difference between being someone who does tasks and someone who designs systems. And here, now, we're looking for the latter.
Silos are over
And here's the consequence I least saw coming: functional silos are over. Not because we run a cross-functional collaboration workshop. Not because we have a shared OKR. They dissolve because when you can do more things, you inevitably touch more territory.
The dependency between teams was the glue that kept silos in place. By eliminating the dependency, silos lose their reason to exist. What remains are people, who know more and more about everything, and who move between problems instead of moving between departments.
There's no innovation committee. There's no lab separate from the rest. What there is, is a snowball that each person pushes in a different direction, and the result is something none of us could have designed alone. The frontier isn't planned. It's discovered, every day, when someone crosses a boundary nobody told them they could cross.
Read that sentence again
Last week, our Talent Manager fixed a bug in production. He didn't choose the wrong profession. He saw something broken, learned enough to understand it, and fixed it. Soon, a developer will sit down to listen to recordings of prospect calls, from a prospecting cadence that an SDR will have designed from start to finish, but doesn't execute alone. The SDR designs the strategy, the agents execute it, and the developer still wants to understand what customers are saying to improve whatever they're building.
An SDR who designs but doesn't execute. A developer who listens to sales calls. A Talent Manager who pushes code. If you look at it from the logic of the org chart, it's a disaster. If you look at it from the logic of results, it's the most efficient we've ever been.
This is what happens when you stop protecting the boundaries between roles and start protecting curiosity. The snowball grows in every direction. And the frontier isn't ahead. It's everywhere.
The tensions
I don't want to paint this as an Eden. It has its tensions.
The most obvious: if everyone can build, who decides what gets built? Autonomy without alignment is chaos. The answer isn't less autonomy but more visibility. That's why I expect something very specific: share what you're building, before you build it. Think out loud. Publish before perfecting. Transparency isn't a nice-to-have. It's what makes autonomy work and not turn into anarchy.
There's a silent trap in building capacity: it's very easy to confuse output with outcome. Building something that works isn't the same as solving something that matters.
Before opening Claude Code, before designing the flow, there's a question I hope each of you asks: what has to be different when this is done? Not what am I going to build, but what has to have changed. The output is the means; the outcome is the point.
This doesn't slow action down: it orients it. A builder who knows exactly what they're trying to change builds faster, not slower, because every decision has a clear north.
The second tension: professional identity. If you're no longer "just marketing" or "just ops", what are you? That creates discomfort. There are people who found security in specialisation and who now feel the ground shifting. I understand. But I hope you embrace that discomfort rather than flee from it. Because what you are is a builder who knows a lot about marketing. A learner who masters ops. Your expertise doesn't disappear. It becomes your perspective, not your perimeter. Expanding the perimeter is a sign of a good direction.
60 people, 100x more capacity
We're the same sixty people. But the output of this company will be unrecognisable compared to a year ago. Not because we work more hours. We work, and will work, the same hours. It's that each person with a team of agents behind them that amplifies everything they do, multiplies their radius of action by 100. What used to require two people and a week, one person can now solve in an afternoon. Not always. But increasingly.
This has enormous implications for how we think about growing. The question is no longer "how many people do we need to hire" but "how much can we amplify the capacity of those we already have". It's not an argument against hiring. It's an argument for hiring differently: people who know how to orchestrate, who learn fast, who feel comfortable in the ambiguity of a role that changes every quarter. And I expect the same from those already here: that each month you're capable of doing more than you could the month before. Not more hours. More capacity.
Builders and learners
This is how we describe what we look for and how we approach work.
Builder because you build. You don't just think, you don't just plan, you don't just strategise (much less, PowerPoints). You put things into the world. Code, automations, documents, systems. Things that work, that have an output, that someone can use tomorrow. I expect that every week, every person on this team will have put something into the world that didn't exist on Monday.
Learner because what you know today isn't enough for tomorrow. Six months ago nobody on this team knew how to orchestrate agents. Three months ago some did it with difficulty. Today it's becoming the standard. The speed at which tools change, the threshold of what's possible, demands an equivalent speed of learning. Don't wait for someone to come teach you. Go and learn. It's easier than ever. Whoever stops learning, stops. I expect tireless curiosity. I expect you to break things by trying. I expect questions before certainties. If you've learned something new, share it, inside and outside Dcycle.
They're not two different things. They're the same: you build to learn and you learn to build.
My part
Everything above is what I expect from you. Now, my part.
If I ask you to build, I commit to clearing rubbish out of the way. Every process that adds nothing, every approval that only exists through inertia, every meeting that could be a message: it's my responsibility to eliminate it. Point it out when you see it. Your energy should go to building, not to navigating bureaucracy.
If I ask you to break things by trying, I commit to making sure breaking things has no consequences. Good-faith mistakes are not penalised here. They're analysed, learned from, and we move on. The only unforgivable mistake is not trying. If you ever feel that making a mistake has a political cost, tell me. Because that will mean something in the culture has broken, and fixing it will be my number one priority.
And if I ask you to learn constantly, I commit to learning with you. Not from an office. From the same trenches. If I stop building, stop breaking things, stop asking uncomfortable questions, you have the right to call me out. This pact works in both directions or it doesn't work.
The most transformative thing of all
I don't know if in a year we'll still be working exactly like this. Probably not. We'll probably have discovered problems we can't see now, and will have invented solutions we can't imagine now.
And that, I think, is the most transformative thing of all. Not the technology. Not the agents. Not the code. It's the mindset of someone who stops waiting and starts solving. Of someone who sees a problem and, instead of escalating, builds. That's what I expect from every person in this company. Nothing more, nothing less.
This is how we work at Dcycle. Builders. Learners. Managers of one and many. And the path continues to be made by walking.
J.
