Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.

Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.

You can learn more about Refactoring here.

To receive all the full articles and support Refactoring, consider subscribing 👇

Become a better tech leader ✨

Over the last 10 years there have been very few things in my engineering work that have remained constant.

If my younger self could have a sneak peek into present times, he would be amazed at the tech stacks that have come and go, the remote work shift, and how communication has evolved.

One thing never changed though: developers hate to give estimates about their work.

In my experience this has been remarkably constant, with different people and teams.

My generalization may be flawed, of course, by the fact all these people have a major thing in common: they were all managed by me when I noticed this. So their reluctance might very well be a reaction to my management faults.

Even if we account for these, though, I believe estimates naturally lend themselves to two evil follow-ups:

• ⚔️ They become subject of negotiation in a way or another.

• 🗓️ Developers are pressed to commit to some delivery date.

Both things are scary because estimates are often just guesses in a clean shirt — as every project brings its fair share of unknowns.

In many teams this leads to the infamous cycle of inflated estimates:

1. Management negotiates estimates harder

2. Developers react by producing more conservative estimates in the first place

3. Repeat

I have seen this happening even under the best intentions, with capable managers and reasonable engineers. So I have come to believe the flaw is in the model, rather than in the way people behave.

The Final Delivery Flaw

Why do estimates even matter? They do because they are a proxy for when stakeholders will receive value from the engineering work.

Stakeholders want to capture it as soon as possible, which leads to negotiation. So the more business value is attached to an estimate, the more pressure and expectations will be attached to it.

The epitome of this happens when projects are organized around a single final delivery.

In this model, since the whole value is designed to be captured in a single moment, the estimate becomes incredibly important — and you can't really blame people for trying to make it shorter.

To counter this you should do the exact opposite: deliver value continuously.

Deliver Incremental Value

Whatever you have to build, and however long it will take to complete it, break the project down into pieces that are:

• ⏱️ Small — they are deliverable in no more than a week or two.

• 🎁 Valuable — each of them produces tangible value to stakeholders.

I know this sounds like trite advice, and people usually reply: it is hard to ship complete features every week!

I may reply in turn:

1. It isn't so hard if you plan for it.

2. Value does not come from software alone.

The second point is particularly underrated. There are all kinds of activities that provide visible value and do not involve production-ready software:

• 📋 Clearing some requirements after a round of interview with users.

• 🎨 Converging on a piece of design that makes both users and developers happy.

• 🔨 Successfully demoing a feature prototype, without the actual product being ready.

You may notice not all of these require software, but all require users. Agile says the only measure of progress is working software — I would generalize and say the only measure of progress is the outcome you produce for your users.

Delivering incremental value, with a solid feedback loop, brings several benefits:

• ❓ Reduce risk — by keeping stakeholders in the loop you realize early if you are diverging from their expectations, and possibly get back on track based on their feedback.

• ⚔️ Reduce negotiation — by spreading the value you bring over time, instead of concentrating it into the final delivery, there will be less pressure on how long the whole project takes.

• 🤝 Co-creation — when stakeholders are actively involved on a regular basis they are more likely to feel personally committed to the project. They will share the responsibility with you, be more keen to accept setbacks, and root for your success because it becomes their success as well.

Do you find a hard time negotiating on estimates? Do you estimate projects at all? Let me know your experience about it!

📚 Resources

• 📑 Purpose of Estimation — this article by the great Martin Fowler addresses common pitfalls about estimating software projects, and what are the true reasons you should create estimates for.

• 📑 Contracting for Agile — it is very interesting how agile contracts have evolved over time based on considerations that are very similar to those we make for in-house teams. This presentation explores pros and cons of various common options.

• 🌀 An Agile Manifesto for 2021 — In this article I went back to the 12 original Agile principles and tried to reframe them in the light of today's learnings. Working in small batches and working closely with users are among those.

• 🌀 The Pyramid of Stakeholders — Keeping stakeholders in the loop is probably the single most important factor for any project’s success. This article explores the relationship we have with the different kinds of them.

⭐ Weekly Featured Jobs

Here are the remote engineering jobs featured this week! They are all from great companies and I personally review them one by one.

1. Commit — Tech Lead / Senior Engineer Fellowship — the remote-first community for software engineers.

2. Zapier — VP Platforms & Labs — the easiest way to automate your work

3. Hubspot — Director of Engineering, Fintech — inbound marketing, sales and service software

4. Stripe — Staff Engineer, Product Experience — online payment processing for internet businesses

Browse many more open roles (or add your own) on the full board 👇

Check out all Refactoring Jobs

Hey, I am Luca 👋 thank you for reading this far!

Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.

Subscribe below to receive a new essay every Thursday and put your own growth on autopilot!