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

🔥

Back to resources

What to Do When Joining a Non-Structured Team

Team Processes
Agile / Scrum
Health / Stress / Burn-Out

19 July, 2021

Bogdan Chebac
Bogdan Chebac

Engineering Manager at (Undisclosed)

Bogdan Chebac, Engineering Manager at Gorgias, talks about a stressful situation of handling clients and ample work pressure side by side.

Problem

What are some of the common problems with joining a team in an outsourcing company? As an engineering manager, in my case, it was not having a consistent workflow, or a healthy structure to the team. The trouble was, sometimes the team would have a lot of work, and they would have to spend weekends working or doing overtime during the week. Other times they would have no job at all. It would lead to boredom or getting engaged in work that was not adding value to the engineering team.

When I joined the team, I took over the role of the previous engineering manager. However, the last engineering manager was more focused on the technical aspects, architecture, tech stack, technical debt, rather than the processes and the workflows. Clients came from a very waterfall-based background, meaning that they did not necessarily have small increments of work to be delivered, such as sprints for every day.

Weeks would pass by, and our clients would have a more quarterly view in terms of their objectives. However, not all the goals were of the same volume; some were too big while others were comparatively small. Soon enough, I realized that some team members were sweating out of work, whereas others had a rather relaxed schedule. In the same team, I would see that some were working overtime, and, on the other hand, some had a hard time finding something to keep themselves occupied as they did not have much in their pipeline.

Actions taken

My first take on resurrecting the situation was to talk it out to my manager. I pinpointed where the project would function well and operate smoothly. Learning from my past experiences, I thought a little more about how we could make improvements to the team. I presented some ideas to my manager and the advantages it would bring in. Our ultimate goal was to work on:

  • Having more constant workflow
  • Being able to forecast
  • Having more transparency of our work
  • Letting the client knew what we would be able to deliver
  • What we would not be able to provide at the end of our deadlines

I proposed for the team to take a more agile approach rather than waterfall-based. Furthermore, I talked to my manager to get approval to submit to the client to work in two-week increments rather than quarterly, meaning that the client would get updates more often. In that way, we could plan out the work more carefully, so there were no surprises, and the team would know exactly how much they could tackle the job. I was able to win over the client by telling them they would receive new features more often, while our engineers would put up with a better workflow. It was like killing two birds with one stone.

Last but not the least, this was one of the most important actions that I had taken during the time: changing the processes and ceremonies of the teams to ensure that they adapted quickly to changes. This brought in positive changes in the end. Although it did not fix anything overnight, change was all that we needed. Adjusting to the new way of working and taking in time to understand our clients were a game-changer.

Clients saw changes being made from our end more often, which gave them the pretence of feeling more valued. Even though we were making minor changes frequently, rather than significant changes on a quarterly basis, we were a lot more into what we were doing with engaging the software and workflows. Ultimately, the results also allowed us to move to a more permanent change. In the end, we successfully switched from waterfall to a more agile approach.

Lessons learned

  • Switching from waterfall-based to agile is a difficult task to carry out. An engineering manager might have a plan worked out in his mind, even then, they would need to look at the pros and cons of each situation before customizing the agile approach for the team in the best possible way.
  • There would be a lot of risks involved when selling to clients and customers, but what is most important is to adapt yourself into the situation. The results, in the end, would speak for themselves.
  • As a team, we learned that it was more refined and more uncomplicated for them to estimate in smaller increments rather than estimate invigoratingly. So, they began to focus on how much work we can tackle in two weeks other than in three months. The agile approach was superior to the waterfall one because it was more transparent and received softer more often.

Discover Plato

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


Related stories

Building a New Team in a Foreign Country

23 November

Adam Hawkins, Site Reliability Engineer at Skillshare, went all the way across the world to build a brand new team who worked very differently than he was used to.

Team Processes
Adam Hawkins

Adam Hawkins

Site Reliability Engineer at Skillshare

What It Takes to Understand Other’s Perspective

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how to really understand someone else’s point of view.

Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

How to Handle Team Collaboration After a Merger?

23 November

Nicholas Cheever, Divisional Vice President, Global Supply Chain Technology at Trimble Transportation, shares how he helped the acquired company’s team members understand the business mission and give them focus.

Acquisition / Integration
Team Processes
Nicholas Cheever

Nicholas Cheever

Divisional Vice President, Global Supply Chain Technology at Trimble Transportation

Overcoming imposter syndrome through focusing on your strengths

19 November

James Engelbert, Head of Product at BT, recalls when he had to battle imposter syndrome when managing a new team.

Product Team
Product
Health / Stress / Burn-Out
James Engelbert

James Engelbert

Head of Product at BT

Surefire Ways to Boost Team Morale

11 November

Rajesh Agarwal, VP & Head of Engineering at Syncro, talks about effective ways to boost team morale when stepping in as a new manager in the team.

Motivation
Team Processes
Rajesh Agarwal

Rajesh Agarwal

VP and Head of Engineering at Syncro

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.