Image generated with ChatGPT
“Being brutally honest, describe my most obvious shortcomings”
The other day I asked ChatGPT to analyze me based on everything we have been working on for months, everything it already knows about me, which is quite a lot.
The response was unusual for being honest. I expected it to deny me by flattering me or to try to turn my flaws into strengths in the manner of modern self-help trends.
To my surprise, it didn’t uncover anything that sounded foreign to me, but that didn’t stop me from feeling a certain discomfort (even embarrassment) when reading that critical X-ray that puts me in a compromising situation. Eduardo, you keep building and can’t keep up; you dedicate yourself to perfecting everything without having validated whether that idea is worth it; you are unable to delegate if the decision is really important; you have no trouble protecting technical quality, but sometimes you underestimate the value of what you deliver.
My first reaction was a “yeah, but” that I didn’t even believe myself. A bit of that vanity we hide deep inside and that we often dress in false modesty. After all, I have been developing software for over twenty years, fifteen of them as a freelancer. I have worked with organizations of all kinds, from SMEs to multinationals, including public administrations. I have solved complex problems: migrations, performance issues, convoluted integrations, legacy projects…
The curse of being able to build almost anything
I have always thought that I have a very complete and competitive profile. And while I still believe that, I had never considered that the problem could come from over-executing. I like to ideate, invent, and build. Do I have a doubt? I propose a prototype. Do I detect a repetitive task? I automate it. Are projects starting to pile up? I develop a system to manage them. Do I find limitations in that system? I implement another one to oversee the first. It’s a vicious cycle.
I have had over thirty initiatives in different stages of maturity. Some were small experiments, while others were ambitious. I must say that they were not only professional projects. There was everything: commercial products, internal tools, civic projects, books, mobile applications, project factories…
Seen from the outside, it can be seen as an extraordinary execution capacity, but for me, it is the classic “he who grasps too much holds too little.” My first boss told me that over twenty years ago:
“You scatter too much.”
It struck me to the core.
I find it easy to go from idea to architecture design, to implementation, and from there to promotion and growth (how many times have I not imagined getting rich). But of course, the idea that doesn’t weigh soon becomes an invisible commitment that occupies mental space and displaces other thoughts. The cost is rarely in the small details, like creating the repository or preparing the infrastructure, but in the complete picture. Each open project is a little finger that occasionally taps me on the shoulder demanding attention. Even when I’m not working on it, it’s still there. I have to decide whether to keep it open, whether I need to update dependencies, review an incident, or respond to someone. There are many little details that are insignificant on their own, but that together become exhausting.
What was my response? Stopping was not going to be an option, no. I told myself: “You need to try to industrialize all this.” So I set out to create agents, automations, automatic documentation, cost controls, mechanisms to maintain technical understanding even as the code advances faster than my ability to review it, etc. And mind you, a good part of that work makes sense and I will continue to carry it out. But there comes a time when you have to stop and recognize that more doesn’t have to be better, and that we all have limits even with tools that accelerate everything.
The indifference of the market
What is the most clichéd response when you’re asked about your main flaw in a job interview? Bingo! Perfectionism. Almost all of us have used it at some point to try to turn a flaw into a virtue. It’s not about being a conformist who doesn’t care how what they deliver turns out. There must be a minimum standard. But we cannot let technical excellence be a refuge for not delivering, for not launching, for not stopping to iterate. I have seen this both in myself and in many startups: there is always a good reason to keep polishing the product.
But the market doesn’t care. You can have a technically impeccable product that nobody cares about. A product that no one is willing to pay for because you have become obsessed with making it “perfect” according to your criteria, not according to the criteria of systematic validation. The market can ignore a product that doesn’t fail, that does what it promises, and that has a reasonable price, but that no one had demanded. Here the key is not to confuse activity with progress, something I have done more than once.
What is not billed, does not exist
Everyone has given away their work at some point. I have done it. Features out of reach, non-billable hours, analysis and advice that I wasn’t contracted for… Sometimes to maintain a business relationship, other times because solving it took me little time, or because it seemed more uncomfortable to explain that it had a cost than to do it directly.
One day you realize that gifts are not always appreciated; they can even become an expectation or a source of complaints. I used to attribute the problem to the client who didn’t value the effort. And yes, some didn’t value it, but I should have set the limit.
My difficulty is not in selling (in fact, I do it quite well), but in protecting the value of the service once contracted. My instinct tells me that it’s better to solve, whether by slightly expanding the scope, absorbing an unforeseen difficulty, or adding something I consider necessary without the client having asked for it. Viewed individually, these are insignificant decisions, but they cause great weariness when looked at collectively.
One floor up
I find it hard to delegate.
This phrase has been particularly difficult for me.
I have dedicated great efforts to create mechanisms so that my agents can execute work with greater autonomy. I ask them to research, implement, test, document, and (not always) launch without me having to supervise every step. And at the same time, I want to understand the decisions, control spending, review risks, maintain traceability, audit results, and prevent the speed of production from destroying my knowledge about the project. I even want them to help me with the promotion and growth of my projects.
Automation, in my case, has not eliminated the bottleneck, but has displaced it. We could say it has moved it upstairs, to the decision-making level.
Before, I reviewed code. Then I started reviewing plans, acceptance criteria, cost reports, documentation, evidence, and decisions made by the agents. I had delegated execution, but the criteria remained concentrated on me. And while I hope to continue maintaining the criteria (what would I have left, otherwise?), I think I will have to start tolerating results that I would have resolved differently. I need to set my ego aside and accept that not everything has to be under my scrutiny. And this connects with the reflection on the market: let those who are willing to pay validate. My mission is to build systems capable of generating stable, secure, and usable products.
Lifting the foot
I see a common thread in all these limitations, which is that I am not deciding firmly enough where it is worth concentrating my time. We can apply the Pareto rule to simplify it: I should dedicate more attention to that 20% that produces most of the results, and much less to the rest. So I need to set limits for myself. Is this uncomfortable? Yes, undoubtedly. I have been doing things one way for a long time, and that creates an inertia that is difficult to counteract overnight.
What does all this translate to? On one hand, I will have to be more critical when accepting a project or deciding whether it continues. I will need to streamline my decision-making processes so that they consume less time and energy. I will have to pay much more attention to out-of-scope work even if it seems trivial. And I will have to accept delegating more without losing the necessary visibility of what I am building.
This is the beginning. I have not resolved these problems and I have not even proven that my recipes are valid. Talking about a completed transformation would turn this article into one of those displays of vulnerability where the flaw always ends up being a well-manicured strength.
After more than twenty years optimizing systems, it was only a matter of time before I had to do it with myself.
❓ Do you have questions? Ask me in the comments.
🗣️ Did you find this useful? Share it so it reaches others.
🚀 Every so often, reflections like this in your inbox. Subscribe to Charcos Tecnológicos