These are my views and approaches on leading software development teams and managing people in general. They come from the culmination of a few years of on-and-off leadership, and a lifetime of observation (plus a share of suffering under poor regimes along the way).

In no particular order:

• Work for your team.
• Protect your team.
• Never pass problems down the line.
• Don’t talk about money with the team. They don’t need to know if the project is running over budget. They don’t even need to know the budget. That’s a management concern, not a worker’s concern.
  (Definitely, don’t use budget issues as a motivator to make the team work more.)
• Push back on upper management if their requests and expectations are unreasonable.
• Give the team the tools they need to do their job.
• Don’t be cheap on tools and equipment. Supply computers with appropriate specifications, decent chairs, multiple monitors.
• Give the team the information they need to do their job.
• Give the team the support they need to do their job.
• Be patient.
• Don’t reprimand people. Be a “guide” for team members not performing to your standards.
• Be very clear about standards and KPIs if you’re going to hold people to them.
• If someone is not performing to a standard you expect, talk with them, work with them, help them be better. Raise the issue and talk to them early (don’t wait until the annual performance review).
• Leadership and management will mean tough, icky conversations. If you don’t have the stomach for that, don’t do the job. Skirting tough conversations is dangerous for the team and work outcomes.
• Don’t set estimates when you already have a deadline in mind. Just say the deadline and work with the team to figure out how to deliver.
• Don’t ask for estimates then hold people to it (Dr Evil style). It’s called an estimate for a reason.
• Software estimation is hard. Really hard. Really, very hard. Always remember that.
• Be clear about deadlines. And why the deadline was set.
• Realise that almost every single software delivery deadline set by business is arbitrary. And will slip. And people will burn out and get angry pushing to deliver for a deadline that slips anyway.
• Agile “story points” only work in true agile projects that don’t have time-based deadlines. Those projects are rarer than hen’s teeth.
• If you’re going to hold a team to story point velocity, you’re doing it wrong (and everyone better be very clear from day one what the real effort of a point is).
• You have smart, capable people in your team. Let them think and contribute.
• Team discussion is good, healthy, and expected.
• After the discussion, the decision at the end of the day is yours. That’s part of your responsibility.
• Don’t dictate to people. Direct and guide.
• Good leaders realise they have a team of smarter people or capable people, and enable the team to do good work. That’s the job of a leader – enabling.
• Don’t allow or make people feel guilty about mistakes.
• Understand the hurdles people face. Understand their problems. Understand the blockers.
• Understand what’s slowing people down. It’s not about working people like slaves but making sure the natural pace is not slowed down (e.g. by inadequate equipment, poor process, lack of understanding, stress bubbling from management).
• Don’t push people like slaves.
• People are people, not resources. Never call a person a resource.
• Praise goes to the team. Blame stops with leaders (never pass blame down to the team). A leader’s reward for a job well done is internal satisfaction.
• Software developers need time to breath, take a break, and refresh during the day. And during the week. And periodically over a long, hard project.
• Software coders should not be in front of their computer coding 8 hours per day. If they’re doing that then something is wrong.
• Working software developers hard for long periods will lead to burn-out and discontent.
• I don’t believe a rewards or hall-of-fame type system should exist for people who do extra work (hours) or produce extra stuff. That a) is the encouragement of overtime and, b) isolates the 90% of good people just getting their job done.
• Don’t ask for overtime. Ever. (Unless you can absolutely guarantee a time-off-in-lieu soon after the reason for overtime has passed). Overtime just means fuck-up somewhere up the management or sales chain that software developers are going to pay for by fixing it.
• Ask what people enjoy doing and want to do. What motivates people? What are their interests?
• Give people training.
• Give people support in career progression.
• Don’t presume you know everything as a leader/manager – you don’t. Don’t presume you have all the answers – you don’t. That’s not your job.
• Leaders don’t need to know everything. That’s why you have a team.
• A leader’s job is to have enough knowledge and experience to ask the right questions, trust their staff, do research and make good decisions.
• Draw the best knowledge, experience and ability out of people in the team.
• A leader needs to be “people” person. They need good social and communication skills. They need empathy and reflection. They need patience and a thick skin.
  Managers also need at least some of this.
• Never assume a team member has a certain level of knowledge, especially in software languages, technology and tooling. For example, don’t assume everyone has the same level of Git knowledge (I recently made that mistake and had to correct it). Keep asking questions – basic questions – to understand everyone’s knowledge and comfort levels.
• Listen.
• Don’t talk “at” people.
• Don’t talk over people.
• Don’t micromanage your team, even those who are slow or make mistakes. Micromanaging is just a band-aid. If there’s a problem, work at finding and resolving the root cause – whether it’s a change of process, education or allowing someone time to learn and practice a new way of thinking and working.
  Often a problem one person is having is a [silent] common problem across a team.
  A soldier needs to learn to shoot a rifle on their own. Different soldiers need different paths to reach proficiency. A leader’s job is to help each person on their own path, so when the time comes to use the rifle each soldier can do it on their own without a leader on their shoulder telling them what to do.
• Keep processes simple.
  Keep simple checklists.
  Keep help easy to find.
  Think like soldiers and pilots.
• Document. Document. Review. Document.
• Never stop thinking about how to improve processes, information, and team conditions.
• Never bring your ego.

Finally:

• Don’t elevate a good senior technical person to a lead role that they’re not prepared for, wanting to do, or able to do.
  I’ve seen too many good “senior developers” with poor people skills placed in a lead role that end up hurting teams (at worst the team and project becomes toxic).
  Leave technical people in technical roles.