Over the years, I've spent time as a Developer, Project Lead, and Scrum Product Owner as well as a manager. In managers, I started to identify traits felt worked well, and then traits that didn't. I started curating a list of what I felt worked best. This is a living list and I occasionally change things as a I learn.
- Serve The Team
- Management is a service position. Be sensitive to the needs of the team as they rely on you to find resources, eliminate distractions, help with organization, resolve conflicts, communicate important information, and help provide redirection when things go wrong.
- Help With Conflict Resolution
- There will always be personality conflicts within a group. Sometimes it takes someone with the "manager" title to help diffuse them.
- Provide Resources
- Every product owner, stakeholder, and customer is going to advocate for their interests (as they should). Relationships will develop as folks become familiar with the needs of others. Yet, the resources of a technology department are finite. The manager needs to spend time understanding these needs and how they reflect to business value so resources can be spent where they have the most impact.
- Communicate The Wider Vision
- With greater exposure to the long term vision of an organization, the manager holds valuable information to share about where the organization is going. Although it's important that the team understand these things, they shouldn't have to sit through hours of meetings to gather them.
- Provide External Visibility
- The team is focused on their project. The Manager has bandwidth to get visibility into the projects of other groups by communication with other managers. This can can then be exposed to the team to point them into areas that will need their attention.
- Help With Meeting Attendance
- A single one hour meeting can cost between 4 and 8 hours of development productivity. However, as someone who already attends meetings full time, the manager's cost of attending meetings is low. The manager then has the ability to communicate the important and critical points back to the team.
- Allow The Team To Work Out Their Process
- Documentation, task/bug/defect/story tracking, version control, tests, design reviews, code reviews, testing, and documentation are all very important parts of software development. They are the things that separate a "Programmer" from a "Software Engineer". As a software engineer has these things in their wheelhouse, the manager should respect the decisions of the team. A manager should suggest ways things could be better, help evaluate options, and help build consensus if folks can't agree, but ultimately, it's up to the team.
- Allow Room To Take Risks
- The team is going to make wrong decisions, and do risky things. It's important that management give the team room to to do this.
- Keep A High Level
- Management maintains a close relationship with other managers so they may make suggestions around priorities and staffing. Certainly the manager should work with the team on the long term roadmap. However, there should also be room for folks to experiment. A developer may pick up a small task in between meetings or respond to an e-mail that is not a primary task and they need the freedom to do this.
- Suggest Opportunities For Growth
- Whether it's specific training opportunities, advanced education, speaking and interview opportunities, professional organizations, or cross divisional relationships, the manager should aggressively search out these opportunities for the team and make them aware. Folks do their best work when aligned with their passion. Although management might have a passion for a particular process, language, or platform, this might not be same as the passions of their people. People should be allowed to follow their own passion as much as reasonably possible.
- Manage By Walk Around
- Management is something that has to be done in person. Get out and talk with the team every day. Video conference and phone calls are not the same.
