Deliver bad news early

(This is a departure from my simpletime series. Yeah, life took a downturn and I've become a bum. I've also decided to shelve the project for now. But hey, I'm on a staycation to fix things. You'll hopefully see more posts from me now).

I am a tech-lead at Grafana Labs for the hosted Prometheus product which is built on top of the Cortex project. I have been in this role in various capacities for nearly a year now and I’ve learnt a lot of things: about how different people work in different ways and how some projects are better suited to certain people, etc. But one of the solid lessons I learnt is to “deliver bad news early”.

We had a feature in development that had a lot of customers waiting for it. It was one of the important features of the quarter. Unfortunately, it wasn’t all smooth sailing, issues were cropping up by the dozen and progress was slow. I could see the deadlines slipping even only a month into the 3 month timeline. I could also see that the folks implementing the feature were still optimistic about meeting the deadline, they were willing to work harder and were almost convinced that everything would fall into place. I wasn’t sure how the leadership in particular, my then manager and VP Product, Tom Wilkie, was seeing the progress and how he’d react if I highlighted the problems I saw. After all, this was an important project that I was the tech-lead for and it wasn’t going well.

But in the end, I decided to tell him my reservations regarding the timeline and to be honest, the reaction was surprising, in a good way. He had the same inklings but only realised how serious it could be after I also aired the same concerns. The first thing he said though, stuck with me, “This is good, not the situation but that you raised the concerns early. Always deliver bad news early.” We immediately looped in the managers as well and looked at what was going wrong and how we could improve things. And given this was early in the quarter, we did try to change things, but the feature ended up slipping and launching the next quarter.

But the lesson stuck with me, always deliver bad news early. In this scenario, it wasn’t me directly working on something which made it easier to raise concern, but after the reaction from Tom, I would not hesitate to air concerns or issues even if it was my own project. Turns out this is also good culturally, I’ve been reading Principles by Ray Dalio and What you do is who you are by Ben Horowitz and both of them emphasise being open to and even encouraging bad news. And everytime I read a section on that, I recall my experience.

In conclusion, it is always better to clarify issues and set expectations early. As engineers, we can never fully see all the issues, and are always optimistic about delivering on time. We’ll even sometimes optimistically bend reality a bit, work harder and think that we can finish it in time. Estimation is a hard problem! But there will always be cases where we don’t fully realise the scope of the problem until the last minute. When we finally deliver the news, it will be a surprise and not a good one. Maybe some commitments have been made based on our launch timeline (like press, customer obligations, etc.) and changing things in the last minute is a pain.

But if you set expectations early, it will leave a bad taste in the mouth, but it will give people time to react and prepare. And in the end if we actually end up shipping things by the earlier deadline, that is much better, and not worse. And managers, encourage your reports to bubble up issues and when they do, congratulate them for doing so and you’ll see far less surprises and will help you see issues early and clearly. Put in a culture that encourages transparency and mistakes and you’ll run a faar smoother ship :)