Da consulente di marketing a programmatore: perché ho attraversato una linea che quasi nessuno attraversa
The short version: After more than a decade consulting brands on branding, marketing, and communications, both agency-side and independently, I kept hitting the same wall: developers who could build almost anything, but rarely understood why a marketing or design decision mattered in the first place. The translation between us cost real time and real money, over and over, across different teams and different years. Eventually I stopped hiring the gap and started closing it myself.
The wall I kept hitting
Over twelve years across branding, marketing, and communications, I worked both sides of the agency world: inside agencies serving many brands at once, and independently, consulting directly. Different rooms, different clients, same wall.
I would hand off a strategy, a piece of design thinking, a reason a headline had to say exactly what it said, and watch it arrive on the other side of the build changed in ways that mattered. Not maliciously. Just lost. A developer would simplify something for technical convenience and not realize they had quietly removed the point of it. Or they would build exactly what was asked for, literally, without understanding the "why" behind it, and ship something technically correct and strategically wrong. Or the two of us would spend days translating a piece of strategy into a brief a build team could work from, and something would still slip through that back-and-forth. Or the work would be technically excellent and completely indifferent to what it actually did to conversion or to the brand.
None of these were one bad developer or one bad month. They were the same failure, wearing different clothes, on repeat, across different teams and different years. Every time it happened, it cost time, and it cost money, and worse, it cost the client a version of the work that was quietly worse than the one that had been designed.
Why hiring around it never fixed it
The obvious fix looks like hiring better, briefing harder, or finding "the right developer." I tried all three, more than once. They help at the margins. They do not fix the structural problem, which is that a brief is a translation, and every translation loses something. The person receiving it was never in the room where the decision was made, so they fill the gaps with their own reasonable guess, and reasonable guesses drift.
That is not a hiring problem. It is a distance problem. The only fix that actually closes it is removing the distance: putting the person who understands why the decision was made in the same seat as the person building it.
The decision
So I made the decision that most people in my position do not make. I stopped handing the build off, and I learned to do it myself.
There was no bootcamp and no course behind it. I taught myself directly on real work, building for real projects as I learned, rather than practicing on throwaway exercises first and applying it later. It was slower and messier than a structured course would have been, and it meant learning in public, on work that mattered, with no safety net between a mistake and a client seeing it. It was also the only way that actually closed the gap, because every project I built was a real test of whether the strategy had survived the build, not a simulation of one.
What actually changed
The difference was not that my code became better than a specialist developer's. It rarely was, and I never claimed otherwise. The difference was that nothing got lost anymore. The reasoning behind a decision did not need to survive a handoff, because there was no handoff. The person who understood why something mattered was the person who built it, so the "why" never had to be translated, and never had a chance to drift.
That is the whole case for crossing the line from consultant to coder. Not that one person can out-build a specialist. That one person holding both ends of the same decision stops losing what a relay always loses.
Domande frequenti
Perché il problema non era la qualità degli sviluppatori con cui lavoravo. Era la distanza. Un brief è una traduzione, e ogni traduzione perde qualcosa, indipendentemente da quanto sia capace la persona che lo riceve. L'unica soluzione reale era eliminare del tutto il passaggio della traduzione.
Diversi fattori sovrapposti, tutti ricorrenti: l'intento di design e UX silenziosamente eliminato per comodità tecnica, lavoro realizzato esattamente come richiesto alla lettera senza comprendere perché fosse importante, un continuo scambio lento e costoso per tradurre la strategia in un brief tecnico, e un lavoro tecnicamente solido che ignorava l'effetto reale sulla conversione o sul brand.
No. Ho imparato da autodidatta direttamente su progetti reali, costruendo per lavori effettivi dei clienti man mano che imparavo, invece di esercitarmi separatamente in anticipo. È stato più difficile, ma ha significato che ogni competenza acquisita veniva messa alla prova immediatamente su un lavoro che contava davvero.
Non è privo di rischi, ed è stato più lento in alcuni punti rispetto a quanto sarebbe stato un corso strutturato. Ma era anche l'unico modo per verificare davvero se un elemento di strategia fosse sopravvissuto alla realizzazione, perché non esisteva un progetto sostitutivo al posto di quello reale.
No, e non è mai stato quello il punto. L'affermazione non è mai stata che potessi costruire meglio di uno specialista. Il punto era che occuparsi sia della strategia sia della realizzazione significava che il ragionamento dietro una decisione non doveva mai sopravvivere a un passaggio di consegne, perché non c'era alcun passaggio di consegne da cui sopravvivere.
I dettagli restano miei, ma passare da una carriera di consulenza già affermata alla realizzazione pratica non è una mossa comune, ed è corretto dire che ha suscitato più di una perplessità. Sono stati i risultati a chiudere la questione.
Entrambe le cose. La mia esperienza era specifica a me, ma il problema di fondo, cioè che un brief perde informazioni ogni volta che cambia mano, non è affatto specifico a me. È lo stesso motivo per cui Thabrew Effect è costruito attorno a un solo titolare che tiene insieme strategia, design, realizzazione e crescita.
No. La lezione non è "tutti dovrebbero programmare". È che ovunque una decisione debba attraversare un passaggio di consegne, qualcosa rischia di andare perso, e la soluzione è eliminare quel passaggio oppure assicurarsi che il ragionamento lo accompagni deliberatamente. Per me, eliminarlo è stata la scelta giusta. Non sarà la scelta giusta per tutti.