What to Do When Joining a Non-Structured Team

Bogdan Chebac

Engineering Growth Manager at Gorgias



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.

Be notified about next articles from Bogdan Chebac

Bogdan Chebac

Engineering Growth Manager at Gorgias

CommunicationOrganizational StrategyDecision MakingEngineering ManagementSprint CadencePerformance MetricsLeadership TrainingFeedback TechniquesAgile, Scrum & KanbanTeam & Project Management

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up