DEV Community

loading...
Cover image for Team's external factors

Team's external factors

Arsen
Software developer, tech lead. Most interested in human factors of software development. Embrace your humanity.
・3 min read

I looked into my working experience in different teams, and I compared how I feel about them. I didn't have any criteria in mind, but in the end, I got a list of factors that we couldn't affect as a team. Therefore, I'm talking about the team's external factors.

In my career, I've been in six different teams. I ranged how satisfied I was with the work and what were the reasons. It all came down to three items:

  • how many projects a team handled;
  • how many teams worked on the same codebase;
  • how good the manager was.

(By manager I mean the person directly above the team - an engineering manager or a CTO.)

Here is my rating, from the best team to the worst:
#1 - one team working on one project, good management;
#2 - two teams working on one project, good management;
#3 - many teams working on many projects, good management;
#4 - one team working on many projects, okay management;
#5 - one sort-of-a-team* working on one project, okay management;
#6 - many teams working on one project, bad management.
*I was the only constant team member, while other developers occasionally joined me to help.

Observations

  1. Software management framework didn't matter at all. We followed Scrum more or less closely in teams #2 and #6, a home-brewed process in team #3, and we didn't have any specific organizational process in teams #1, #4 and #5. There is no correlation between how we organized our work and the position in the rating.

  2. Working on many projects was a bit inconvenient. You have to focus on many things simultaneously, and it creates an additional cognitive load. It also comes with more frequent switching of the context, leading to a loss in velocity or quality. Also, it is harder to maintain the focus on what is important for each of the projects.

  3. Many teams working on one project was a more serious issue. Not only it affects the quality, but it also decreases motivation.
    If you can't claim ownership of a part of the code, it is hard to feel fully responsible for it. Then it becomes harder to dedicate yourself to quality. What is the point of making a good design, refactoring the code, covering it with tests if at any moment "an outsider" can come and break everything? You thought everything was fine, but in the meantime, somebody hacked a global object in the middle of your code and marked all the failing tests as ignored because fixing them was too complicated. It's like tending to a garden where anyone can make a barbecue on top of the flowers.
    This is when people start asking themselves - is there any point in doing the job well? In the worst situation, I saw a developer said: "I don't even care about the final product anymore, I'm just a cog in the wheel, I do as I'm told".

  4. To my own surprise, the most important factor seems to be the management. It is hard to describe the management quality in a couple of sentences, but I'll try my best:

    • Good managers were capable of listening, were open to dialog, gave autonomy to the team. They were interested in everyone's success, and they helped everyone to grow.
    • Okay managers were not too helpful, but they trusted us and didn't stand in our way. It was more of old-school carrot-and-stick management: "Do the job, and I won't get mad at you, and there might be a bonus".
    • Bad managers were interested in their personal success more than ours or the company's success. Sometimes they obstructed our work - probably because they were afraid to be undermined. There was no trust, and typically there were many lies, empty promises and political intrigues. Even if you manage to learn something under such management, you grow at a much slower pace than you could have.

What to do

In my opinion, there is a perfect setup of one team per one project, and it is achievable. If you put enough effort, bring enough facts and arguments, and repeat them enough times to the right people - it might take months, but the company's processes can change.
Having an okay or a bad manager is harder to handle. There is always a passive approach - to ignore, work fair and honestly, become emotionally insensitive, and hope your manager will leave the company or get promoted. From a lousy manager you can learn how not to be one - that's something, I guess. And you can always try to become a good manager yourself!

Cover photo by Alex Wigan on Unsplash

Discussion (0)

Forem Open with the Forem app