Journal - Week 10
Journal - Week 10
Intro
Good Saturday morning. I hope you had a great week. Thanks for being here reading my humble diary, where I try to share with you the learnings and challenges I encounter every week.
This week, I have to admit, has been a bit odd. It happens from time to time. You are very busy, but when you look back, you don’t see any real outcome. Everything was made up of small tasks, scattered work, meetings, and alignment sessions.
I mean, I am happy. We closed the sprint and reached all the tasks we had planned (almost! Perfection does not exist), but nothing really big or fancy was accomplished this week.
Nevertheless, I had some good learnings.
Using Spec-Driven Development is now part of my daily routine. But not for all!
Keeping the team focused required some alignment sessions and a few Zen moments.
Projects sometimes get delayed, and it is better to recognize it than blindly push forward.
Spec-Driven Development
I am a huge fan of it.
Last week, I described my workflow, and I have been using it heavily ever since.
My learnings so far are the following:
It is essentially a solo tool. I still see it as not being fully prepared for large organizations or teams. It is a very personal way of doing agentic coding. I love having trustworthy documentation about the stories and features I build, and it works very well for my goals. However, I can understand that others may prefer different workflows.
The truth is that you can configure your systems to work with minimal developer interaction. By configuring the agent properly, all artifacts could be generated after a PR is created and the final push is made, before merging. However, developers could still skip the process, leaving assets stale or non-existent. The repository would contain incomplete information, and the specs would become outdated and therefore useless.
The thing is, if you forget to document just one feature in the specs, the whole system becomes unreliable. It makes the entire approach quite fragile.
For a single contributor who is committed and disciplined (like me :D), it works. For a team where each member has their own focus and priorities, it would require a lot of follow-up and micromanagement.
Next week, I am going to present it to my team, and I will keep you updated on their reaction.
Leadership
All of us have our ego, and we rely on different things to tell ourselves that “we are good enough.” Some people need big cars and money, others seek power, and developers often rely on knowledge. They put a lot of effort into designing and implementing features, and they defend their work like lions when somebody criticizes it.
I have witnessed real battles between developers trying to agree on the best way to implement something. It is not deterministic. There are always different approaches, each with its own pros and cons, and finding agreement can be quite difficult.
My approach as Leader to find kind of agreement has been the following.
Technical Discussion
Here, I am at the same level as the developer, and sometimes even below. They know the ins and outs of the technology much better than I do, and they can easily find arguments that are difficult for me to challenge.
What usually works best is trying to broaden the developer’s perspective. I remind them that they are not developing in isolation, that there are other teams to consider, and that future changes in scope should also be kept in mind.
This is also where the principle of doing the minimum necessary comes into play. Don’t overcomplicate things or think too far beyond the specifications. Of course, there is always a grey area. You do need to think somewhat beyond the current requirements. The question is: how much?
Best Practices
Here, I appeal to the collective spirit of developers. The shared knowledge that comes from years and years of experience and helps us understand what is most likely to prevent future problems.
It works for many situations, although it is still not perfect.
Business Alignment
My last card is simple: whatever you do is fine, as long as it aligns with business requirements.
This usually works well because it moves the conversation away from the technical side and toward the business side, where I have the final say. Nevertheless, there have been occasions when even that argument was challenged.
And If Not…
I try to avoid the “do it because I say so” approach as much as possible, but sometimes, when I truly believe something is absolutely necessary, I use the red button.
I should also add that, in my experience, many things eventually find their place if we simply give them time. So, if I see that something is not critically important and will likely resolve itself over time, I let it be.
Learning to Embrace Failure
Things have not gone well for a company I am doing a small consultancy project for.
Unfortunately, the project has suffered significant delays, and the CEO was even considering stopping it altogether.
After a crisis committee meeting, we decided to completely change direction. The main issue was that the project involved half of the company. From a quality perspective, this seemed like a wise decision. Everyone’s opinion should be heard, and everyone should contribute. However, it became a massive bottleneck.
Moving from team to team was exhausting for the project manager. Some project stages remained blocked for weeks because one department was preventing others from moving forward. Departments also started blaming each other, which affected morale across the company.
Now we are taking the opposite approach.
We will enforce a single, straightforward way of carrying out the integration. All departments will follow the process, and the integration project will no longer depend on them.
We are very optimistic and expect to increase delivery speed by 600%.
The goal is to see positive metrics within the next few weeks.
I will keep you updated.
PS: The post image is inspired from my Hometowm Barcelona and Sagrada Familia which past 10/06/2026 was blessed and finally considered a church after 140 years of work.