Sergio Gago – CTO, Guitarist, and Reluctant Frontman

There’s a reason great teams feel like great music bands, or viceversa. I’m not talking about the dysfunctional ones where the bassist walks out mid-tour because the drummer slept with his girlfriend. Or the dysfunctional teams where everybody is fingerpointing each other (note to read Lencioni’s “The Five Dysfunctions of a Team”). I mean the ones that click—where people listen, build on each other, and create something far greater than any solo effort. Regardless of the genre.

Business teams, like bands, aren’t a collection of rockstars. They’re ensembles. And the best ones groove like legends. From hiring to performing all the way through forming, storming and norming. There are tons of analogies that one can take from the other.

When hiring people, I have a bias towards musicians because of this (and if you are reading, don’t sweat, I’ve built internal mechanisms to mitigate that, ha!). And the reason is because the attitude and ethos required is pretty similar. You can call it a proxy indicator, oftentimes better than your Github pattern of green.

So, in every band team, you’ll find archetypes:

• The Bassist: Holds down the groove. Not always visible, but you surely feel them. This is your backbone— For example the reliable platform engineer or ops person who makes sure nothing collapses when the tempo shifts. This person needs to be in the key, fully embedded in the team. Sometimes can shine when nothing else cuts through the mix. The best songs always have a steady bass line that is remembered for ages. (Try listening to RHCP without Flea at the bass and you will know what I mean)
• The Drummer: Keeps time, drives the rhythm. Perhaps the project manager or scrum master. When they’re tight, everyone else stays in sync. When they’re off? You’re in chaos. Even when you play in odd times or when you are jamming they are what keeps the pace. A drummer is process oriented. Keeps eye contact, and you know, when the audience (the client) claps at the wrong time they are able to adapt the groove to the public. Then the other musicians can adapt as well. Some companies have punk drummers, some have jazz ones, everyone dreams of having a Bonham. But the personality is very typical. Give them a bpm that they’ll kick off a rythm in their minds. Identify them by rapid calculations, excel spredsheets and tight structure. Does the groove need to change on the chorus? They will bring the band along for that rythm.
• The Rhythm Guitarist: Steady. Crunchy. Creates the actual value of the product and also fills the gaps. Your favourite riffs? They usually come from the rhythm guitar player. Everybody knows Angus, but Malcolm was the real deal. A fullstack developer who can solo if required but is truly the meat of the product. Your core features, your end to end understanding of the product. Filling the sound spectrum with what’s missing. This person can build structure while letting others shine. Most of the times they are the ones who stay in the band for longer and know all their songs by heart. Notes and feel.
• The Lead Guitarist: The technical wizard. Riffs when needed. But here’s the catch— knows to solo only when the song needs it. No need for 12 minute shreeding. This is the Jennifer Batten next to Michael Jackson, or EVH. In business, that’s your principal engineer or domain expert. Sometimes a lone wolf. A technical lead that can get pulled during a major client incident or downtime. They typically can’t keep the same pace and shredding for too long (unless they are Dragonforce or Dream Theater), so use them with caution. The rest of the band works as a build up for their performance but if not tamed they could alienate the rest of the band (“I’m playing myxolidian on the high range, just stay at your palm muted power chords!” is the new “don’t do anything else before you make things worse, just let me fix this”)
• The Vocalist / Frontman: The face of the group. The showman. People may think is the one that does everything but a capella may not be the best show ever (Unless you are Freddy, of course). This can be your product manager, your client lead, sales, or your team lead in general. It is the one grabbing the mic and connecting to the crowd. Empathy is their name. They can read the public and create the words that move people. Sometimes it can be one of the other band members (in my case I’m an average rhythm guitar and mediocre vocalist!). Who said two roles are incompatible for the same person? This person is an extrovert, can do conferences, can sell, loves to be on the spotlight and craves it. Knows that ethos, pathos and logos are the fundamental ingredients for everything. Looks like the star, but without the rest of the band? Karaoke at best.
• The Keyboardist: Adds color, mood, depth. Fixes the song. Sometimes overlooked and when composing sometimes they just add the final touches at the end instead of right at the beginning. The product wouldn’t feel whole without them, or would not feel at all (Imagine “Jump” by Van Halen without the keyboard! or Flake from Rammstein). They think end to end. How people will benefit from the product and they adapt their instrument to the song. They tend to have amazing skills and musical knowledge (sometimes are the only ones with musical training in the band, like PhDs in your company!). They help with the overall arrangement and oftentimes suggest improvements to their bandmates. Think data scientists, UX designers, frontend developers, etc.

Everyone needs their moment. Not everyone gets a ten-minute solo. But they all make the track.

Play for the Song, Not for the Ego

Bands that work well understand this: you don’t play for your instrument, you play for the song. That includes the lyrics and the vocalist. In business, too many teams get trapped in instrument-first thinking. “I wrote 300 lines of code today,” says one dev. “I closed a ticket,” says another. “It works in my machine” repeat the rest. Great. But did we move the song forward? Did the crowd dance? If the public is not dancing your job is not done.

True collaboration is about listening to each other and to the public. Adjusting. Backing off when needed. Hitting hard when it’s your turn. No amount of virtuosity saves you if you’re off-tempo or playing in the wrong key. And it is ok to miss a note or a beat here and there! As long as you fix it as a team.

Rehearsals are like stand-ups. Neat, predictable, relatively safe. But when you go live—whether that’s a client meeting, a product launch, or a conference demo—everything changes. You might miss a chord. Hit a bug. Forget your lines. Doesn’t matter. Keep the groove. Smile. Most of the audience won’t notice—unless you make them do. When playing live I had a tick that my teacher helped me solve. Whenever I made a mistake live I made a face, a small wink (a kind of mental f**k!). And that face was what gave away the mistake. Should I kept going like nothing happened people would have thought I was just playing a disonant jazz chord on purpose.

Execution isn’t about perfection. It’s about resilience and flow. You need stage presence in business too. A live concert is a whole set not just one song.

The Axis Progression of Projects – All about the Flow

Let’s talk music theory for a second. The I–V–vi–IV progression (Axis of Awesome, anyone?) is the backbone of more pop hits than you realize. That is, four chords that put together allow you to play absolutely everything. From Eagle-eye Cherry to James Blunt or Justin Bieber. Absolutely terrifying but useful on a campfire evening when you are 17 and you are playing guitar to… make friends…

Music, like business projects and teams are also about flows. Most of the times is not about the absolute number (a KPI, Revenue, Project status) but the differential and how that flows with the ecosystem. The interval when you play a C and a G note (a perfect 5th) sounds very similar to the interval when you play an E and a B right after. In companies you can ascend the scale chromatically (one semitone at a time) or through crunchtime in startups you ascend octave by octave.

What does that have to do with chord progressions on teams? This is how the progression typically works:

• I (Tonic) – It’s Home. Stability. The kickoff of your project. Strategy meetings. Scope. Calm before the storm. The place you leave, the place you will want to return.
• V (Dominant) – Tension builds. Engineers are stressed. PMs are sweating. Customers want features you never promised. Deadlines approach or are missed. Something is slightly dissonant.
• vi (Submediant) – The emotional phase. Burnout sets in. But you pivot. Find a new angle. Add nuance.
• IV (Subdominant) – You stabilize. Deliver. Reflect. Close the loop… and begin again.

This never ends. Companies live in these cycles. Good teams learn the rhythm and use them for the better. Bad ones stay stuck in the bridge forever.

🎸 Final Riff

Music has no shortcuts. You don’t become a decent player without rehearsal, trust, and the courage to play in front of others. Exactly the same goes for business. So next time you’re assembling a team, don’t ask if they’re rockstars. Ask if they can groove, listen, and serve the song.

Because in the end, the crowd doesn’t cheer for solos. They cheer for the song, for the band and the overall performance.

(Post inspired by Ozzy. Long live the prince of darkness. Thanks for all the good moments.)

It is 6am, at least somewhere in the world. I am in a transatlantic flight on and I refuse to count the number of miles. I am a “road warrior” as they say. Spend two to three weeks per month traveling. And that affects my health specially with the food I eat. Like many people, I decided to start taking that seriously and went to hotel gyms and started looking at my diet. Specifically, counting calories and macros. Now, that can work great when you are home, but when you travel so much it is very difficult to “count calories” or really know what you are taking in. The usual tools don’t cut it. So I decided to fix it. What if I could send a whatsapp picture to a tool and automatically have all the information gathered, macro nutrients, energy, etc. And recommendations for my diet done? So, as I was around Greenland I started vibe coding my new app. Created a whatsapp number, built the whole app and connected to some nice LLMs, tested it on the plane with the food they served me… et voila! I just had in a matter of 3-4 hours a full application that served my purpose (and still does). For almost no money and most importantly. Without seeing a single line of code. Only writing in english what I wanted.

Should I claim this “app” is a business? Of course not. Probably it only serves me and my need today. But again: I built it, to my needs and taste, in a few hours and with very minimal money investment (maybe 10$ in tokens and opening an account on Twilio). And I created more value to myself than many other apps I should’ve gone out and research and evaluate.

We are in that point where careers are redefined. Where some people will lose their jobs and some will end up building multi billion dollar companies. The whole paradigm is changing completely. Some are realizing that but some others are still thinking they are safe.

But let me start from the beginning.

Software Engineering was always considered a craft. A type of art that helped people create new things. Worlds, systems, operations, applications. You name it. We were creators. And with that came a sense of pride. We loved what we typed. It’s poetic structure. Its maintainability. We saw ourselves as smart mammals capable of building mutable machines that replicated the world and were able to mutate into complex systems that solved the world problems. From trading algorithms, to dam-flood-control systems, all the way to dumb mindless mobile app games. 

We have been always looking for the best and most efficient way to solve a problem. Sometimes holistically, sometimes within a specific realm. We have added layers and layers of abstraction between us and what runs our programs and expanded our reach to the whole internet. From managing the inner layers of the memory and our CPU cache, to super high level javascript abstractions where we don’t even need to think how to trim a string.

As new companies were built and digital was the new natural, we were sought after like scientists in the era of the Manhattan project. Companies paid more and more for software developers. University degrees did not matter that much anymore. Bootcamps started popping up everywhere so that people could reinvent their careers and join the gold digger fever. Parents wanted their 6 year olds to speak Python before english. Thousands of people changed careers to be part of the new cool. Software development was the quickest way to make a six figure salary. Move away Wall Street. Here come the coders.

Over time we have matured the industry. We have created career ladders, organizational frameworks, quality systems, design processes. And whole charts that make a “path” for any new entrant to know what’s ahead. From junior engineers, to staff, to CTOs and VPs of Engineering. Beautiful stuff. Now we know how to build stuff, how to organize ourselves and how much it will cost (well, not quite. It is still a very immature business, but you get the idea).

And suddenly everything changes. The rules of the game are completely thrown away. Suddenly your QA processes are completely automated. Your frontend development ends up being a commodity and you require a fraction of the man power you needed back then (ironically, we are back to the “surgical team” concept by “The Mythical Man Month”). I am not talking about “vibe coding” a prototype like my experience at the beginning of the article. But about the whole rearchitecture of the Software Development Lifecycle.

In the past (present) we built software in a variety of ways. But they all boiled down into the same concept. There is an idea or request, a design phase, a development phase, testing or certification, deployment and monitoring and feedback. Depending on your flavour the phases can change order or intersect each other. Testing may precede development just to take over right after. You may deploy continously, or do the process in very small chunks for quick iterations and feedback loops. OR you can just shoot from the hip and deploy what a product manager fancies whenever it is safe for customers. But from a high level it all does the same thing. Code, Build, Deploy, Repeat.
And because our platforms have become so complicated, we have especialized ourselves in ways that we could not even think of ten years ago. A fullstack developer is now regarded as a shallow generalist. Frontend developers focus in unique frameworks following their own cargo cults. Data has its own universe and don’t get me started with mobile development. Specialization, like anywhere else, brought depth, capabilities and access. But value only came in certain cases. Many teams ended up building technology for the sake of technology instead of customer driven value.

And now, at the dawn of Agentic AI we see that the two three most important and ROI generating use cases are around streamlining (and replacing) customer support flows, QA in software development and the muscle of building the actual software. The princesses of the industry, the high salary individuals that were sought after like financial quants in the late 90’s… are now being automated.

I am not talking just about using Github Copilot or other tools to be faster and more accurate. I am talking about a full replacement of the engineering pipeline. Imagine a system that:

1. You write a detailed flow on how you want your application to behave (say, a web application). You describe it in good detail (with your voice). Flows, interactions, users, etc. An LLM gives you a near perfect Product Requirements Document that is better and more complete than what any product manager has ever created. Of course you can iterate, add and change things, give more context and examples, etc. All until you get your desired outcome.
2. You give that full PRD to your vibe coding system of choice. Now there is enough players in the market to get them to fight for new and better features and models continuously. It is not about one of them being the best today. It is about keep the race on and cost low. With that you achieve a playable and deployable prototype (or even a hint of an MVP) that you can show to people. Investors, clients, or your grandmother. This is your first feedback loop. You are recording those sessions of people using it and giving the feedback to your system in point one. With that feedback it will refine the PRD and then you can build the v2 of your prototype. Rinse and repeat until happy.
3. Now you have a full Product Definition Document, user stories, acceptance criteria, working prototypes (instead of just a mockup). So you can create that document in a Markdown document and put it in an empty Github repository. The party starts.
4. A project manager agent will divide the work in small chunks and will order it properly with dependencies. Then it will create automatically Github issues (if you prefer JIRA that’s on you). With unique and specific definition and description of what is intended. 
5. Whenever a ticket is created, an army of “AI Coders”, that are just waiting, start picking up tasks. You can parallelize them if you want. They will write the tests, build the code, make the build, fail, iterate. Test Driven Development becomes the norm now. When a task is completed as per the acceptance criteria, they send their code to the repository in a Pull Request.
6. Another agent reviews the pull request. It may have flaws, it may not run properly integration or end to end test. If so, it send it back to the agent developer. Keep iterating until it can be merged.
7. The last agent takes the latest tag with all the PR’s integrated, makes the build and deploys it into production. YOLO. A monitoring agent that’s hooked to your profiling and APM solution of choice detects any error immediately by reading the logs before a human has even looked at his pagerduty. Creates an urgent ticket, a developer agent fixes it, PR, deploy, repeat.

That cycle typically lasts weeks for many companies. Months for large enterprises. Here, this is done in minutes or hours. Continously, 24/7, 365 days per year.

We are effectively redefining everything. The concept of technical debt, of migrations and upgrades. Of on-call rotations. Even of Agile and bloody SCRUM (about time we start opening that can of worms). 3 weeks to provide value units to customers? I want 3 hours! All the roles in the software world are changing in front of our eyes. The technical lead, the testers, backend, frontend, DevOps…. The agents learn from us, connect from us and react better and faster than us. We just define what we think our customers want.

Am I being optimistic? perhaps, but I am seeing those systems already working at a small scale. Startups that would have required a quarter of a million to start moving, now they just need a savvy builder and a couple billions of tokens (and a fraction of the time). And this is just the beginning. ChatGPT came out end of 2022. 2023 saw the advent of LLMs everywhere and in 2024 many companies went into production with their use cases. 2025 and beyond is where Agentic AI is taking over. New and better models come every month, improved frameworks, etc. Things can only improve. How are you going to adapt to this new reality?

Software engineering is dead, long live software engineering.