RELATED CONTENT: How you organize your development teams matter

According to the report, the five challenges managers are struggling with are:

1. Maintaining productivity and velocity. As more development moves toward microservices and serverless structures, development teams are struggling to make technologies visible and troubleshoot their applications. “The complexity they bring demands a steep learning curve, and one of their main value points — namely, the abstraction they provide between the application code and the hardware the application is running on — also raises new challenges when attempting to troubleshoot the application without access to the hardware they run on,” the report started. 
2. Resolving customer issues in a timely manner. Engineering teams that are not properly equipped to handle customer issues become apathetic to problems. They need to clearly put a face and a name to an issue, see how much the issue is impacting the bottom line, and align with the business. “Once engineers are equipped to help the customer, they start seeing benefits to the business and end customers. It is becoming much more motivating to help resolve those issues and ties the loop back in to focus, understand and align with the business,” said Liran Haimovitch, CTO and co-founder of Rookout.
3. Balancing speed and quality. When working in a distributed development environment, it can be hard for developers to balance velocity and quality. Leaders are measuring development on their ability to meet deadlines, make customers happy, and find as many bugs as fast as possible. 
4. Teamwork and collaboration in a distributed environment. Teams are having trouble debugging and developing efficient code in a distributed environment. They need tools where they can collaborate, have access to the same information, and share knowledge. 
5. Remote debugging: Traditional debuggers don’t work in a distributed environment. “The solution is adopting the proper tool: a modern debugging solution that’s built for cloud-native applications. Developers will be able to get the data they need from their code, no matter where it’s running, and while their code is running live,” the report stated.

The post Top five challenges development managers are facing today appeared first on SD Times.

“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.”

The post How you organize your development teams matters appeared first on SD Times.

According to Lorenzo Pasqualis, vice president of engineering at DreamBox Learning, to be an effective manager, you need to be a domain expert in whatever it is you are managing. 

“An engineering manager needs to understand the work of software engineers and guide them through a career path that is very technical. Without that programming background, it is unlikely that an engineering manager could gain the respect of their [team] and lead them appropriately,” he said. 

RELATED CONTENT: Defining development roles in today’s modern software world

Yoav Cohen, CTO and co-founder of  the data security startup Satori Cyber, also explained that an engineering manager “that is viewed by his or her team as not technical enough would find it hard to drive the team to deliver extraordinary results due to lack of credibility.” 

However, Cohen noted that there is a fine balance between having that technical knowledge and knowing when to use it. 

To code or not to code
According to Scott Berkun, author of “Making Things Happen: Mastering Project Management,” how hands-on a manager needs to be really depends on the size of the team. If it is a team of six to 10 people, there should be enough programmers on the team to do the work without the manager stepping in. 

Pasqualis explained that while coding is a way for managers to stay close to the technology, it is very rare that they will be able to consistently produce production-quality code and excel as a leader. 

“The reason is that the two types of work are very different,” he said. “Coding requires intense uninterrupted concentration, while management requires dealing with constant interruptions and context switching. Being able to do both is not something that a lot of people can do in practice.”

Instead of coding as part of a team, Pasqualis recommended managers code in their free time. 

If an engineering manager takes on the same tasks as the team as part of their everyday responsibilities, it creates a confusing dynamic, according to Richard Wong, vice president of engineering at Coursera. Wong found that when managers code, they will only spend time on the interesting tasks and leave the less interesting, more tedious stuff to the team. That can cause the team to feel very unsatisfied. “A manager’s contribution is not as big as the damage they can do to their team,” he said. 

“Many people don’t like the managers they work for, and the reasons are pretty consistent… they don’t feel like they are trusted, they aren’t given work that is challenging or interesting, and they don’t feel like their boss looks out for them,” Berkun added. 

Cohen believes managers should still be able to code though, just not 100% of the time. According to Cohen, coding can help managers understand their teams better as well as the work. Some tips he has for continuing to code while managing include: 

1. Setting up the development environment on their laptop. “This alone will surface a lot of workarounds, tribal knowledge, and technical debt, especially around developer productivity,” said Cohen.
2. Picking easy tasks like fixing a typo in the user interface. This will help managers experience the end-to-end process of committing code and how it makes its way into the product, according to Cohen.
3. Taking on less critical tasks in the backlog. “Pick something small, around two hours of uninterrupted work, which you might be able to get done in 1-2 days, depending on how busy your calendar looks like. Get help from your team members if needed, they’ll jump on the opportunity to deliver more value,” said Cohen.

“The role of management should maximize the impact of the company by understanding what are the most important goals of the company and how to contribute to those goals,” said Wong. “One skill that is hard is that even if managers aren’t coding, they definitely have to have good empathy for technical challenges associated with engineers. If they don’t understand it they need to be able to ask and learn about it.”

How technical should managers be?
While it is possible to manage a software development team without having an extensive programming skillset, Cohen believes in order to truly be a successful engineering manager they need to have a programming background.

As you go higher up the corporate ladder, Pasqualis explained the need to have a programming background will go down, even if the company has a software division. “It is probably possible for a CTO or maybe even a VP of engineering to be more high-level, assuming that there are several layers of middle management under them that are deeply technical,” he said.

But for managers directly involved in the software engineering team, they “should have substantial background, and be experts in the field the team operates in,” said Cohen. 

Great companies are the ones that will even go as far as placing newly hired managers as team members for a few months before officially taking on a managerial role just to ensure they have the right level of background to be effective as managers, Cohen explained. 

This can be effective because for any given team, engineering managers need to understand the process their engineers use to make decisions, to prototype, to test code, and to do all the software development related things necessary, according to Berkun. “If a manager doesn’t understand those things well, how can a manager go into a meeting and make a decision on behalf of their team that isn’t going to cause them a lot of pain, suffering or effort,” he said. 

According to Berkun, having technical understanding is not the same as knowing how to code. It is more about understanding how decisions are going to impact the people coding. “You don’t need to have a computer science degree to have that kind of awareness of aptitude,” he said. 

For managers that don’t have a software development background, Cohen explained the team will need to be set up in a way to compensate for that. “One way to do that is to introduce technical leaders that are not managers to take on more of the technical leadership work, leaving the manager to focus on people management,” he said. 

The most successful non-technical manager relies on their domain expertise in other fields such as quality assurance, project management and product management, Cohen added.  “I believe that people management principles are applicable and transferable across many fields, and engineers are not unique in that respect,” he said.

However Cohen does note that the speed in which technology is evolving is different on a software development team than other teams, and managers need to be able to lead their teams not only from people skills, but from their technical skills. 

Managers should be constantly keeping up with the latest tools, frameworks and technologies. This doesn’t mean they have to read every single book and blog post to understand what is going on, according to Wong. Instead, they should delegate and have team members assigned to go out, find what is going on in a particular area, and come together to share their research and findings. “Then the leadership will be able to understand the trends and make decisions on behalf of the team,” said Wong. 

How to transition from programmer to manager
Since manager and developer roles are very different, not every developer is going to be well suited for a managerial position, and they should really take into consideration the different roles and responsibilities before taking the leap. 

When you have a programmer move into management, you get a Peter Principle effect, Berkun explained. “Someone may have been a great programmer, but now you ask them to be a manager that is more about communication, setting goals, dealing with politics, which they may not have any aptitude for at all. They are put into that role because they were good as an individual contributor and that happens way too much in organizations.” said Berkun. “In many organizations, the only way to get promoted is by moving into management, even though a developer doesn’t really like it and isn’t really good at it, that is the only path they are given.” 

The prime candidates for managerial roles are engineers who are passionate about leading people and are able to positively influence others, according to Cohen. “Identify those people who have potential and have conversations with them to make sure this is something they are passionate about,” he said

What ends up happening if you put a developer who isn’t well-suited to be a manager in that position, is they become micro managers because they know they can just jump into the code, look around, and fix things, according to Berkun.

Developers also have a certain style of getting things done and expect their team members to follow that same style when they become managers. “When the team deviates from their behavior, they think the team is not doing a good job without seeing the actual outcome, how they collaborate, or the final impact of the work,” said Wong. In order to let the team and team members become successful, the manager has to let people make mistakes, embrace different working styles, and understand how different types of people working differently can result in the same impact. 

Additionally, Wong explained that it is hard for someone to give up something they were really good at and do something they aren’t so familiar with. They have a natural tendency to do things themselves because they know they can do it faster and better than the people on their team. “The problem, though, is even if you can get it done faster, if you don’t give people the opportunity to learn, grow and even make mistakes, they will always take longer to get the job done,” said Wong. 

“The switch to focus from just technology to technology and people is perhaps the biggest barrier for a software developer to become an effective engineering manager. Engineering managers, to be effective leaders, need to be able to define reality for others and communicate complex ideas with simple words. Moreover, they need to be able to hire great people and create an environment where those people can thrive and grow, including fostering a high performing culture of innovators,” Pasqualis added.

Pitching Tuesdays
While managers need to ensure work is getting done and teams are operating smoothly, it is still important to allow team members to be able to contribute or express their ideas. According to  Sergei Anikin, CTO of cloud-based sales software company Pipedrive, managers and leaders need to give team members the time and opportunity to step outside the status quo and create freedom of thought, or a “culture of choice.” He explained too often team members are undermined or ignored when they try to bring new ideas to the table. 

One way Pipedrive enables team members to contribute is through “Pitching Tuesdays.”

“Every Tuesday, across our organization, team members from every level have an open forum to propose projects/initiatives (missions) and present them to the entire company. The best and most pressing ideas are put into action. The team members who propose the mission then work to coalesce an appropriate group to address the challenge,” Anikin said. “The team members for each mission are naturally attracted to the projects they find most interesting and compelling. They are invested in the project and motivated to discover a solution. With team members choosing projects they are most passionate about; we have created a ‘culture of choice.’ ”

According to Anikin, Pitching Tuesdays have enabled his company to define a culture, serve as a training ground for leaders, and explore new ideas. It is especially important that leaders go into something like Pitching Tuesdays with an open mind.

“Managers are using Pitching Tuesdays to grow and become better managers. Remember, Pitching Tuesdays are a focal point to drive our self-managing, agile organization,” said Anikin. “And, the journey from a traditional hierarchical management structure to decentralized, self-organizing teams requires a lot of confidence and commitment and deep understanding of reasons behind the change.”

Some ideas that have come out of Pipedrive’s Pitching Tuesdays includes Leadbooster, a conversational bot that engages with web visitors in order to find leads and help book meetings. 

“Because our development team is connected to the product team and customers, we were able to identify this need with Pipedrive customers. As a result, our entire Prague team engaged and developed this capability over a period of months, including testing and feedback from customers,” Anikin explained.

In addition, Pitching Tuesdays led to Hovercards, a capability that allows Pipedrive users to hover over information and see details without having to navigate away from the current view. 

“In a Pitching Tuesday session, the development of Hovercards started like all missions begin — with a problem statement. The problem is always from the customer’s point of view,” said Anikin. “Great leaders understand they can control the effort, but cannot control the outcome. To get the best effort and an opportunity for the best outcome, senior leadership will support and encourage a joint team effort through commitment and buy-in.”

The post The dev manager’s dilemma: To code or not to code appeared first on SD Times.