A community of experts covering technology, society, and personal development.

Published on April 21, 2023

Office Politics in Software Engineering

Three tips to organize a successful dev team

Photo by Anna Samoylova on Unsplash

I’ve worked in several roles on good and bad teams over the years. Everything from junior to senior developer, team lead, project lead, software architect, process manager, system administrator, and even scrum master.

Across all of these team experiences, I’ve found three key contributors that led to successful performance. The first relates to team communication protocols, the second to defining developer responsibilities, and the third relates to assigning key team functions.

Below, I’ll also share the rationale, approaches, and tools related to these contributing factors for healthier and more productive teams.

Photo by Annie Spratt on Unsplash

1) Keep teams small and in tight communication

The ideal team size is five to eight developers (plus a few support roles I’ll discuss below).

Teams with three or fewer engineers find it hard to develop consensus without forming cliques. Teams with ten or more members find it hard to create a consensus because there are too many opinions.

With the right team size, engineers can communicate effectively with each other, quickly learn each other’s expertise, and pair up on hard or long problems without sacrificing the team’s velocity on smaller (and often critical) issues.

The magic of making the team work together is often a bit of an art, and comes down to individual personalities at least as much as the technology being used.

It is important to set communication expectations early and repeat them frequently. Those expectations can be driven from the top down if leaders are good at understanding the personalities on their team, or can be built up from developer preferences.

When leaders set the communication strategy, the benefit is clarity. There is one person to go to when a team member has a question about how to effectively communicate. The drawback is often resentment. The communication strategy doesn’t always have buy-in and can feel like an imposed extra task.

When the team decides on the communication strategy, the opposite is true. The benefit is buy-in. Teams get to decide how to communicate together and while one or two members may be unhappy with the results, most will be satisfied. The drawback is that the strategy may be subject to change, though this also allows for correcting approaches that are not working. An additional drawback is that the decision-making process about communication may itself take up larger blocks of time. This can still be worth the time for teams that will remain fairly static for long periods.

Tools - A collaboration tool like Slack or Microsoft Teams and daily standups

An integrated messaging tool should be everyone’s first choice and will probably be 90% of the team’s communication. These tools can be integrated into many parts of the development process, giving a single location to find the information that team members need. They can also use these tools to share desktops and documents, or start video calls to collaborate quickly when the situation calls for it. But most importantly, they are built to be ignored (for some time).

One of the worst things for software developer productivity is being constantly interrupted or breaking a deep chain of thought. These tools have settings to make notifications non-intrusive, and team leaders can create a culture that reinforces the point that message response is not time-critical. I’ve found that this way, most messages get answered both promptly and with more thought because the developer responding is not trying to rush back to their problem or keep their focus, but is intentionally pausing to answer communications when they get to their messages.

Daily standups are tedious for everyone but instrumental in getting work done as long as they are managed to be quick meetings. This is not a meeting to justify your existence as a developer, but rather to give a quick status on what you’re doing that might impact the team or roadblocks you’re facing. It lets the team hear if a member is being continually stalled so more people can get involved early if necessary and provides a forum for impactful decisions. It should take no more than fifteen minutes.

Photo by Mr. Bochelly on Unsplash

2) Have well-defined responsibilities for developers

Want to know one of the most frustrating conversations I’ve had?

“Why wasn’t this caught in code review?”

The answer to this varies:

“I didn’t know this needed a code review”
“I couldn’t get anyone to review my code”
“It was found, but <person(s)> passed it anyway”
“We didn’t know if the feature was more important than the code quality”

In a CI/CD environment, this is how bad code flows to the customer. This happens when no one knows whose job it is to be the arbiter of “good” vs “bad” code.

Your team can answer this particular question in multiple ways, but my favorite is to have two senior developers on the code review team where both are required to sign off. When the story or ticket is assigned, also assign reviewers. That gives the developer or developers a chance to bring in a few more other interested parties before code review if needed.

Developers having non-specific responsibilities is problematic because they have no specific authority over their peers unless that authority is assigned or agreed upon in advance. Give your team specific responsibilities with the authority to carry out those responsibilities, otherwise, their approval or disapproval is only advice to a coworker.

Tools - Built-in collaborative review tools like GitLab code review

With tools like these, not only can your team pass along code comments directly in the code, but you can assign specific rules to code reviews. For example, setting the code review to require two reviewers and requiring two approvals. Best of all, this can all be done outside of a planned meeting because these tools are available to use any time the reviewer is available.

Photo by Mimi Thian on Unsplash

3) Create four key positions for the project

Your team needs leadership and direction. If you are following the Agile process, you already will have a product owner and product management helping decide the priority of features vs the team velocity. Within the team, there are four critical leadership roles.

Keep in mind that these roles do not need to be four separate individuals and do not have to be full-time responsibilities unless the team requires it. I have seen very successful teams with a single person fulfilling all four roles, sharing leadership roles across multiple teams, or spreading these roles across the team as part-time positions.

1) The Manager

At the end of the day, it is usually the Manager’s responsibility to get performance out of the team. They answer to higher powers and may need to impose decisions on the team. Their key benefit to the team, however, is to protect the team from those higher powers.

It is critical for the team to feel like a team. Nothing breaks up a team quite like pressure from above seeking to blame individuals in the name of higher velocity or quality. The (good) Manager will have to accept responsibility for the whole team and help build process improvements … or sometimes get themselves and others out of the way.

2) The Architect

While the overall architecture may be decided for the team or may be decided by consensus, it is important to have a single point of contact that understands the architecture that is being planned and has the authority to enforce that architecture. I often think of this person as a “code evangelist”. When you decide to follow a particular pattern or architecture, it can be very easy to find an expedient solution that ignores the pattern and someone needs to be able to say no because it doesn’t fit the pattern.

This leader needs to be actively involved in story planning and acceptance. They will be the person the team checks with to validate their approach to a feature or bugfix when necessary.

This role becomes more critical the longer the project lasts. If the product becomes a hodgepodge of different architectures, it becomes unmanageable over time. If it uses a single (even if outdated) design, communities that use the same architecture often have solutions for even the hardest problems.

3) The Style Manager

It is convenient to try and replace this position with automation, and to some degree that is correct. Your CI/CD process should include unit testing, code coverage reports, linting, and auto-formatters. To what degree it includes each of those might be up to the team, but the responsibility of implementing and maintaining those automations needs to fall to someone.

This is a person that likely should be included in every code review so they can take a quick glance and be sure the team’s style choices are not being ignored for expediency’s sake.

4) The Process Manager

Similar to the Style Manager, processes should largely be automated, but it falls to someone to build, maintain, and enforce processes. This position is also evangelical … the process manager ought to be a proponent of that process or it will fall into disarray. The position here can be divided further into individual processes if needed (CI/CD, Agile, ticket management, etc).

A lot of the processes themselves will be decided by company culture or availability or licensing the company is willing to provide. Part of this leader’s position is making the best use of the tools available or advocating for better tools.

Tools - GitLab CI/CD, Kanban, githooks

The tools chosen are going to depend on the language and the goals of the team, but in general, I’ve found that a strong CI/CD process with built-in build and testing stages, Kanban for tracking tickets or stories, and githooks for enforcing code standards pre-commit or pre-push (these can be caught in CI/CD stages as well, but are cleaner to catch outside of the trunk).

Photo by Mahmud Ahsan on Unsplash

Bonus: How to raise up junior engineers

First and foremost, try to hire engineers that will fit your team and use a sane hiring process. Also, try to have no more than a quarter of your team be very junior. It can take between one and six months for a brand-new developer to be productive. It often takes senior developers one to three months to be productive because the team, technologies, and processes are often different from job to job.

Set expectations both with the team (and management) and with the junior developer. Let them know they aren’t expected to know much initially. Most developers come out of college not knowing anything about version control or other processes. Most developers coming out of boot camps don’t know much about algorithms or advanced data structures. The job of a new developer is to learn to be productive.

You need enough personnel to spare the time to teach your new developers. They likely need, on average, an hour or two a day with a productive engineer. They need to ask questions, try and fail, and be given room to slowly make progress.

My favorite thing to do is to assign a “mentor” to a new developer. It should be a rotating position so the junior developer can learn more than one “style” of developing. Assigning a mentor also gives that person the authority to slow their own velocity so they can help build your next generation of developers.

Once the new person is onboarded and has access, assign them very small features with very slow velocity. This will give them time to learn the process, style, and architecture from their mentor via code reviews and paired programming. This is a perfect time to reinforce a culture of seeking help when it is needed instead of spinning unproductively on problems. Make sure their mentor is spending time with them each day.

As the new developer’s code increasingly matches the team’s process, style, architecture, and velocity, then increase the size, complexity, and criticality of their assignments.

You can internally grow a highly productive team member within a few months. Now you just have to retain them!

Citizen Upgrade is a community of experts covering technology, society, and personal development. Visit us at our website, on Facebook, or on Twitter. Join our mailing list to access more great content and other helpful resources.

https://citizenupgrade.medium.com/membership