Table of contents
Introduction
Yesterday I came across Sean Goedecke’s blog, and I remembered that I had read some of his articles on hacker news, which I really liked. I discovered he has a book collecting many of those articles. I started reading it and was delighted by the amount of good insights within them that I wanted to remember.
I’m writing this blog post to summarize the ones that resonated the most with me from Sean’s article How I ship projects at big tech companies. I’m also taking the opportunity to connect those ideas with my own experience.
My notes
projects almost always ship because one single person makes them ship.
In medium to large-sized companies, there will be a lot of people contributing to the project with essential and important actual work; but if no one takes the responsibility to ship, the project will stay in its default state forever:
The default state of a project is to not ship
Taking the responsibility to ship is a challenging and uncomfortable role, which may result in good outcomes for you if it goes well, and you communicate that work properly. Earlier in my career, it sounded “funny” to me when I heard that some manager was the responsible of the delivery of a project. “How can that be possible if they didn’t write a single line of code?” I thought. Now, after having been in that role a few times, both as an engineer and as a manager, I think I understand a little bit better what that means.
Sometimes, I’ve found myself in that role without even noticing, not giving it much importance and thinking that it was just what I was supposed to do. If you’re in that position, make sure you give yourself credit for it first and be very proud of it. Second, make sure your manager knows that you’re doing it and discuss it with them. They can help you with this. Otherwise, you risk burning out by spending all that extra energy without getting anything in return. Things you can get from taking on this role:
- Recognition.
- Reduction of workload on other types of tasks, so that you can do that work better.
- Or, if you successfully do it several times, you’ll gain trust, which increases the probability of a raise, promotion, etc.
The key thing is to get whatever you’re building in front of as many eyes as possible
…and the earlier, the better.
This is one of those things that seem obvious at first but aren’t that easy in practice. When starting a project, the most impactful tasks are often connecting more components earlier. So, this should be the first goal. To give a simple example, if you’re developing a typical mobile application, that talks to a backend, it’ll be far more impactful to return canned hardcoded responses from the backend rather than mocking the API calls directly in the mobile app.
This will:
- Demonstrate whether some of the assumptions made when designing the network API layer are valid or not.
- Get the team used to deliver increments without breaking the app/server contract from day one, because if it’s broken on the backend side for instance, it will make the app developers unhappy as they’re already using it to do their job.
- Make the team learn the different ways the system breaks, resulting in a more reliable product in the end and fewer surprises.
The second goal is finding the absolute minimum piece of functionality that allows a user complete the user journey, have it working in production ASAP (under a feature flag), and doing nothing else until this goal is met. This might (and usually will) be a smaller set of what product had in mind for an MVP. I’ve found myself that the negotiation of what the MVP is with product or the rest of stakeholders is more productive when the conversation is had in prioritization terms, rather than “engineers wanting to cut scope again” terms. There’s another article by Sean Goedecke titled the simplest thing that could possible work expanding on these ideas.
Once we’ve reached the point where that absolute minimum piece of functionality is working and could be opened to users today, we can start prioritizing the “bells and whistles”, adding functionality, but having something deployable in every new step. Incremental iterations they say. This is a big part of what I understand by agile. At this point, for me, the project is not at risk, because it’s shippable. However, it’s important to remember the point Sean makes here:
If you deploy your system, but your manager or VP or CEO is very unhappy with it, you did not ship […] If you ship something users hate and makes no money, but your leadership team is happy, you still shipped
So, balancing this aspect is also crucial. Easy, right? 😅. To achieve this, I have no better idea than early and frequent demos with all the stakeholders, writing down the feedback from those demos, and getting a better sense about how your manager, VP, CEO picture the project in their minds. Another challenge here is handling different opinions within your reporting line — and you definitely will find them.
Nothing builds trust like having fallback plans,
I liked this connection between “fallback plans” and “building trust”. I always thought about fallback plans as a way to de-risk a project, but I didn’t have this directly under my “building trust” toolbelt.
In fact, it’s paradoxically often better for you if there is some kind of problem that forces a delay, for the same reason that the heroic on-call engineer who hotfixes an incident gets more credit than the careful engineer who prevents one.
This quote has left me thinking a lot… it sounds horrendous to me, and dangerous and, at the same time, I’m afraid it holds a good amount of uncomfortable truth. I guess one thing to apply is trying to be more vigilant and give more credit to the careful actions that you or someone else took that prevented something wrong from happening.
In relation to this, I remember having a chat with a very smart colleague. He impressed me with how he expressed in concrete quantified money terms, how much the company had saved by following his advice of not doing a months project. This example could have easily fallen under that “careful engineer preventing incidents silently” category, but I’m sure the way he expressed it prevented that action from remaining unnoticed, and allowed people in his team to learn from it.