How to Meet Strict Deadlines In An Environment of Uncertainty

Problem

A research team had built a quick proof-of-concept application, and it was my job as a new EM to take ownership of this application, to form a new team to turn it into a Product, and to deliver it in Production for our clients within 6 weeks. None of the engineers who were part of that original research team would be part of my team, and therefore nobody in my team including myself knew much about what the application did nor how it was built. We had access to the source code and limited documentation about it. What are the odds that we would successfully productise the prototype and deploy it in Production within 6 weeks?

Actions taken

We started by taking ownership of the prototype. This meant getting to know what it does functionally and what problems it solves for our clients. Secondly, we investigated what are its different modules, how they interact with each other, and created technical documents. Lastly, we assessed its production readiness, so we examined it from the Quality perspective as well as its non-functional requirements (i.e. Security, Performance, and Observability).

In the Production Readiness assessment, we managed to identify all the gaps that prevented the prototype from being a product. With this list, we were able to categorise them as either mandatory for ‘go live’ or otherwise. We then performed high-level estimates for all the items in the mandatory list, which led us to conclude we couldn’t reach our deadline. With this in mind, we re-assessed the list, and through close collaboration with the Product and our Security teams we realised there were further reasonable compromises we could make. Thus, some of the items in the mandatory list were moved to a new category for items we thought were mandatory immediately after ’go live'.

Within the list of mandatory items, we had a lot of work to do in terms of Observability. We had to ensure we had all the monitoring and logging systems in place. Also, we prepared ourselves for any incidents and created a troubleshooting document on what to do if we did get any incidents. Importantly, we also prepared operating procedures for our first-level support teams to follow in case of incidents. This gave them the means to troubleshoot the easiest problems by themselves and enabled them to route to our engineers the problems that needed further investigation, with the right level of detail and the right priority.

Lessons learned

• Working closely with Product and other stakeholders is essential, especially when you need to make tough compromises. They will be on your side if you are transparent about the constraints you are facing.
• Put the uncertainty on paper. Assess and list in written form what it is that you don’t know, and then start a discussion about how to turn the unknowns around. Do this together with your team and your stakeholders.
• Challenge what might seem obvious at first. If a backlog item is mandatory, ask yourself again, is it really mandatory? If so, why? What is the impact if the item does not get done? Can it be done later?