Plato Elevate Winter Summit has been announced (Dec 7th-8th)

🔥

Back to resources

Managing Tight Deadlines While Building a New Team

Building A Team
Deadlines
Reorganization

10 June, 2021

Shruti Venkatesh
Shruti Venkatesh

Engineering Manager at Capsule

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

Delegate successfully as a first time manager of Product Managers

24 November

Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.

Scaling Team
Building A Team
Delegate
Coaching / Training / Mentorship
Psychological Safety
Cross-Functional Collaboration
New Manager
Andrew Tsui

Andrew Tsui

Director of Product at Startup

Working From the Ground Up

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, uprooted an entire product and built it back up again with the help of his team.

Deadlines
Toxic Atmospheres
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

Why Overloading Product Teams Never Work

23 November

Adi Purwanto Sujarwadi, VP of Product at Evermos, shares how he identified the symptoms of his overworked product team and worked towards defining conflicting priorities.

Managing Expectations
Product Team
Deadlines
Stakeholders
Adi Purwanto Sujarwadi

Adi Purwanto Sujarwadi

VP of Product at Evermos

How to Successfully Complete A Major Reorganization

4 November

Kirk Gray, VP of Engineering at McGraw-Hill, recalls his experiences performing major reorganizations of departments, including successful techniques to ensure a smooth transition.

Alignment
Convincing
Reorganization
Roadmap
Fairness
Kirk Gray

Kirk Gray

VP Engineering at McGraw Hill

Succeeding as the First Product Hire in a Startup

2 November

Priyanka Naik, AVP of Product and Technology at J.P. Morgan, shares her plan to bring a product to execution as the first product hire in a startup.

Alignment
Goal Setting
Product
Deadlines
Roadmap
Priyanka Naik

Priyanka Naik

AVP - Product and Technology at JP Morgan

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.