Now what?

Dylan Etkin has been an engineering manager for a good portion of his career, and now is a co-founder of Sleuth.io, a company focused on helping organizations continuously improve their software delivery through the use of metrics. He has seen it all, and lists five common mistakes these newly minted engineering managers make.

1. Don’t compare how you would work as an engineer to the team you’re supposed to be managing.

“There’s a change in how you understand value for yourself,” Etkin explained. “Let’s assume some sort of world where you’re a great IC, and you’re used to slinging code throughout the day, and let’s say you’re really, really good, and maybe you’re producing at a five … Now you become an engineering manager, maybe you’re managing a team of five ICs, and they’re all producing at a three, so you start to think about things in terms of 15. But you’re also not tangibly doing that; you’re not showing up each day and getting that satisfaction of personally having driven a five across the line. And that’s a huge mental shift.”

He went on to say that if you’re not taking satisfaction from that new part of the job, you might as a manager feel like you’re not doing something that’s important. “I’ve seen folks … that don’t take management super seriously. They don’t realize that if they adjust their thinking, like getting everybody who’s doing a three to do a four, and that’s suddenly a huge amount of more capacity,” he explained. “Instead, maybe they go off and hide in their IC habits, and the things that give them comfort. If you’ve been an engineer your whole life, and now you’re a manager, your fallback in your comfort zone is going to be engineering.”

2. Understand who you’re reporting to

A second mistake new managers make is not understanding who you’re reporting to and how they want to receive information. Etkin said an engineering manager is part salesman, in that you’re selling the work that your team is doing. But in the absence of the necessary information a new manager might not be delivering up to his managers, those higher-ups will naturally assume the worst, he said. “When I started doing the job, I was like, ‘Hey, my team is doing great. I’m focused down and across. And, everybody knows that I’m so good at things, so they will just assume that this team is going great.’ Yet lo and behold I hear through the sideways mechanism that people are very concerned about how this project is going. And I had to learn the visceral way that I need to be telling people what’s working and what’s not working, and what we’re trying and what we’re focused on and what the impact of that is. And that’s a very different mentality from when you’re an IC.”

That issue starts to get into the topic of value streams, which enables first-line managers to surface the real work in such a way that it can be zoomed out for the next higher levels of management to assess if the project is on time and if the correct amount of resources are being spent on the things the organization is trying to accomplish.

3. Understand the big picture

Another aspect of the role of the manager is to understand the bigger picture and learn the why behind what the organization is trying to do, and then enforce those things.”It’s not always easy. And sometimes, the worst part is when it’s just a terrible idea and you have to enforce it anyway,” Etkin said. Often, the manager will fight over the direction, and if the fight is lost, the manager has to go back to the line engineers to explain the decision. Etkin added, “If you’re a good manager, who’s always communicating to your team and letting them know what the thinking is behind a lot of these things, it makes it easier to deliver the bad news. As long as there’s transparency and communication, it makes it go down easier.” 

4. Understanding your team

Etkin advises to be adaptable to the team that you’re working with. Different people have different styles. “I have had engineering managers that work for me that are extremely pedantic,” Etkin said. “They have a super-manicured JIRA board, and their planning meetings are a walk through issue after issue after thing. And they have been extremely successful.” On the other side of the coin, Etkin said he’s had managers working for him that have very short planning meetings, who simply want to know what the team is doing that week. And once they are sure the engineers know exactly what they’ll be doing to get from here to there, that’s the extent of the meeting. “I think those are great examples of understanding the teams that are working for them,” he said. “So some individuals can work in that mechanism and prefer to do so, while some individuals can’t, and they require a little bit more structure.” 

5. Understanding yourself

And then there’s a balance of understanding what you need yourself, Etkin pointed out. “How much structure do you need, versus how much loosey-goosey units do you need, and then marrying that at the right level, between you and the people that are working for you, such that you can come up with a process that allows everybody to do their best work.”

But he said managers also have to take that a level up to their bosses, who will be on the spectrum of extremely right to extremely open and understanding, to see where the manager is in relation to that individual. “You have to adopt enough things to make sure that that person is satisfied with the way that your team is working too.”

To learn more about making development teams more productive, join us at the upcoming Improve: Productivity one-day virtual conference on Nov. 15. Registration is now open.

The post Common mistakes made by engineering managers that hurt productivity appeared first on SD Times.

Me? I’m Team Crunchy. A lifetime member since the uniform was footy pajamas and my cereal of choice was Honey Nut Cheerios. 

You need to know these types of things– like how your coworkers prefer their morning cereal and if cilantro fills their mouths with the taste of suds- when you’re collaborating with people on a daily basis. It’s arguable that these tidbits are even more critical when you’re working in a hybrid model, which is probably why these questions are nearly always included during our Ask Me Anything interviews featuring new engineers.

Here are four other things I’ve picked up leading and collaborating with an engineering team in a hybrid/remote model.

1. Create an environment of learning from Day One

Engineers, especially new hires, just want to code, produce, and ship new features– it’s what we do, it’s in our DNA. When an engineer joins a new company, however, they have to catch up on a lot of code and processes. Onboarding new engineers is all about redirecting their energy for the first few months from doing to learning. 

Supporting this learning process was easy in the office. At Slack, we would seat you right next to your “onboarding buddy” and it was natural to turn to them and ask them questions. Even with assigned buddies, though, this didn’t translate favorably into the hybrid model. Setting up Zoom meetings required too much activation energy and structured meeting hours felt strained and awkward. One enduring trait of engineers is that they can determinedly set their minds to reading their way to a solution, which doesn’t always benefit them or the team they’re collaborating with. 

Slack Huddles is recreating the ease of in-person communication. When a question arises, all an engineer has to do is ping their buddy or another teammate for a few minutes of their time. The other person clicks yes and they’re connected. That’s much closer to what we had before. Of course, this has to be normalized as part of your team culture as well. The easiest way to do that is to model this behavior as a leader, and it’s totally normal for me to start or receive three to four huddle pings a day.

To keep my engineers from crawling up the walls of their home office in their first few months with Slack, they’re still fixing bugs and submitting code. Because not being able to ship code would probably drive them mad. But I remind them, their primary work product during this phase is learning – then shipping.

2. Set high standards, provide feedback that helps people achieve them

Once employees are up to speed, the expectations change from learning to performing. It’s your standards that set your technology apart amongst the millions of apps and feature sets that are released every year. Achieving that auspicious goal requires that every single team member performs to their utmost potential. How do you help your employees get back on track?

Don’t wait until an employee’s performance review to inform them they’re not coming up to scratch. Feedback is somewhat of a perishable good and it’s best when delivered fresh. Building continuous feedback loops into the way you lead and collaborate as a team means consistent improvement is the norm for everyone. Integrating feedback into your day-to-day model also normalizes the process and makes it easier to give and receive. 

Be intentional about the way you deliver feedback as well. Focus on framing the feedback around your employee’s role or function and use language that makes it clear this isn’t about who they are as a human being. If it is somewhat personal, reflect how a certain behavior or action may be perceived by others or how it impacts the team. 

Follow up by asking for any feedback they have for you as well. Thank them for their honesty, and commit to processing and integrating any valuable feedback you receive– both as a role model and for the benefit of your work.

3. Listen to what’s not being said

Giving, receiving, and integrating feedback are all expedited when your communication skills are sharp. While many people have practiced the art of talking, far fewer have devoted adequate time to listening. My advice to you is to look into active listening. There are nearly as many interpretations of what that means as there are people espousing its positive impact. So while I am listening actively I’ll speak to some specifics. 

Listen for what is not being said. Frustrations arise, but some teammates may be reluctant to face conflict head on until the situation gets out of control. It was easy to watch body language, tone of voice, facial expressions, or the way people walk away from a meeting in an office setting. As a leader in a hybrid model, I’ve had to attune my ears and eyes to the minute indicators of how someone communicates via text, audio, and video to keep a pulse on team dynamics. When you’re listening well, you can waylay issues before they mushroom. 

Like any good engineer, I appreciate an efficient system. Going remote meant that I needed to tighten up the way that I respond to my team’s professional and interpersonal needs. By systemizing conflict resolution, you guarantee that grievances don’t go unchecked on your to-do lists. These slips can happen due to unconscious bias, a busy schedule, and the blending of our work-home lives. A process makes sure you do it right every time with everyone.

4. Arm your team with the essentials, and get really good at using them

Going hybrid meant a lot of things: being unmoored from an office or an in-person team, the collision of personal and work life, the ability to hire engineers living literally anywhere. It also necessitated a new wa of working together while maintaining the extremely high level of collaboration that engineering teams like mine need.

The tool came first for us, and then came the cultural shift. 

We already knew that Slack was a platform for great immediate interaction. It’s asynchronous abilities, however, weren’t as celebrated when we were all in-office at the same time. But once Slack embraced this nebulous work environment– physically and culturally– asynchronous tools began to shine.

A great example is the way we share materials. Now, it’s our norm for California early-birds to log off before their coworkers and drop a file marked “Here’s something to check out.” In the past, people may have felt pressure to immediately respond. Now you know that person isn’t checking comments until early the next morning. 

We’ve really changed the expectation so that it’s clear that people are sharing things that are meant to be consumed when their teammates have the space and time to do so- whether that’s in a few minutes, hours, or even weeks in some cases. 

Another tool that has been pivotal for our hybrid collaboration is GitHub. We have our own internal controls and compliance that require that every piece of code is reviewed by another engineer. It’s also how better software is made so that there are more engineers, eyes, and minds on it. Code reviews in GitHub have many of the advantages of pair programming – only you don’t have to be sitting next to someone looking at the same code at the same time. 

Once you’ve completed your piece of code, you can submit for peer reviews by whomever is available whenever they are. You can also ask someone who has specific subject matter expertise or domain knowledge. It’s the norm that that person will finish what they’re doing and then get to it, it may even be that they ask for a review in kind on their code. This is all asynchronously occurring. In Slack, you know once someone has left comments and you can go back to the feedback when you’re ready.

We’ve really upleveled the way we work together. And, quite frankly, I think if my team was all in the same office, we would still choose to work this way. 

Leading in a hybrid model, for me, remains grounded in my values and my skills as a leader. But as an engineer and a leader of engineers, I get excited about the tools we can expand on or create to enhance the way we work together.

We had many of these tools on a rudimentary level pre-pandemic, and through this experience they’ve gotten better. We have also gotten better– our work flows, our norms, our leadership skills, they’re all better. And I’m sure we have farther to go. Looked at on a timeline for scale, if this is how we work forever, we’re not going to figure it all out in the first 18 months. And I, personally, am looking forward to seeing how far we go.

The post Leading and collaborating with an engineering team in a hybrid/remote work setting appeared first on SD Times.

SD Times: Development managers have to make sure projects run smoothly and are completed as requested. So, how close to the code do they need to be? Should they be jumping in and coding, or merely helping to set policies and internal best practices for developers?

Mathon: Development managers need to be close to the code; however, leadership work is different than the technical work. Managers need to focus on establishing engineering practices and teams, managing projects, and organizing developers. It really helps when development managers can perform a technical code review, as well as know how to submit a pull request and write unit tests. Even more importantly, development managers need to establish and support an agile culture, DevOps automation, and continuous improvement.

Development considerations include the supporting infrastructure, but many developers don’t understand infrastructure or concerns about security and resource utilizations. Many also either don’t know how or want to implement CI/CD with automated testing in an adequate way. It’s critical to ensure that security scanning has been performed and passed before deployment. If there is a security problem, the entire enterprise can be massively impacted.

Many software projects today are built from pre-existing components, whether open-source or off-the-shelf. What is the development managers’ role in assuring license compliance and security?

First, managers need to know what components are being used. It is easy for developers to use cloud services and open-source components. However, a proliferation of tools can lead to risks and costs later when the components are scaled, need upgrades, have problems or incompatibilities. For this reason, organizations should limit the number of different components offering similar services.

Additionally, managers generally need to be aware of how popular an open-source project is and if it is supported well by the community. License compliance is less important today, since almost all open-source components use Apache or similarly loose licenses. More important is watching each component for security concerns.

How responsible are development managers for testing? How hands-on in that process should they be?

Development managers need to know what tests are being created and what tools are being used to run the tests. They also need to know if security testing and performance testing are being done on a regular basis, and they should receive alerts or notices if the testing identifies issues.

Outside of the development process, how involved with business decision-makers and marketers should a dev manager be?

Today’s DevOps-oriented Agile approach requires development and business teams to be highly synchronized. Each iteration of a business offering should be driving the apps and services to be created by the development team. A proper Agile and DevOps process should enable releases to production for every iteration, and these should correspond to business priorities. Additionally, the development process should inform the business team, so business managers can be aware of the reliability of predictions made by development.

Is it the development manager’s responsibility to introduce Agile or DevOps practices to the team? If so, must he be an expert in these areas? How does he gain that expertise?

It may be the responsibility of the development manager to run the Agile process. If so, training via well reviewed consulting organizations would be good. There are excellent books on the subject as well. A lot of people think they know Agile and in reality they don’t.

Even if not running the Agile process, a development manager should still have a thorough understanding because he or she then will be able to assess the process implemented by the team and work with the Agile coaches and project managers effectively.

The post For development managers, the question is: How close to the code should you be? appeared first on SD Times.