Managing Tight Deadlines While Building a New Team

Problem

Most engineering teams have raced against a tight deadline at some point. While delivering the outcome is certainly important, how we get there is even more so. Do we emerge from the process feeling a sense of accomplishment and energized to take on the next challenge or are we wrung out by the chaos and uncertainty? The job of every Engineering Manager is to make sure we have more of the former moments and almost none of the latter. I joined a company as an EM and was asked to manage a brand new team. None of the engineers had worked closely together before, and I had certainly not worked with any of them earlier. To add to this, we had a very tight deadline for an ambitious project that the team had to deliver - a complex distributed orchestration platform in all of three months.

This project was challenging on two levels:

• Teams take time to work together, to build trust with each other and with their manager.
• I had to convince my newly formed team about the necessity of this new platform.
  

Actions taken

I took the initial few weeks to have several conversations with the team. I blocked out my schedule exclusively to have conversations with the engineers both 1:1 and team wide so we could all better understand each other, align on our goals and build the basis of strong interpersonal relationships. I also took this time to talk through the architecture overhaul that the company was going through and why our system needed to be built.

I talked the team through the utility of the system and through alternate implementations. Identifying the pros and cons of various approaches helped familiarize the team with the concepts we were trying to work with. By the end of the first week, the team was convinced that this was the best path to move forward on. They had also formed the basis of good communication and interpersonal relationships with each other.

The next step was to enlist an engineer on the team who had product experience to help identify immediate use cases and future use cases for the system. This meant even though we were building an MVP, we were not just focused on only building for the first use case, but also had an eye on our future use cases.

We prioritized the needs of the system together as a team. We built out a matrix to identify what were absolute must haves, should haves and nice to haves. Following this, we ranked them all by priority and prepared the initial list of features.

Next, I involved the team in conducting a build vs. buy analysis to ensure that our time and resources were being spent on the right areas. I identified at least 8 other similar offerings on the market. I divided these up amongst the team and enlisted them in learning about and investigating these systems in detail. We ranked these against the “needs matrix” that we had constructed and vetted if any of them were a good fit. We narrowed down 2 or 3 that could have been a fit, but ultimately decided that since we have many bespoke use cases and this system was to form the base layer of our technology infrastructure, we should build it in-house.

Through the unbiased analysis, the team was further convinced about the benefits of building our system. They were also able to familiarize themselves with the internals of other orchestration systems and bring ideas to the table. We then worked on chalking out our system architecture over several discussions over the next two weeks which we presented to the rest of the engineering organization for review.

Last but not least, I broke down the system into separate areas and assigned areas to each engineer. This was based on their skill set, interest and experience. I was able to ensure that each engineer felt ownership towards at least one part of the system. This helped them feel a sense of responsibility towards the final delivery and that they were trusted to deliver a part of this mission critical system.

Lessons learned

• Take the time to know your team even, and especially, if you are working against rushed timelines. Trust and interpersonal relationships go a long way.
• Transparency is critical. Making sure that everything is well documented, nobody misses anything out on anything, and everyone is clear on what they should be working on and why, helps bring everyone on the same page.
• Give people a sense of ownership, starting from a place of trust. Even if you may not have worked with them before, do take the time to understand what drives them. Figure out something that works best within their parameters and set them up for success in that way.
• Make your team feel recognized and rewarded for the effort that they put in. People in the organization need to know the type of work that gets awarded. It not only motivates everyone to work towards success, but also sets an example for the rest of the organization.