Blog
/
Work Culture
/
How to manage a Software Development team: What your devs won’t tell you

How to manage a Software Development team: What your devs won’t tell you

Cathy Reisenwitz
Content, Clockwise
July 1, 2021
Updated on:

How to manage a Software Development team: What your devs won’t tell you
Photo by 

When I asked my friends for their tips on how to manage a software development team effectively, one of them simply replied with this GIF:

Accurate, if not super helpful. If management were easy, everyone would do it and you’d get paid a lot less. The good news: You can learn how to be a good Engineering Manager. Especially if you listen to Engineers talk about how they want to be managed. Read on for some awesome effective software team management tips.

Managing a Software Development team comes down to five things. A great Engineering Manager offers their reports the right:

  1. Tools
  2. Processes
  3. Information
  4. Esteem
  5. Autonomy

Here’s what that looks like and how to do it for your team.


1. Tools

To begin, ensure your Engineers have all the tools they need to do their jobs. Architecture investments like software, infrastructure, and build pipelines pay off. They enable your developers to focus on delivering business value and spend less time on troubleshooting and manual work. These kinds of investments are much cheaper than replacing Devs who don’t want to do busywork.

Let your Engineers choose their own tools. “Be precise about the product you want to build, let your technical team decide the tech they want to use to build it,” Developer Joshua Goldbard said.

The one thing all Engineers need to do their jobs is uninterrupted Focus Time to write code. Over and over, I heard Engineers say they want their managers to protect them from distractions like meetings and noise so they can focus on delivering. “Provide a quiet place for them to work (ie. no open office floor plans),” Jeff Darchmare told me. “Help them avoid meetings.”

Developer Richard Mehlinger referred to the classic Paul Graham essay on the maker schedule vs. manager schedule. “Try to get all of your team's meetings on one day so that the rest of the week can be focused on development,” Mehlinger said.

Andrew Hinkens said he wants managers to “Minimize distractions by grouping meetings and allowing devs to block their calendar with do not disturb time.”

(Note: Clockwise uses AI to group your meetings together and block your calendar with Focus Time automatically.)

2. Processes

Like the right tools, the right processes save time and energy, helping your Developers get more done with less effort.

Many Engineers spoke highly of Agile methodologies. “A one-week sprint is almost too short to finish big user stories, but two weeks allows time for vacations and unexpected issues,” Developer Emily Nicole said. “Daily stand-up meetings help me understand what everyone is working on and get a feel for the pace of the rest of the team (and ask for help when I need it).”

“Make sure it's *actually* Agile,” Developer Matt Gilliland wrote. “Lots of people say they do Agile, and what they mean is that they do a bunch of processes that someone learned in a workshop or a book that were labeled ‘Agile.’ Agile is a philosophy about how you choose your processes, and not a set of processes itself. ‘Agile’ teams can easily end up micromanage-y and bureaucratic by stacking on a bunch of ‘Agile’ processes that didn't make sense for the team or for the work, usually at the behest of a former manager turned ‘Agile coach’ who is trying to stay relevant without actually understanding what a truly agile team looks like.”

Developer Chris Rogers concurs. “The most agile thing about Agile is you can be Agile in how you implement it,” Rogers wrote. Developer Francis Bacon warns Managers, “Agile must remain an adjective and not a noun.”

Richard Mehlinger recommends managers reserve 20% of the team's time for dealing with technical debt and architectural improvements. Otherwise, your devs are likely to have to stop progress for emergency bug fixes. That, plus cruft (overly complex code) may cause everything to start taking longer. “Too many PMs will try to devote 150% of your team's time to the feature release treadmill if you let them,” Mehlinger said.

Another place for a good process: division of labor. In Francis Bacon’s world, Product Managers decide what gets built and in what order and development decides how long each unit will take. For Emily Nicole’s team, Devs decide the upstream and downstream dependencies for stories, but managers decide the views/screens. Making sure everyone knows what their role is, and isn’t, is as important as who does what.

3. Information

Effective Engineering management requires connecting your team with your customers and the rest of the organization. To succeed, your Devs should understand your customers, target audience, and the needs and constraints of the rest of the organization. This helps them define a path to delivering software your target audience will find useful and pay for. You need to decide when Devs should speak directly with external teams and partners and when you can relay pertinent information to them.

Software Engineer Maura Hubbell: “The nature of the day-to-day work encourages the kind of tunnel vision that excludes big-picture organizational objectives. As a manager, you're going to have to keep reminding your team about those objectives and champion them.”

Once your team understands the project as a whole, help them break it down into component pieces and set ambitious-but-realistic deadlines. “Budget 25% more time for what you expect,” Holdbrooks said. “Underpromise and overdeliver with margins for the unexpected.”

Proactively deal with unknown unknowns by making every request as specific as possible. “Plan as much as you can before setting timelines,” Developer Andrew Hinkens said.

“I hate dealing with entire projects,” Software Developer Jacqueline Pickrell told me. “It can feel like ‘step one, climb mountain.’ Breaking it down can make it feel more manageable and allow for more critical thinking on features at the start.”

Your job is also to protect your team’s Focus Time from executives and Product Managers. “Be vigilant on what is asked of or needed from you to pass along to your team,” Developer Nick 'ickna' Holdbrooks said. “Watch out for scope creep from above and technical debt from below, both of which can torpedo your deadlines in a hurry.”

All pertinent information should live online in an easy-to-navigate repository. This is vital for managing a remote team but it’s also helpful, no matter your working environment. Managers should “Get really, really good at documentation,” Data Scientist Steve Spalding told me. “Developing good processes to manage the creation, organization, dissemination, and proper use of documentation can be a game-changer.”

People Ops pro Austin Carrington Carmichael recommends Engineering Managers bring all relevant information into Confluence or another kind of internal Wiki. Having your company handbook, policies, etc. in one place means Engineers with questions outside of HR’s working hours still have access.

4. Esteem

When it comes to strengths and weaknesses in software development, there’s a lot of understandable focus on so-called “hard skills.” However, the so-called “soft skills” like empathy, authenticity, and kindness are equally necessary for building software in a team environment.

“The Law of Expectations means that whatever you think of your employees, you're right – and their performance will rise or fall to your level of expectation to prove the point,” Executive Coach Gary Winters wrote.

One of your primary jobs as a leader is to believe in your reports and show them that you believe in them and care about their well-being. This will help motivate them and help with effective communication. “Devs tend to be awful at caring for their physical selves,” Darchmare said. “Spring for a good chair, ergonomic keyboard, large external display, lighting that doesn't give them headaches, etc. It'll pay off in productivity over the long run.”

Keep your expectations realistic. “Software development is highly cerebral, and - frankly - can be exhausting,” Darchmare said. “Don't expect eight hours of continuous code output just because they're on the clock for eight hours. Focus on the quality of deliverables they give you. That's what matters.”

Believe experienced Engineers when they say they don't know how long something will take. Show them you believe they want to improve by giving them honest feedback. “Be kind,” Joshua Goldbard advises. “Kind is often saying the hard things. People actually want feedback to grow. Hire people who have small egos as much as you can.”

Use good productivity metrics. “Don't allow anyone to use ‘blocker’ as a scarlet letter, Developer Thomas Martin advises.

5. Autonomy

Perhaps most importantly for managing a team, I heard over and over again that Devs need autonomy to do their best work. Holdbrooks put it well: “Give your people the why and general requirements and trust them on the how.”

Developer Ryan Tanaka advises managers to give Developers a problem to solve. “Don't give them instructions, just guidelines,” Tanaka said.

As much as possible, allow Devs to choose how, when, and where they work. Evaluate Devs based on their output and other metrics, not based on butt-in-chair time.

Promote the most productive, ambitious, and collaborative Devs to Tech Lead or other roles.

Going forward

Your job as a manager is to hire the right people, provide them with everything they need to succeed, and make sure they’re happy and stay put. Remember these five things and you’ll be well on your way to being a great Software Development manager:

  1. Tools
  2. Processes
  3. Information
  4. Esteem
  5. Autonomy

About the author

Cathy Reisenwitz

Cathy Reisenwitz is the former Head of Content at Clockwise. She has covered business software for six years and has been published in Newsweek, Forbes, the Daily Beast, VICE Motherboard, Reason magazine, Talking Points Memo and other publications.

Make your schedule work for you

More from Clockwise