Same curiosity. More perspective. Still evolving.
Looking back
On September 30, I turn 50.
It is one of those round numbers that makes you look backwards, whether you planned to or not. I do not see it as a finish line, and I do not want to turn the last fifty years into a list of job titles, certifications or achievements. What I keep coming back to is a much simpler question: how did the kid who was fascinated by a computer end up here, almost four decades later, still wanting to know how things work and what I can build with them?
My professional career in technology started in 1997. My relationship with computers started much earlier.
"The technologies changed. The jobs changed. The places changed. The curiosity stayed."
Before there was a career
I was around nine or ten when I started programming in BASIC. I obviously had no idea what a career in technology was. I was not thinking about software engineering, platforms, architecture, cloud or AI. I just liked the fact that I could write something, press a key, and make a machine do what I had told it to do.
Then came the computers I still remember as milestones: an inherited 8086, then a 386, and later my first Pentium 60. Today the names sound almost archaeological. At the time, every new machine felt like a bigger world. More speed, more possibilities, more things to try, and more ways to get something wrong and then work out why.
That last part is probably important. I have always learned by touching things. Reading, trying, breaking, fixing, asking questions, trying again. I did not know it when I was ten, but I was already developing the habit that would shape most of my professional life.
The Internet, a webmaster, and choosing my own route
At eighteen, I did not go straight to university. Computing was changing very quickly and the Internet was opening a completely new world. The things I wanted to learn about the Web were not something I saw reflected in the path available to me at the time, so I did what already felt natural: I learned on my own.
There was no YouTube. No Stack Overflow. No ChatGPT. There were books, magazines, documentation, source code, conversations with other people and a lot of trial and error. You learned because something worked, but very often you learned more because it did not.
By 1995, I was simply a webmaster. I like saying it exactly like that. Not a platform architect in an early stage of a master plan. Not a future SME. A webmaster. The Web was new, I was curious, and I wanted to build things for it.
Two years later, in 1997, software development became my profession. From there came years of building software for very different environments: web, banking, media, mobile, e-commerce. Development became technical leadership, and technical leadership gradually opened the door to people and delivery responsibilities.
I did not build my career by knowing what came next. I built it by learning whenever 'next' arrived.
University, ten years later
At twenty-eight, I did go to university to study Computer Science. By then I was not starting from zero. I had already spent years learning and working professionally. Part of the reason I went was very personal: I wanted to see where my knowledge really stood when compared with a formal academic environment.
I did not finish the degree. That is not something I need to hide, and it is not something I need to turn into a badge either. It is simply part of my path. What it reinforced for me was that education was never going to be one stage of my life with a beginning and an end. Learning had already become continuous.
Moving to grow
In 2006, I moved to Madrid because I wanted to grow professionally. It sounds simple when written in one sentence, but it was an important decision. I wanted to put myself in a bigger professional environment, meet different people, work on harder problems and create opportunities that were not going to appear by themselves.
Later, I also spent time in San Francisco studying languages. English was not just another skill to add to a CV. For me it became access: access to more knowledge, more conversations, more people and a much bigger professional world. Years later, working every day with international teams would feel completely normal, but that normality was built one decision at a time.
In 2013, joining trivago took me to Germany. By then technology was already my profession and I had years of experience behind me, but I was still willing to change country and environment because I believed there was more to learn and more room to grow.
Later came Mallorca, another change of place while my professional world was becoming increasingly international. Gibraltar followed as another move made with the same instinct: if changing my environment could help me improve professionally, I was willing to do it.
And in 2025, close to turning fifty, I moved again - this time to Belgium to work at NATO in Mons. That move made me notice something about myself. Moving somewhere new when you are young is one thing. Doing it again when your life and career are already established is different. Apparently, I never completely lost the
willingness to put myself somewhere unfamiliar if I believed there was something there worth learning.
Madrid. Germany. Mallorca. Gibraltar. Belgium. Different stages of my life and different reasons, but often the same instinct: keep moving when moving can help me grow.
Some of the biggest changes in my career were not technologies. They were decisions to put myself somewhere I could grow.
2011: Agile and Atlassian arrived together
2011 was another important point in the story. Agile and Atlassian entered my professional life at roughly the same time. Jira and Confluence became part of the way we worked, while Agile changed the way I thought about the work itself: iteration, feedback, visibility, collaboration, priorities and continuous improvement.
But Jira did not suddenly become my career. That is an important part of the story. I was still developing software and, in parallel, building a management career. Engineering, leadership, delivery and Atlassian lived together for years.
I think that overlap explains a lot about how I see Atlassian today. I have never been very interested in a tool for the sake of the tool. I want to understand the process behind it, the people using it, where the friction is, what needs to be flexible and what needs to be reliable. The configuration comes after that.
trivago: the chapter that connected the pieces
In 2012, trivago appeared on my professional horizon. In January 2013, I joined as a PHP Developer and moved to Germany. I could not know it then, but I would stay for almost eight years, and it would become one of the most important chapters of my professional life.
My role changed many times during those years: developer, Team Lead, responsibility for development teams, Atlassian Administrator, area and Atlassian leadership, department management. I led teams, coached new leaders, dealt with delivery, priorities, restructuring and organisational change, and I still
remained close enough to the technology to understand what we were actually asking people to build.
The titles are not the interesting part for me now. The interesting part is what changed in my perspective. A developer can spend a lot of time thinking about whether the code is right. Once you are responsible for people and delivery, 'right' becomes a much bigger question. A technically good decision can still be a bad
decision if it makes the team slower, creates unnecessary complexity or solves the wrong business problem.
In 2014, Atlassian administration became an explicit part of my responsibilities. I stopped seeing Jira and Confluence only from the user side and started seeing the platform behind the teams: configuration, governance, automation, permissions, integrations, scale, and all the small decisions that can quietly make work easier or harder for hundreds or thousands of people.
trivago was also where trust from other people changed my career. John Bettiol, in particular, trusted me with responsibilities that helped me grow as a people manager and leader. That matters when I look back. Some of the biggest steps in a career happen because somebody gives you space to grow before you are completely certain that you are ready.
Team '17, Community, and seeing a bigger ecosystem
Atlassian Team '17 was another turning point. Until then I had years of experience with Jira and Confluence, but the event made the ecosystem feel much bigger. It was not only software. There was a community around it, different organisations solving similar problems in completely different ways, and a much wider conversation about how teams work.
That eventually led me to become active in the Atlassian Community in 2019. Community changed something for me because knowledge stopped being only something I consumed or used at work. It became something to share. Ask a question. Answer one. Explain what worked. Learn from somebody else's approach. Repeat.
Choosing Atlassian
For a long time, Atlassian was one important part of a much broader career. At some point, I made a conscious decision to go deeper and make it my main professional specialisation.
What matters to me is that I did not arrive there empty. I did not specialise in Atlassian first and then learn about engineering, management, delivery and business. I arrived carrying all of those perspectives with me.
In 2020, Cloud and certifications became another part of that evolution. I never saw certifications as the reason to learn something. For me they were a structured way to test what I knew, discover what I did not know and keep moving. Years later, contributing to Atlassian certification exam development gave me an experience I could never have imagined when I was learning from books and trial and error: helping defin d my career around Atlassian and then learn engineering, management and business. I arrived at Atlassian carrying all of those perspectives with me.
What Atlassian came to mean to me
If I look at the last fifteen years, Atlassian is not just the technology I happened to specialise in. It became the place where many different parts of my career finally started to make sense together.
Jira and Confluence first arrived as tools that helped teams work. Over time, the ecosystem gave me something much bigger: a way to connect engineering with process, management with delivery, and business problems with technical systems. Later, Jira Service Management, Assets, Automation and Forge kept extending that same idea. I could stay close to implementation while also thinking about the organisation around it.
That is probably why Atlassian became so important to me. It sits exactly in the space where I have always felt most useful: between people and technology. A request that looks like a Jira ticket is usually a process. A workflow is usually a conversation between teams. A field can represent a business decision. An automation can remove frustration from somebody's day. Once I started seeing the platform that way, I could never really go back to seeing it as just software.
The Community matters for the same reason. Team '17 showed me that there was a much larger world around the products. Becoming active in the Atlassian Community gave me a place to share what I had learned, learn from other people and contribute beyond whichever company I happened to be working for at the time. The certifications later gave me another way to test myself, and contributing to Atlassian certification exam development felt like a strange full circle: the kid who learned by trial and error was now helping define how expertise in this ecosystem is assessed.
I do not think Atlassian replaced everything that came before it. The opposite happened. It gave all those previous experiences somewhere to meet.
Developer. Manager. Delivery lead. Administrator. Consultant. Architect. Community contributor. I can recognise all of those versions of myself in the work I do with Atlassian today. That is why, after fifteen years with Jira and Confluence, I still find new things to learn and new ways to use the platform to solve real problems.
Becoming an architect without deciding to become one
Today, 'Atlassian Platform Architect' is a useful description of much of what I do. But I still do not naturally think of myself as somebody who made a decision one morning to become an architect.
For me, architecture happened gradually. It is the accumulation of perspectives: the developer who wants to understand the implementation; the technical lead who sees dependencies; the people manager who knows that bad systems have a human cost; the delivery manager who cares about flow and priorities; the
administrator who knows how platforms behave in the real world; and the consultant who has seen the same problem appear in very different organisations.
I also still need to be hands-on. I like architecture, but I do not want architecture that exists only in a diagram or a slide deck. I want to understand the configuration, the automation, the API and the actual implementation. I want to be able to prove that an idea works, not only explain why it should work.
Architecture was not a career switch. It was the accumulation of
perspectives.
RSI: maybe my last dance
And that brings me to where I am today: Rush Street Interactive, the current chapter after another period of movement, change and learning.
I joined RSI at a very different point in my life and career from the developer who moved to Madrid in 2006 or the PHP developer who joined trivago in 2013. I am fifty now, and I have been doing this professionally for almost thirty years. I do not think very much anymore about what the next title should be. I think much more
about what I can still build, what problems I can help solve, what I can learn, and what I can leave behind for the people who work with what we create.
In some ways, I think of RSI as my last dance. Not because I have decided when my career will end - I have not - and certainly not because I intend to slow down. I mean it in a different way. If this is one of the last big chapters of my professional life, I want it to count. I want to use everything I have accumulated along the way
and still be curious enough to discover things I have never done before.
RSI is where many of the threads of my career now come together, and Atlassian is still at the centre of that work. I can think like a developer when I need to understand how something really works, like a manager when technology affects people, like a delivery lead when a beautiful solution becomes too complex to operate, like an Atlassian specialist when the platform needs depth, and like an architect when the problem is
bigger than Jira. JSM, Assets, Automation, Forge and AI are not separate interests for me; they are now
different parts of the same platform thinking.
Still learning from people
One thing RSI has reminded me is that, even after almost thirty years in technology, the people around you
can still change the way you look at your own work.
Mike has encouraged some of the experiments I started around AI and project reporting, taking ideas that
began as small initiatives and asking how we could turn them into something reusable. I value that because it
is not only recognition of an outcome; it is encouragement to keep experimenting and to turn an idea into a capability that can help more than one team.
Dustin has challenged me in a different way. Conversations about workload and responsibility have made me think about something I probably understood much less when I was younger: being capable of taking on more work does not always mean that you should.
Earlier in my career, growth often meant doing more, taking the next challenge and proving that I could handle it. Today I think much more about where I can create the most value, what deserves my attention, what should be shared or delegated, and how to stay useful for the long run.
That does not mean slowing down. It means becoming more deliberate.
Coming back to development
And strangely enough, one of the things I have chosen to spend that energy on is development again.
After years in leadership, delivery, consulting and architecture, I am back in the code - and, in a way I did not expect, Atlassian brought me back there. Today it can mean building a Forge application, working with APIs, designing backend validation, connecting Jira Service Management with Assets, automating a process, or
creating a prototype to prove that an architectural idea actually works.
There is something familiar in it, and I like that. For years, my career seemed to move progressively further away from development: developer, technical lead, manager, delivery, platform ownership, consulting, architecture. Forge and AI have created an unexpected loop back to where everything started.
The difference is that I return to development carrying everything that happened in between. I no longer look only at whether the code works. I think about the business process behind it, the people who will use it, security, maintainability, governance, scalability and what will happen when somebody needs to change it later.
The developer came back. He just brought the architect with him.
That is one of the things I enjoy most about my work at RSI today. The distance between thinking and building has become smaller. I can discuss a business problem, design an architecture, challenge the assumptions behind it and then open Forge and start proving whether the idea actually works.
AI as my pair engineer AI has changed that experience again. I increasingly think of the way I use it every day as a form of pair engineering.
Anyone who has done pair programming will recognise part of the idea. You are not working completely alone. There is another participant in the conversation: questioning, suggesting, checking, proposing alternatives and helping move the problem forward. In my case, one side of that pair is now AI.
I might be building a Forge application and use AI to explore an API, challenge an implementation approach, generate a first version of something, review code I have written, think through an edge case, or help me
understand why something is behaving differently from what I expected. Then I challenge the answer. We
iterate. Sometimes it is right. Sometimes it is completely wrong.
Knowing the difference matters. That is why I do not see AI as replacing engineering knowledge. If anything,
it makes experience more important. AI can produce an answer very quickly; experience helps you decide whether that answer makes sense, whether it is safe, whether it fits the architecture and whether it actually solves the problem you started with.
It does not replace the engineer. It changes what one engineer can
explore.
For me, the interesting part is the combination. AI is very good at exploring ambiguity, interpreting context and helping accelerate the journey from an idea to something tangible. Architecture still has to establish certainty: boundaries, security, ownership, permissions, data, maintainability and the rules that must behave
predictably.
AI handles ambiguity. Architecture handles certainty.
And then came AI - again
There is another reason this moment feels familiar. I remember the early Internet: you could tell that something important was changing, but nobody really knew where it was going to lead. You could wait until somebody explained the future to you, or start experimenting and learn while it was happening.
At eighteen, the Internet pushed me towards self-directed learning. At fifty, AI gives me a very similar feeling.
The technology is different. My instinct is exactly the same as it was when I was young: start learning.
What I like about this stage is that I am not simply applying what I already know. I am still developing professionally. The difference is that every new thing I learn now has almost forty years of previous experience to collide with.
Maybe that is what a last dance should be. Not repeating your best moves. Learning a few new ones while you still can.
Fifty
When I look back now, the path makes more sense than it did while I was living it.
The kid writing BASIC did not know about the Web. The webmaster in 1995 did not know he would become a professional developer. The developer did not know he would lead people. The manager did not know that Atlassian would become one of the strongest threads running through the rest of his career - not only as
technology, but as a community, a specialisation and eventually a platform for bringing all those previous perspectives together. And I certainly did not expect that, at fifty, Forge and AI would bring me back to
development again.
There was never a perfect roadmap. There were decisions, opportunities, mistakes, moves, people who trusted me, problems that forced me to grow, and technologies that kept changing underneath all of us.
Maybe I am entering my last dance. Maybe I am not. I genuinely do not know, and I do not need to know yet.
What I do know is that I want this part of the journey to count.
I want to keep building. Keep sharing. Keep learning.
Around forty years after BASIC and almost thirty years after technology became my profession, I still get genuinely interested when I find something I do not understand yet.
Maybe that is the one thing that has been consistent all the way through.
Same curiosity. More perspective. Still evolving.
Old? Maybe.
Obsolete? Not yet.
And the dance is not over.
The Atlassian Friend is a personal series by Antonio Ferruz about people, technology, careers, and the lessons learned along the way in the Atlassian ecosystem.
Same curiosity. More perspective. Still evolving.
