“Drupal’s Complexity Is Being Used to Make Things Simpler” — Jorge Tutor on Smart Scaling
Jorge Tutor isn’t just a CIO. He’s someone who has spent years translating complexity into clarity, both for clients and the teams that build their products. As co-owner of Metadrop, a company specializing in Drupal Development, Jorge has led the development of digital solutions for major institutions and organizations. But he’s just as invested in the people behind the code. A former Technical Architect who moved into software engineering, Jorge combines hands-on technical skill with a sharp eye for team dynamics, business needs, and long-term impact.
What makes his perspective stand out is how much of it comes from lived experience. He’s been an employee, a teammate, and an entrepreneur. He’s felt the pressure of broken processes and the relief of systems that actually work. Over time, his role has shifted from writing code to building alignment, helping teams and clients find shared understanding and avoid wasted effort. Whether through internal tools like Entity Mesh or his coaching sessions with leaders, his goal stays the same: make the work smarter, more sustainable, and more human.
In this interview conducted by Kazima Abbas, sub-editor at TDT, Jorge shares how his thinking evolved, the systems that changed the way his team works, and why clarity beats complexity every time. He opens up about leadership blind spots, the future of Drupal, and how playing music helps him reset. It’s a conversation packed with practical insight, shaped by years of doing the hard work and learning from every step.
TDT [1]: You started out as a software engineer but now focus more on helping others understand and lead technical work. Was there a specific point when you realised your role had shifted, or needed to?
Jorge Tutor: That's a great question. For me, it wasn't a single event, but a gradual realization. I still genuinely enjoy the craft of coding, so it was never about leaving something behind.
I started to notice that the satisfaction I got from helping a teammate overcome a challenge, or seeing our team grow in skill, was even greater than solving a complex problem on my own. It became clear that we needed to scale and improve.
The shift really solidified when I focused on our clients, especially non-technical ones. I’ve always believed that the best projects happen when we create a shared understanding. I found myself spending more time translating concepts, building that bridge so we could benefit from their domain expertise and they could understand the possibilities and constraints of the technology. When that clicks, you’re not just managing a project; you’re co-creating a solution.
That’s when you truly see the multiplier effect. The time spent clarifying a requirement for the team doesn't just solve one problem; it prevents ten future ones. That impact compounds daily. My role now is to create that shared understanding for our clients, ensuring the technology we build is perfectly aligned with the business results they need to see.
TDT[2]: You often mention using your own experiences as an employee, teammate, and entrepreneur. How do those different roles shape the way you teach or coach today?
Jorge Tutor: Those roles are not just hats I've worn in the past; they are perspectives I try to integrate every day. Each one taught me a crucial, and sometimes painful, lesson that directly shapes how I work with my team.
As an employee, early in my career, I reported to a manager who wasn't technical and showed no interest in tech. To win projects, he would often promise things that were incredibly difficult to deliver. This created a high-stress environment of constant overwork. That experience taught me my first and most important lesson: good technical practices aren't an academic luxury; they are a survival mechanism. They protect the project and the team's well-being in the long run. When I coach, I always start from this place of realism and sustainability.
As a teammate, I quickly learned that one person fighting for quality isn't enough. It's like the 'broken windows' theory, as soon as you let one standard slip, the whole structure can start to weaken. This taught me that coaching is about fostering a culture of collective ownership. It's about getting everyone to not only follow best practices but to feel empowered to champion them. My goal is to create an environment where the team holds the standard, not just me.
Finally, as an entrepreneur, you're responsible for everything from finance to sales. The temptation can be to lose touch with the technology. My past experiences made me determined to avoid that. I want to be a leader who understands the daily challenges of my team. This perspective taught me that leadership is a two-way street. I need to be able to coach my team, but I also need to be humble enough to be coached by them. We support each other, and we all learn from our mistakes together.
TDT[3]: You talk a lot about systems, things like RACI, Agile, or communication frameworks. What’s the first system you built that actually helped a team work better?
Jorge Tutor: Our team was already working with Agile principles long before we put a formal label on them, so the official adoption was a natural fit rather than a dramatic shift. I am referring to the agile principles, not the ceremonies that have always been controversial. At least it helps us explain better to our clients how we work using agile concepts, which in the end means working as a cohesive team, adapting to challenges, and embracing change (when it makes sense!).
Funnily enough, the first system that had a truly game-changing impact wasn't a management framework, but a piece of technology we implemented out of necessity: our first continuous integration server using Jenkins.
I vividly remember a time when, as a growing company, the owners—myself included—were regularly spending our weekends fixing critical bugs that would pop up on production sites. It was exhausting and completely unsustainable. We had automated tests, but developers (me included at that time) ran them on their own machines only when we recalled and creating the weel know “it works on my machine”. We were missing an objective, impartial gatekeeper, which led to the classic 'it works on my machine' problem.
Setting up Jenkins was the solution. It became our independent referee. Before any code could be merged, it had to pass a suite of tests on a clean, neutral environment. There were no exceptions and no opinions; the build was either green or it was red.
The change was immediate and profound. It wasn't a gradual improvement; it was a night-and-day difference. That system gave us our weekends back. It gave us confidence in our deployments and allowed us to focus our energy on building new features instead of constantly firefighting. It taught me a vital lesson: while principles and frameworks are the soul of how a team works, automated systems are the backbone that makes that work sustainable and scalable.
TDT[4]: You’ve been involved with Drupal for well over a decade. When you look at where Drupal is today with Drupal CMS branding, Drupal AI, ECA+bpmn.io, project browser, recipes, and other new initiatives, what stands out to you as a meaningful shift?
Jorge Tutor: The most meaningful shift is that Drupal is evolving from a powerful CMS into a polished and accessible framework suited with a miscelanea of modules, which lets us focus more on our clients' goals and less on reinventing the wheel.
For years, Drupal's power was in its flexibility as a developer's toolkit. We could build anything, but it often meant spending significant time on foundational work. Now, thanks to mature initiatives, we can build upon solid, evolving components that are improved with each Drupal version. This allows us to dedicate our energy to creating remarkable features that directly achieve client goals.
This shift is visible in several key areas:
- Project Browser and Recipes are lowering the barrier to entry, making it faster to launch sophisticated, pre-configured solutions.
- Drupal AI is empowering content creators and marketers directly within the platform.
- ECA (Event-Condition-Action) is a perfect example of this new focus. Instead of coding complex business rules, we can now use a visual tool like bpmn.io to map out workflows with our clients. This changes the conversation; we can discuss the logic and consequences of a process visually, ensuring we are building the right solution for their business.
Drupal has always been a robust and powerful platform. What's exciting now is that its complexity is being harnessed to make things simpler for both end-users and developers. This allows us to iterate faster, test new ideas, and ultimately focus on what truly matters: building software that solves real-world problems.
TDT[5]: In your Star Wars blog post, you said you wished more meetings worked like the rebel briefings. What do you think most meetings are missing today?
Jorge Tutor: I believe most meetings today are missing three fundamental things that those rebel briefings nail every time:
First, they’re missing a single, clear mission. A rebel briefing is about one thing: 'Here's the target, and here's how we're going to hit it.' Too many meetings happen without a clear purpose, or they try to solve five problems at once. We should only meet when it truly counts, with one defined goal that everyone understands.
Second, they’re missing the right crew. The rebels only have people in the room who are essential to the mission. Meetings today often have bloated invite lists. People are invited 'just in case,' which dilutes focus and wastes time. A meeting's effectiveness is often inversely proportional to the number of attendees.
Finally, and most importantly, they’re missing a 'mission-first' mindset. In those briefings, it’s not about ego; it’s about 'we win together or not at all.' That culture means everyone listens intently, and even the quietest voice is heard because a good idea can come from anywhere. The goal is to find the best solution, not to win an argument. When you have that alignment, the coordination becomes snappy and clear, and you get decisions in minutes, not hours.
TDT [6]: There’s been a growing conversation around developer experience and the onboarding gap. What do you think the community still gets wrong—or overlooks—when it comes to making Drupal easier for newcomers?
Jorge Tutor: Drupal's greatest strength is its flexibility. It's a powerful ecosystem where you can build amazing things with or without code. However, this freedom can be overwhelming for newcomers. There are often multiple modules that achieve the same goal and a specific "Drupal way" of doing things that isn't immediately obvious. It's like a kitchen full of incredible ingredients; a new chef needs a recipe before they can start improvising.
At Metadrop, we bring in interns every year who know nothing about Drupal, and within months, they start building their own solid projects. We've found that success comes from a combination of approaches:
- Learning by Doing: The best way to learn is by building. I always encourage people to dig into Drupal core and the Examples module. This provides practical, best-practice patterns that are more valuable than any theoretical document.
- Leveraging Formal Training: While doing is key, you can accelerate the process immensely with structured learning. The official documentation is great for core concepts, and we encourage everyone to contribute to it, especially for smaller modules. Additionally, professional training resources like those from Forcontu are invaluable for getting a solid foundation. We are even launching our own training platform at Metadrop soon to cover specialities like automated testing.
- Embracing the Community: You are never alone in the Drupal world. The community is incredibly welcoming. When you get stuck, there are issue queues, Slack channels, and Drupal conferences full of people who are genuinely happy to help you find the "Drupal way" and get you unstuck.
Ultimately, we don't need to shield newcomers from Drupal's power. We need to give them a clearer map to navigate it, combining hands-on projects, structured resources, and the incredible support of the community.
TDT [7]: When you see discussions around decoupled Drupal, composable architectures, or even site builders like Gutenberg or Layout Builder, where do you think Drupal should draw the line between flexibility and complexity?
Jorge Tutor: The line shouldn't be a rigid boundary but a commitment to empowering choice. The mistake is searching for a single "silver bullet" solution when Drupal's very essence, like its water-drop logo, is to be fluid and adaptable.
Drupal provides a spectrum of powerful tools, but it rarely forces your hand. You can build a fully decoupled site, but you don't have to. You can use Layout Builder or the new Dupal Canvas, but you can also stick to traditional theming. This is the magic of Drupal. It provides a professional-grade toolkit for architects who need maximum flexibility, alongside intuitive, user-friendly experiences for editors who need simplicity.
The real beauty of Drupal is that this flexibility is governed by the open-source ethos. Good ideas can come from anywhere. You can develop a module that sets the new standard and eventually gets integrated into the core. If a project is too complex or rigid, it won't gain traction and will fade away. The community naturally favors solutions that are both powerful and usable.
Drupal's approach is to trust its builders. It provides the freedom to choose the right architecture for the job, backed by a robust community ecosystem that ensures the best solutions are the ones that survive and thrive. Project pages with their integrated issue queues and GitLab CI create a level playing field. It fosters collaboration and allows the best ideas to rise to the top, ensuring that the tools we use are battle-tested and community-approved.
TDT[8]: With Metadrop, you’ve worked on many custom modules and tools. Has your approach to building for Drupal changed as the platform itself has matured?
Jorge Tutor: Absolutely. Our approach has evolved dramatically, mirroring Drupal's own maturation from a self-contained CMS into a modern, flexible content framework.
In the past, let's call it the Druplith era, the instinct was to solve every problem inside Drupal. We'd build large, custom modules that handled everything from business logic to the final presentation. The entire project operated within a single universe, which could lead to complexity and challenges during major upgrades.
Today, our mindset is significantly different, largely thanks to Drupal's embrace of the wider PHP ecosystem. The integration of components from frameworks like Symfony and the power of Composer have been game-changers. Our thinking has shifted from 'How do we build this in Drupal?' to 'What is the best tool for this job, and how does it integrate with Drupal?'
This leads to a 'contribute first' development approach that benefits everyone. When a client needs new functionality, our first step is to check if a suitable Drupal module or PHP package already exists that we can contribute to. If not, we design our solution from the ground up to be modular. We create small, focused, and reusable modules for the core functionality and contribute them back to the community. Then, we keep only the client's specific business logic in a separate, lightweight custom module. This approach helped to develop over 100 contributed Drupal modules on Drupal.org.
This is a huge win for our clients. It means they aren't locked into a proprietary solution that only we can support. Instead, the core of their new feature is backed by the global Drupal community, which dramatically lowers long-term maintenance costs and makes future upgrades seamless
TDT[9]: Metadrop has been around for over 15 years. That’s a long time in tech. What has helped the company stay relevant and steady through all those changes in tools and client expectations?
Jorge Tutor: That’s a question we reflect on often. In an industry where companies can come and go in a few years, staying relevant for over 15 years requires a very intentional approach. For us, it has come down to three core principles.
First, we are partners, not just developers. Our philosophy has always been to get deeply involved in every stage of a client's project. We learn from mistakes and celebrate successes together. Technology is constantly changing, but the need for a trusted partner who can help navigate those changes is constant. That focus on the relationship over the transaction has been our foundation.
Second, our commitment to Open Source is our greatest strategic asset. We are deeply invested in the Drupal community, and that’s not just for ideological reasons. Actively contributing keeps us at the forefront of the platform's evolution. It attracts talented, passionate people who want to be part of something bigger than just a job. And it means we’re not just using a tool; we are helping to build it. This gives us an incredible depth of knowledge that our clients rely on.
Finally, we have made learning and pragmatic evolution part of our DNA. We’ve always been loyal to Drupal, but we’re not dogmatic. We embrace good ideas from anywhere, which is why we were early adopters of Agile methods and why we integrate best-in-class tools from the entire PHP ecosystem. We dedicate time for every team member to research and explore new technologies. That constant curiosity is what has allowed us to adapt from one era of the web to the next without losing our focus on quality and sustainable practices.
These three pillars—partnership, open source, and continuous learning—are what have kept us steady and relevant.
TDT [10]: “Content First” is a simple idea, but it solves a real issue. What led you to build that module? Was it based on something you kept seeing in projects?
Jorge Tutor: That module came directly from a common conflict we see in so many web projects. With all the amazing new tools for building beautiful landing pages, it's easy for conversations between clients and developers to focus entirely on the presentation—the visuals, the layout, the user experience. While those things are critical, we risk forgetting that websites are, first and foremost, about content.
Historically, content was often just seen through the lens of SEO, sometimes leading to practices like keyword stuffing. But in the current AI era, clarity and substance are more important than ever. Your message needs to be sharp, clear, and free of noise to stand out. The ultimate success of a website is measured by its results, and those results are driven by powerful content, not just by the technology behind it.
We built the Content First module to solve this exact problem. It’s a simple tool that allows anyone—a client, a copywriter, a project manager—to see exactly what a page is saying to the world, completely free of visual distractions. It forces you to evaluate the substance: Is the message clear? Does the semantic structure, like the headings, make logical sense?
To make it even more practical, it includes tools to instantly copy or download the text, so a copywriter (human or AI) can refine or improve it.
The best part is seeing the community take the idea and run with it. Recently, contributors added a feature to download content from multiple pages at once, which is a fantastic improvement. It's always an amazing feeling when a simple tool you built to solve your own problem is embraced and enhanced by the community. A huge thanks to them for that.
TDT [11]: With “Entity Mesh,” you get a live map of how content is connected. What kind of problems were you trying to solve when you first built it? Was it inspired by the concept of business process management notation (bpmn 2)?
Jorge Tutor: While Entity Mesh does have visual similarities to BPMN in how it maps complex systems, its original inspiration actually came from a different place: Google Analytics.
The initial goal was to solve a marketing and content strategy problem. We were looking at traffic funnels in Analytics and realizing we were analyzing user flow after the fact. I wanted a tool that would allow us to be intentional and design that user flow from the beginning. The first version of the module was built to visualize the organic links between nodes, creating a map of how we intended visitors to move from acquisition pages toward conversion pages.
However, once we started processing all that link data, we realized we could do so much more. The node visualization is now just one part of the module. By analyzing the content directly, we can now provide reports on broken links, access-denied links, and even inventory things like phone numbers or iframes used across the site.
This internal analysis is a powerful complement to external, third-party SEO tools. Those tools scan a site from the outside, but Entity Mesh works from the inside, leveraging Drupal's complete knowledge of its own data. This gives us a level of accuracy that crawlers can't match.
The module is still growing. We plan to add content statistics, find orphaned nodes that aren't linked at all, and expand support to other entities like taxonomy terms and Commerce products. It started as a funnel visualization tool and has evolved into a comprehensive content auditing and architecture platform.
TDT[12]: Can you give an example where Entity Mesh helped your team—or a client—notice something that wasn’t visible otherwise?
Jorge Tutor: Certainly. Entity Mesh has become an essential diagnostic tool for us, revealing critical information that is otherwise buried. Here are a few real-world examples of how it provides immediate value.
- Validating Complex Content Migrations: For large website migrations, ensuring that all internal links are correctly updated is a massive challenge. Tools like Drupal's Migrate and Redirect modules are fantastic for handling the technical transformation, but Entity Mesh provides the final, crucial validation. After a migration, we can instantly generate a report of all content links. This allows us to spot any remaining self-references to the old site or confirm that every link points to its new destination. It’s a mandatory final check for us to guarantee the migration has been done successfully.
- Preventing Broken Links and SEO Penalties: Content editors are constantly creating, archiving, and deleting content. A common problem is an editor deleting a page without realizing it was heavily linked from 15 other articles, instantly creating broken links that harm the user experience and penalize SEO. With Entity Mesh, an editor can now see a page's connection map before deleting it. If they see it's highly referenced, they can think twice, perhaps updating the linking pages or setting up a strategic redirect. It’s a proactive way to maintain site health.
- Strategic Conversion Funnels: Let's say a client wants to drive more organic traffic to a key conversion page, like a "Request a Demo" form. Before building a new campaign, we use Entity Mesh to see the current state. We can instantly visualize which blog posts, case studies, or service pages are already linking to that form. This map allows us to be highly strategic, identifying high-traffic pages that aren't linking to the form and represent a missed opportunity. It helps us build powerful internal linking strategies with precision.
In Europe, GDPR regulations around cookies are mandatory. Many third-party services embedded via iframes—like videos, maps, or social media feeds—can place cookies that require user consent. Identifying every single iframe across a site with thousands of pages can be a nightmare. Because Entity Mesh inventories all content, it can instantly provide a site-wide report of every iframe in use. For clients concerned with compliance, this is a critical risk-reduction tool. We can provide a complete audit of all third-party embeds, helping them ensure their site is fully compliant with regulations like GDPR.
TDT[13]: In your post on “The Illusion of Stability,” you challenge the idea that systems are stable just because they’re not changing. How do you know when something needs to be challenged, even if it seems to be working?
Jorge Tutor: My core belief is that true stability is an illusion. In any project, team, or company, there is no static state. You are either getting better or you are getting worse. You know something needs to be challenged the moment it gets too comfortable. "Working just fine" is often a mask for stagnation.
The biggest red flag for me is a lack of healthy tension. This looks like: There are no new challenges or difficult situations, no one is asking tough questions, meetings are too quiet, and decisions are too easy; the team is recycling old solutions for new problems.
You have to introduce a little bit of challenge, because real progress only happens outside of your comfort zone.
TDT[14]: When you run 1-on-1 sessions with leaders, what’s something they often don’t realize is holding them back?
Jorge Tutor: The most common blind spot I see is that leaders have unintentionally made themselves the single point of failure for their team. Leaders often come to me because they feel overwhelmed and don't have time for their real job, which is to support the team, improve communication, and guide the project's strategy.
What they often don't realize is that they have cast themselves as the "Rescuer" in the team's story. Whether it's driven by stakeholders demanding a single point of contact or their own desire to always deliver premium value, they have created a system where every decision, piece of information, or task must pass through them.
This creates two huge problems: They become the bottleneck; The team can't move faster than the leader can approve, and the leader is perpetually swamped. They block their team's growth:
Every time a leader does a task that a team member could have learned to do, they are robbing that person of a valuable learning experience. It feels like a good short-term strategy to ensure quality, but it's a terrible long-term strategy that creates dependency.
My role is to help them see this pattern. I do this by asking questions, which can sometimes feel tricky, but it's the best way to help them discover the solution themselves. I might ask, "What would happen if you were on vacation for two weeks with no internet?" or "Walk me through what would need to be true for your team to handle that task without you."
The breakthrough happens when they shift their mindset from "I am the one who does" to "My job is to create a team that can do." That’s when they start to truly delegate and lead.
TDT [15]: Many leaders want to manage tech projects, but don’t have a coding background. What’s the one skill or mindset shift that makes the biggest difference for them?
Jorge Tutor: The single most important mindset is to be curious and respectful. Many leaders without a coding background feel they must lead with authority to compensate. The most effective ones do the opposite. They don't pretend to have all the answers; instead, they cultivate a deep curiosity and learn to ask good questions:
- "Can you help me understand the main challenge here?"
- "What are the trade-offs with this approach?"
- "What does the simplest version of this look like?"
This approach builds trust and uncovers risks because it empowers the real experts, the developers, to share their insights and concerns safely.
Interestingly, having some coding knowledge can be a double-edged sword. While it can be helpful, a leader might unintentionally impose their own technical preferences, which could be outdated or not the best fit for the problem.
Ultimately, the key is to create a learning balance. A non-technical leader should be open to learning the fundamentals from their team to better understand the landscape. In turn, they should teach the team about the business context, the "why" behind the project. When everyone is both a teacher and a student, the client relationship transforms into a true partnership. It stops being about ordering features and becomes about co-creating the best solution to their business challenge.
TDT[16]: Is there a skill, craft, or topic you’re quietly exploring on your own, something unrelated to tech or work, but meaningful to you?
Jorge Tutor: Yes, definitely. I've been reconnecting with music lately, getting back to playing the guitar and drums. For years, I played guitar in a metal band, we were called Today Ends Dying, and while those days are behind me, the feeling of getting lost in the music has never left.
For me, it’s the ultimate way to disconnect. You can’t think about a project deadline or a client email when you’re trying to nail a complex drum pattern or a guitar riff. It forces a different kind of focus, one that's creative and immediate.
Recently, I’ve been getting together with friends to play some covers, just for the fun of it, and it has been incredibly rewarding. My next goal is to introduce my kids to the world of making music. It's less about them becoming rock stars and more about sharing that feeling of creating something together.


