Five hundred words about software management

I’ve been managing people for a few years, and I’ve realized that this term means a lot of different things to a lot of different people. As someone who made the jump from technical contributor to manager, I’d like to write down what it means to me.

My job is to build strong teams and get things done with them.

Building a strong team means finding the right people and avoiding the wrong people. The right people are technically strong, but that is only the beginning. Individually, they are also good team players, they have positive attitudes, and they embrace challenge and change. Collectively, they are diverse in skills, experience levels, backgrounds, and philosophies, so that multiple perspectives are brought into discussions. The team is cross-functional, together possessing all needed skills. The team is motivated and engaged.

Software teams get things done by following a consistent process. Some processes are better than others, but any process is better than chaos. I personally prefer agile processes that allow teams to focus for a period of time, but also adjust to market feedback and changing requirements. To align around a process requires many good behaviors. Communication has to be strong, and team members have to hold themselves and each other accountable.

In understanding how I contribute to all of this, I have been inspired by the work of Daniel Pink in Drive. He talks about motivation coming from three factors; autonomy, mastery, and purpose. Give people the power to make decisions. Give them the training and tools they need. Show them the value of their work. Results will follow. It is a valuable exercise to regularly reflect on whether and how actions have helped the team grow in autonomy, mastery, and/or purpose.

All very nice, but what does the actual job consist of?

  • Hiring the right people.
  • Communication with team members, other managers, and other members of the organization who can influence team success.
  • 1-on-1 meetings are so important they get their own bullet. Every two weeks and they don’t get cancelled.
  • Obtaining training and other resources.
  • Identifying career growth goals and helping people progress towards them.
  • Discovering impediments to motivation and helping the employee solve them.
  • Figuring out what is “just enough” structure.
  • Delegating tasks, sometimes the fun ones, to give someone else a chance to grow and shine.
  • Feedback, both positive and constructive. Fairness in everything but especially this.
  • Knowing when to let the team take a chance and possibly fail with learning, and when to provide guidance.
  • Promoting good software development practices while being open to team self-determination.
  • Coaching teams to grow in autonomy and self-organization.
  • Being a good role model.
  • Believing in people.

What I expressly try not to do:

  • The team’s design/coding/code reviews.

It’s fine to pitch in when it’s needed (people rarely turn down testing help) but teams that depend too much on a manager are not built to maintain success. Instead of doing the work, create the conditions for the team to successfully do it.

(OK, phew. 500 on the nose. Comments welcome!)