What to Do When Joining a Non-Structured Team
19 July, 2021
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Sebastien Cuendet, Senior Director of Engineering at AppFolio, relieved interdepartmental tension by bringing his Engineering team together with Sales in order to see things from their point of view.
Sr. Director of Engineering at AppFolio
Harold Li, Director of Data Science at VTS, makes his department’s spiritual evolution within the company one of his top priorities as a leader.
Director, Data Science at VTS
Bogdan Chebac, Engineering Manager at Gorgias, explains how he managed to bounce back from a tough situation.
Engineering Manager at Gorgias
Bogdan Chebac, Engineering Manager at Gorgias, talks about a stressful situation of handling clients and ample work pressure side by side.
Engineering Manager at Gorgias
Catalin Stoiovici, Head of Engineering Delivery at Capco, shares how he helped his team transition to a more mature operational practice and replace their ad hoc, cowboy style of delivery with Agile.
Head of Engineering Delivery at Capco
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.