Back to resources

Building a Team of Mixed Seniorities

Building A Team
Company Culture

29 November, 2020

Sameer Kalburgi

Sameer Kalburgi

VP of Engineering at Fieldwire

Sameer Kalburgi, VP of Engineering at Fieldwire, discusses how his team evolved from hiring junior engineers to building a team of -- and balancing -- mixed seniorities.


As a small startup, our team initially consisted of immensely talented but very junior people who we could afford. Most of our processes were top-down and we built a culture that resonated with their seniority -- or lack thereof. We were driven by the fact that junior engineers need more guidelines and hand-holding and our culture reflected that approach.

At that point, we also failed to acknowledge that people of the same (junior) seniority could differ greatly among themselves and have entirely different needs. If you would try to onboard, train, and/or manage them in the same way it will be frustrating for everyone. In addition, as we grew, we were attracting people of different seniority and had to adjust our processes and culture to meet their capabilities and needs.

Actions taken

Setting up expectations
On the team level, I had to set up my expectations in terms of responsibilities and the level of work to match my engineers’ seniority. Also, on the company level, we had to set up expectations for onboarding and getting up to speed. Both should be higher for senior people who should be able to jump in and help with some complex things.

Identifying heavy-handed processes
Our flow of work from product to engineering and then, to production was very prescriptive and that was helpful for junior people who were coping to fill in the blanks. They would have a hard time understanding which things should be debated and which implemented straightaway. Packaging steps as X, Y and Z and handing them off to junior people should get you good results. However, this approach would feel stifling for more senior people. They would have their own ideas and suggestions that they would want to apply and tweak. Instead of receiving the instructional package, they would want to be able to build that package themselves.

Increased ownership
Junior people own implementation, senior people own outcomes and goals. You should challenge senior people with more strategic tasks and provide them with an opportunity to influence strategic areas. I would try to make projects more engaging for senior people as opposed to merely delegating them.

Growing them in their role
Junior people need to expand their knowledge and skills through more mentorship and hands-on training while senior people need more opportunities than training. Most senior engineers had already been to different training and they would need larger projects to work on or bigger initiatives to own. You shouldn’t hold their hands and micromanage them which eventually, can lead to frustration. Instead, you should spend that time connecting and helping junior people who would often need more assistance than you could imagine.

Lessons learned

  • One of the mistakes we made was that we didn’t think ahead of time when we were building our processes and culture and they were tailored to meet the needs of junior engineers.
  • If you think of hiring senior people, be prepared to listen to them. We hired smart people with abundant experience and past success that we could leverage. Since you have invested heavily to bring on those people, make sure that you are benefiting from what they have to offer.
  • Every person is a unique individual that comes with a different experience, background or competencies and you should craft onboarding and a development plan to match their uniqueness. Even among the people of the same seniority, you will have people with, for example, more technical or product experience. Instead of having one generic approach tailor your onboarding and processes to fit different individuals -- starting with seniority, but not ending with it.

Discover Plato

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

Related stories

Providing Clarity to team

5 February

Giving confusing direction to team is perilous. But giving clarity is so very important.

Building A Team
Kamal Raj Guptha R

Kamal Raj Guptha R

Engineering Manager at Jeavio

Managing remote first organization

4 January

I was hired at HUMAN in 2021 to manage a team that went from hybrid to completely remote working environment because of COVID.

Building A Team
Company Culture
Ahsan Habib

Ahsan Habib

VP Software Engineering at human

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Managing Expectations
Building A Team
Psychological Safety
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

Facebook vs. Google: 10 Contrasts for Engineering Careers

7 December

This is a brief comparison and contrast of Google and Facebook, as a place for one’s software engineering career. Both can be amazingly good places for engineering careers. But both places can be misfits for otherwise excellent engineers. This is a short differential guide. [Originally on LinkedIn]

Company Culture
Michael McNally

Michael McNally

Chief Technology Officeer at GraphStax

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino