Four Essential Team Tasks for Software Engineer Managers

Quick Summary - Investing effort into the four activities we’re looking at today can help any software engineering manager make sure their teams are more productive tomorrow.

Four Essential Team Tasks for Software Engineer Managers

Focusing on team development

We recently talked about whether software engineering managers for Israeli companies actually need to know how to code. We pointed out that in Agile software development, Israeli engineering managers probably don’t. This actually lets the engineer manager focus on the big picture and their team’s development. I’m sure that if you’re an engineering manager, you’ll agree that there’s plenty here to keep you very busy.

Developer hours are your units of currency in software development. As with shekels and dollars, you can waste, spend, or invest developer time. From reducing code churn and code complexity to improving teamwork, or even properly managing the size of your Git repositories, there’s productivity to be gained.

Our focus here is on four activities that all software engineering managers should be doing that help to develop team productivity and capabilities. These four activities are also relevant for all developers, in-house, outstaffed, or outsourced. When engaged, they provide a return on the investment over time while dismissing them can lead to a bevy of troubles from slower cycle time, more bugs and more rework, to higher turnover.

Performance analytics

Here, we’re talking about using tools like WayDev, Gitential, or even Pluralsight Flow, to track company, project, team, and individual performance. Without an ability to objectively see how your developers are performing, you can only guess at the root causes of issues impeding their progress and your project. Without analytics, you also have no easy way of determining whether your team is getting better, worse, or stagnant over time.

But guess what? Performance analytics isn’t just for developers. It’s also for their engineering managers. The engineering manager has a high degree of influence and even control over their team’s performance. It’s the engineering manager’s responsibility to see to it that their team is continuously improving. That’s data that the CEO, CTO, and founders should be keeping an eye on. Again, software developer time is the single largest expense of software development.

Software development metrics include wide-ranging statistics like code churn, code complexity, pull request comments, velocity (lines of code), utilization. Some tools let you track developer activity by programming language, too. While stand-alone metrics have little value; taken together, contextually, over time, they provide enormous value.

This data can help identify probable root causes of common problems like excessive code churn, perfectionist coding, high code complexity, developer burnout, and more. Performance metrics can guide code review pairing and mentors based on objective measurements of expertise. You might pair a developer with high code complexity with a developer who has more concise code; or break their story points up into smaller, discrete tasks. You can see if your most productive developers are getting overloaded or burning out. High utilization and/or multi-tasking reduces efficiency and productivity.

Guiding Pull Request commenting

A developer metric of its own, it’s standard practice for developers to never commit code that hasn’t been reviewed by another developer. Developers who review the code are responsible for pointing out any issues (code structure, complexity, readability, etc.) they come across via comments for the original developer to fix and resubmit. If they don’t kick it back, they’re effectively recommending the code is good to commit/merge, depending on workflow, with the main branch of the codebase.

This process can have issues depending upon team size, composition, and maturity. The software engineer’s tasks with pull request comments involve:

  • Engineering managers can pre-empt nitpicky comments over style issues by mandating their team uses linter programs configured to enforce your team’s style guide. This ensures review time focuses on more substantive issues.
  • Helping all developers provide useful feedback – avoid insults, question what they don’t understand, suggest alternative approaches, and generally scrutinize code based on all of the principles they apply when writing code.
  • Reviewers should have competence in the code they are reviewing. This can be problematic if you have many junior and few mid-level or senior developers. To help moderate the pull request review load across the entire team, Story-splitting is a partial solution. It may require you and a senior developer to help your Scrum Master better define small, discrete, meaningful, and logical tasks.
  • Ideally, pull requests should be picked up within 2 hours of submission. Some teams may take 2 days or more. At a minimum, the delay means that the original developer is likely moving onto another task and must later re-orientate to fix defects in their earlier code. Sounds trivial until you compound the time for all of your developers over the course of a couple of Sprints.

Lines of Code actually is a relevant measurement if we’re enforcing that all code must be independently reviewed before it’s committed. This goes back to performance analytics. If your developers are generating an average of 800 LOC per day, at least two hours per developer needs to be allocated for code reviews.

Peer code reviews and walkthroughs

What, more reviews? Oh yes. Peer code reviews should actually start before the developer writes any code. The idea is for developers to talk with each other about what approach they will use to help ensure they start and stay on the right track.

Walkthroughs are an opportunity for senior developers to highlight best practices for coding, architecture, technique, and solve unusual problems, with junior developers. Reverse walkthroughs are also an option, allowing senior developers to question juniors about specific aspects of code to see “where they are.” It’s sort of like going back to high school where the teacher asks questions and calls upon students to explain.

In these activities, the software engineering manager can again draw upon performance analytics to provide better peer code review pairing and identify cases for walkthroughs. For some examples:

  • The manager may pair up developers based on the programming languages they are learning. That’s even better when you have one good with C++ wanting to learn Python and another who’s great at Python who wants to learn more C++. Agile teams favor cross-functionality.
  • The manager may see one developer’s code is always complex, more verbose than it needs to be, and also has issues with test coverage. Why not pair them with a developer with a history of writing concise code with high test coverage?
  • With vast libraries of open source projects, engineering managers can work with senior developers to assess upcoming challenges and identify examples of both good and bad code to cover in walkthroughs. The engineering manager can use analytics to define the issues that have challenged their team the most.
Did you know that Ukraine is one of the best places to hire developers?

If so, this handy calculator will help determine how much it would cost.

Calculate now

One-on-one meetings

A major aspect of the software engineer’s role is getting to know their team members. One-on-one meetings are a perfect venue to do this. Regular meetings help to build trust, transparency, accountability, simplify challenges, and keep everyone aligned on project objectives. Just as importantly, they provide a mutual feedback loop.

Engineering managers can identify challenges developers are having with their tasks and walk them through to find solutions. Equally, this is the perfect time for the engineering manager to ask their developers how they can do their job better. What can the manager do to help the developer code more productively or efficiently, with higher quality, or in team collaboration processes?

A study by Gallup indicated managers who are open to feedback have ~15% lower turnover and are ~9% more profitable. Regular one-to-one meetings reinforce accountability and greatly amplify the chances both parties will keep their commitments by as much as 95%.

At a minimum, one-on-ones should be conducted with each team member monthly. Perhaps counterintuitively, high-growth companies should conduct one-on-ones weekly or biweekly. An increased cadence helps to keep team members aligned even during peak chaos and is critical to avoid ultra-high turnover (25+%) rates common to high-tech startups.

Must these tasks include outstaffed developers, too?

Anyone who is working on your project as a designer, developer, tester, software architect, or another specialized technical role – is part of your team. Mid- and long-term staff should be engaged just like in-house developers in every regard except pay and benefits, which are handled by their agency. If you are outsourcing a project though, all of this should be handled by the agency’s own engineering manager.

For short-term staff (90 days or less), some of these activities may be condensed. Performance analytics scales in proportion to the duration a developer is on your team, though analytics will still help you identify low and high performers. One-on-one meetings for short-term staff are likely to be condensed to an initial evaluation, midstream checkup, and final review of deliverables.

We can help with your IT staffing requirements

Maybe you’d like to talk about your IT staffing requirements and how we can help you extend your team with Ukrainian software developers? Call us toll-free at 1-800-PERCEPTIONBOX or please use the form below. Also, you can get a no-obligation quote using our Team Cost Calculator. Tell us what you need and we’ll get back to you asap with the current going rates.



Tell us about what you are trying to build

  • Hidden
  • This field is for validation purposes and should be left unchanged.

Subscribe to our newsletter

  • This field is for validation purposes and should be left unchanged.