Plato

Login to Plato


This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Don't have an account? 

Back to resources

Managing Tight Deadlines While Building a New Team

Building A Team
Deadlines
Reorganization

10 June, 2021

Shruti Venkatesh, Engineering Manager at Capsule, shares some of the best tips for dealing with tight deadlines in a newly formed 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Restructuring a Team Methodically
21 June

Vinodh Sundararajan, Senior Engineering Director at Earnin, shares his experience restructuring a cross-functional team from the ground up, providing context and streamlining the work at hand simultaneously.

Dev Processes
Reorganization
Vinodh Sundararajan

Vinodh Sundararajan

Sr. Engineering Director at Earnin

Taking a Vested Interest in the Hiring Process
21 June

Anna Min, Director of Engineering and Digital Experience Monitoring at AppDynamics, leaves nothing to chance when narrowing down the competition for a spot on her team.

Building A Team
Hiring
Anna Min

Anna Min

Director of Engineering at AppDynamics

Holding Partner Teams Accountable
16 June

Manzar Kazi, Software Engineering Manager at LinkedIn, speaks of his experience of holding a partner team accountable with whom his team had multiple dependencies.

Deadlines
Internal Communication
Collaboration
Manzar Kazi

Manzar Kazi

Software Engineering Manager at LinkedIn

Restructuring a Growing Team: A Lesson in Adjusting the Spotify Model
11 June

Marcin Dyguda, Engineering Manager at Hinterview, shares how inspired by the Spotify model of tribes and squads, he helped restructure a growing team and made their engineering function more efficient.

Reorganization
Agile / Scrum
Marcin Dyguda

Marcin Dyguda

Engineering Manager at Hinterview

The Parking Lot Method of Team Development
17 June

Suresh Marur, founder of Grow Happily, cultivates his team by putting them through a thorough and intensive regeneration cycle that he calls the parking lot method.

Different Skillsets
Building A Team
Hiring
Suresh Marur

Suresh Marur

ex VP of Engineering at Smarsh Inc

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.