Hey!

Welcome back to another week of musings. This past week flew by, and now we're in the last week of January, we did it!

I hope you had an uneventful weekend and managed to get some rest.

Was this forwarded to you? You can subscribe here!

Things I enjoyed in the past week

• How to think about Gas Town, part of a series by Steve Klabnik about using Claude Code for software development. I hadn't heard of Gas Town, so it was interesting to know about it.
• There is No Proto-Dragon: The Illusion of Fictional Taxonomy. It was an interesting read about what fictional creatures mean and what is considered "canon" for them. But more importantly, how people can easily think about a "dragon", instead of having to explain how a creature looks or acts in every single story.

Lately, I've been focusing more on planning and execution of projects than anything else. I've pretty much started the year with meetings to "regroup" and assess the next steps. Or what to do about new information, or blockers that came up during the Holidays.

That has made me think, what makes projects get to the finish line? In small projects, you or your team are trying to deliver something without external intervention, which might be clear: you would do design (formal or informal), implement something, and test it.

In larger projects (or maybe large corps?), where a project cannot simply be delivered by a single team, and depends on aligning backlogs, setting up requests from other teams for them to schedule work, involving more roles like Program Managers, etc. The amount of coordination would make a single person burn out or simply be unable to hold all the details in their mind.

I've also started watching projects from afar that I'm not really participating in but seeing what makes them move forward.

We recently started undertaking a large project at the company I work for. It required a huge amount of teams and coordinating, weekly meetings, scrum of scrums, and people juggling their backlogs, redoing them, reassessing scope every week or every two weeks to make it work.

This project is too big to fail on one side, and on the other, it's top-down, so every team is pretty much in it. I've seen projects like these in the past; they tend to fail if the sponsor leaves, or the hurdles become so much that they kill it close to the finish line, burning people out in the process.

In small/medium projects, it takes a few people to care about the project and keep pushing through the hurdles, handling the risks, blockers, etc.

The main thing is not get discouraged each time a new problem shows up, that team won't work on this immediately, we're required to use the new system instead of the existing one, you get the idea.

Another aspect is how clear vision and decision-making are and how they are communicated. These aspects make people aware of why something took a given turn, no surprises. Vague always sticks around; it's better to be wrong and get corrected.

Your turn!

How do you help projects cross the finish line? Have you ever had to push through hurdles, blockers, etc to make a project reach the end? Was the end unsatisfactory for you? Have you ever been on a project that was cancelled in the end? Let me know your thoughts by replying to this email!

Happy coding!