Among the roles played by development managers is to serve as the middle man between the business and developers. They have the hard task of facilitating the needs and wants of the business and end users through their development projects. How they set up, organize and empower their teams can result in the success or failure of a project, solution, feature or even overall business. 

“We have business objectives and we need people to fulfill them. The goal of an organization design is to group the skills necessary to deliver value in the most efficient way for the business overall,” said Jeremiah Lee, an engineering manager at InVision, a digital product design, workflow and collaboration company.

Add COVID-19 and remote work into the mix, and things get even more difficult for development managers. 

Assembling your development teams
There are different ways to organize and bring developers together on a project and work toward the business’ success. For instance, there is the traditional development team structure or a squad approach.

A squad is a term that came from audio streaming company Spotify’s engineering culture. According to Spotify, it is a “small cross-functional, self-organizing team usually less than eight people” that “sit together and have end-to-end responsibility for the stuff they build, design, commit, deploy, maintenance, operations, the whole thing.”

RELATED CONTENT:
Developers reflect on challenges, feelings about remote work in pandemic year
Top five challenges development managers are facing today

The company explained they started as a Scrum company, but once they started to introduce more development teams within the organization, it found the Scrum practices were getting in the way. “We decided that Agile matters more than Scrum, and Agile principles matter more than any specific practice,” the company said in a video. 

Typically, a squad includes a squad leader that acts as a lead developer or Agile coach, and six to eight developers who are split up into pairs. There are also support squad roles such as a designer, product owner, and application architect who come in for a period of time to help with the overall design or UX, explained Chinh Vo, CTO and practice leader for IBM Garage.

According to Ravi Lachhman, an evangelist at the CI/CD software company Harness, “squads are more organized around a problem set to deliver functionality on and members of a squad can rotate in and out much more frequently than changing teams. Squads are typically problem- or functionality-based, bringing together several members from different teams to solve and deliver on a particular problem or build specific functionality. When those goals are accomplished, squad members can realign to different squads while continuing to grow their skill sets.”

Squads can, however, have a negative effect on the human aspect of development, according to Liran Haimovitch, CTO and co-founder of debugging company Rookout. He explained that in a squad model, developers are required to change teams frequently and work with different people, which can hinder the development project because developers have to take time to get to know one another and how they will work together.

However, Harness’ Lachhman looks at changing teams as a good thing because the only way he says a software engineer can grow and expand their skill sets is to experience and embrace new challenges and changes. 

“Squads can regroup and spin up and down quicker than changes in the team/management structure, allowing for individuals to solve problems they are passionate about and the squad can focus on the goals set forth,” he said. “Modern teams should focus on skills and domains of the ‘bench strength’ of the development organization and then allow development members to work on different projects/squads. This allows for development members to rotate around and work on fresh problems while building domain skills in the firm/organization.”

Lachhman explained that in order for a squad to work, there needs to be a strong platform engineering culture in place. “The biggest part of the learning curve when switching team to team is that no one ever deploys software the same way,” he said. “Common engineering efficiency tools such as those that enable the CI/CD pipeline and similar confidence-building steps teams take to reach production are crucial for squads to work.”

IBM’s Vo recommends the following best practices: implementing pair programming, rotating programming pairs to spread knowledge, having standup meetings, and co-locating squads.  

According to Mark Cruth, enterprise solutions architect at the software development company Atlassian, the best practices engineering managers can take from the Spotify model are: 

  • Not to copy the model, but to try to understand the structure, practices and mindsets, and then tailor it to fit your own organization and needs.
  • Autonomy and trust to empower teams to pick their own tools and make their own decisions
  • Transparency with community by building trust, being transparent, providing inclusive ways to gain feedback and aligning with how your organization wants to work
  • Encourage mistakes to constantly be learning and improving 

“Although it may look like a matrix organization, the key cultural elements of the model need to be in place to allow the structure to thrive, such as trust and autonomy. If an organization doesn’t shift its behaviors (and ultimately its culture), the benefits of the Spotify model will never be realized. If you simply rename teams to Squads, you’re just putting lipstick on a pig,” Cruth wrote in a guide about squads.

InVision’s Lee  believes Spotify’s squad model falls short of its promises. He explained while Spotify’s idea of squads was to basically have teams working as autonomous mini-startups with all the skills necessary to do their job without having to rely on another team, matrix management solved the wrong problem, he said. It was too fixated on team autonomy, collaboration was an assumed competency, and mythology became difficult to change, he said. 

Stream-aligned teams
Instead, Lee recommends a stream-aligned team approach, which is an evolution of full-stack, multi-discipline product engineering teams or Agile feature teams. 

“Stream-aligned teams perform better than teams organized by discipline because coordination effort is reduced to coordination within a single team instead of across team boundaries,” he explained. 

IBM’s Vo finds that while ideally you want to have full-stack team members, there really aren’t any true full-stack developers. They either have more expertise in the front end or back end of software development.. He explained forming teams into squads helps because you can pair different types of programmers together to get them more up to speed on the technology or in an area where they may not be as strong. 

Stephen Deasy, head of cloud engineering at Atlassian, explained that what engineering managers should really be focused on is organizing teams around customer impact. “Our first frame of reference is always we should organize the team to be most effective to deliver that value and how you organize changes,” he said. “What we found was being able to connect to the end user and really understand the domain and problem space the end user is having, the team can really develop a deep understanding in there and build really good solutions.”

The way you organize and execute that will be different depending on your project or team size, but Atlassian believes in the triad model where you look at the development, market and operational aspects of a solution. “We think of products as really being the what and the why, building that roadmap and understanding the domain, what outcomes we are trying to drive. Then, the engineering teams are trying to drive how we will build it, owning the schedules, delivery, execution and operations,” he said.

As far as how big the team should be, generally Deasy says you want to make sure you can control and understand the growth of a team at that size. “Really trying to connect the team to the what and why, building a balanced team so they are set up for success with skills, level and size, and try to get out of the way and let teams win,” he added.

As you start to grow the amount of developers you have, you will have to revisit how you organize and execute your teams. Deasy explained what works for say 40 engineers may not work once you scale to 200+ engineers. 

“The most optimal combination of team types changes as the organization size changes and the business needs change. Many organizations today start with several stream-aligned teams and expand to include the other types as the organization grows” Lee said. 

Lessons learned working in a remote environment
Traditionally, you would form a development team and they’d have their own physical space to work together, but the COVID-19 pandemic really forced development teams to rethink how and where they work. A year later, many businesses are actually seeing increased productivity and happier employee work-life balance as a result of working remotely that they are starting to consider a remote-first approach. It wasn’t an easy year, but organizations have started to work through the kinks and find what really works for their business in a remote world. 

One of the biggest disadvantages development teams faced in the pandemic and in the new remote world was the camaraderie that came with being co-located, according to Harness’ Lachhman. Managers have the extra task in a remote setting to make team building and skill-sharing a priority. “Setting up co-working time, virtual lunches and happy hours are also important to foster ongoing collaboration,” he said. 

What Lachhman found was that while, even when employees were still in the office they would typically “ping” or message someone before getting up and going over to their desk to ask for help. “You can still collaborate this way virtually and instead of walking over to someone physically, you can start a screen share,” he explained. 

According to InVision’s Lee, the success or failure of a team in a remote environment has more to do with team interaction than team structure. “Working remotely means embracing asynchronous work. There are a million ways to collaborate and almost as many tools to help. When you are remote, you can’t look around the office and infer norms. You also can’t get everyone in a room at the same time to build consensus every time. You have to find another way of getting alignment,” he said. “Companies have to increase intentionality to work effectively remotely. That means creating and explicitly communicating an agreed upon set of practices and investing in people being able to self-serve their way to success.”

Remote camaraderie, team building, and human connection really requires good video and microphone setups so people can put a face to a name, look at each other, and see their emotions, according to Rookout’s Haimovitch. “Once you move to asynchronous communications, you can reduce costs and have more flexibility on who and how you hire,” he said. 

One of the things Atlassian tried to implement to keep the human connection was to try and organize a social event every week. However, the company found that this was challenging in the beginning because not everyone was available at the same time and it was taxing for them to have to add another meeting on their calendar. The company found that replacing a standup meeting with a social event and consolidating the number of meetings really helped alleviate some stress of their team members. 

Managers also really need to listen and learn from their team members, according to Atlassian’s Deasy. Some ways to gain feedback is to run regular polls at the team and individual level to find out what is working, what is not working, and how the organization can help. 

Deasy also found that the company had to reallocate or increase development team budgets so they could get their remote offices properly set up. Since the company found that every individual has different requests and needs, the company gave managers the anatomy to overwrite budgets and work out what was needed for each individual case. “It’s hard to come up with a single global approach to this because the individual situations are so different and it changes over time,” he said. 

When offices start opening back up, Atlassian plans to retain office spaces, but use them more for collaborative workspaces or as an option for those who need a physical place other than home to work. “We believe the distributed manner in which we are working now has a lot of advantages. Diversity, improvement, engagement and flexibility for people to work in the ways they are most productive while still connecting to their team,” said Deasy. 

Rookout’s Haimovitch found that the pandemic really highlighted the importance of independent engineers. “It is even more important that engineering managers provide team members with the right tools and guidance to allow them to work efficiently and independently,” he explained. “You need to make sure your  engineers can do whatever they need to do alone by themselves because that is how they are going to spend their day. You can’t rely or allow silo knowledge or lack of privileges. Give them the tools to deal with their own day-to-day tasks independently.”

IBM Garbage’s squads worked on a co-located model in a physical space before the pandemic because they found it provided a faster turnaround for mission-critical development projects. When the pandemic hit, the company had to move to more virtual ways of working. According to IBM’s Vo, video was key to making sure there was still that personal connection. The challenge in the beginning was dealing with people’s Internet connection and bandwidth. 

It also adopted new collaboration tools to maintain interaction and engagement from all participants.

Vo doesn’t expect to change much of the work environment post-pandemic, unless it’s a request from a customer. “There will still be a combination of going onsite with customers and teams coming into the office working together, but it’s not a requirement anymore,” said Vo. “It actually opened up the possibility for us to form more efficient squads. Instead of restricting us to one office location, now we can have people from the West Coast, East Coast, middle of the country, and get the right type of folks to be more efficient or more specialized to execute on the project. It gives us a little more flexibility.”