“My dev team is failing, what software process should we use to be more successful?”
“My dev team keeps missing their deliverables, what task management software should I use so they hit their commitments?”
“I’m not a very fast runner, what shoes should I buy to make me faster?”
“I’m a horrible cook, what knife should I use to make a really tasty meal?”

I get asked variations on these questions several times a month. You’d think by now I’d be better at answering them. Sadly, I still get this flutter of panic when I hear these questions where I run through my head the best way to unwind the web of assumptions behind these questions. This is where I begin visibly grimacing and possibly sighing. I then start responding with something like “well…. it depends… hmm…” And then I feel guilty for dodging the question when clearly they just want a simple answer and why won’t I just tell them the secret?

The problem is software process, task management software, shoes, and knives are just tools. Having horrible tools can lead you to fail, but having great tools doesn’t make you succeed. What most people don’t want to hear is that success has more to do with preparation, persistence and a lot of hard work. There is no secret. I have learned a few lessons over the years though, and what follows is what I consider to be important when leading a successful development team.

1. You don’t manage a bad team to be good, you build a good team and it mostly ends up managing itself. People always tell me that the things I do only work because I have a good team. That is because at least 40% of my time is spent on strictly building the team. Recruiting, mentoring, coaching, training. These activities take time to come to fruition and hard work, so don’t expect immediate results. Your persistence will pay off though. One of the best ways to build your team is by giving them accountability so they can practice exercising good judgement. Too many managers hoard decision making, prioritization and return on investment analysis. For example, make someone on your team accountable for the operational excellence of your team. Work with them to establish metrics for their success, have them come up with and prioritize the activities that will improve operational excellence. Be their mentor or find them a good mentor so they are setup for success in their role, but don’t undermine their authority by overriding them. Do this with as much of your manager responsibilities as you possibly can and constantly give your team members more accountability as they grow. Keep doing it until you worry that you’ll have nothing left to do yourself.
2. Craft a long, medium and short term vision by deeply understanding your customers. On each of these time horizons, members of the team should be able to answer the question “What value is my team providing?” and “What value should my team provide?” Ask yourself how your team can be even better. How could your team create even more value? Don’t just do this in a bubble but get out there and learn more about your customers. Read individual customer feedback and piece together patterns that allow your team to deliver even greater value. This isn’t a one time activity but a never ending journey of both refining your team’s vision and building relationships with your customers.
3. It is critical that you understand the role of trust in creating your process. 90% of the process development teams build up is due to a lack of trust, both within the team and between the team and others. Detailed specifications are asked for because the people asking for functionality don’t trust the developers to build the right thing. Commitments are asked for because people don’t trust the developers to work hard and on the right priorities. These process artifacts take time though that take away from the time the team could be spending on creating more value. Ask yourself, is it possible that by building more trust we can run a lighter process that spends more time on creating value? This question should be approached honestly because the answer isn’t always yes but frequently is.
4. Manage complexity through iteration, not planning. Most software is not simple and unambiguous. If you are have people using your software directly, it is almost guaranteed to be complex. Humans and their organizations are infallible generators of complexity. The more ambiguous or complex the problem the more aggressive you should be about iteration. Aggressive iteration means being unafraid of throwaway work for the sake of getting a feature out earlier. Aggressive iteration means actually getting the software used though, an unused feature is a feature you aren’t learning from. As a side benefit, iteration is a powerful way to generate trust with customers and management. A productive development team that is regularly demonstrating working, valuable functionality will be more appreciated and have more autonomy.
5. Establish a planning horizon for your team that matches your business. Fast iteration isn’t an excuse for short term thinking. In my experience too many managers sacrifice long term value chasing after short term results. You need to consider the long term ramifications of your decisions. What is considered long term should match the context of your business. If you are in a fast moving startup that is trying to be the first to market, you should probably optimize for something closer to a 3 month planning horizon than a 3 year horizon. The shorter the planning horizon, the more you can ignore trust issues, technical debt, operational inefficiency, etc. because none of those will matter unless you have a successful product. On the other hand, if you are in a more stable environment with a long planning horizon, a heavy investment in operational efficiency and building trust will pay dividends and be much more cost effective in the long run.
6. A team needs a way to understand their long term success. The mistake most people make is they focus first on what is measurable rather than what is important. This leads to ridiculous measures of value like lines of code, story points, estimated accuracy, etc. It can be hard to wrap your head around what success looks like though. Engage your team, your own managers and your customers with the same question. Eventually you’ll come to a true measure of your success. The benefit of having that measure goes beyond just knowing what success looks like though. It gives your team autonomy in how they accomplish that success. Without a valid measure of success, your team will be more subject to signing up for arbitrary project deliverables. With a measure of success though, you can commit yourself to that end result, but maintain the freedom along the way in the best way to accomplish it.
7. Have fun, be ethical and treat people with respect. Seriously. You have only one life to live and the only measure of a well lived life is to be a good person doing good things. Never sacrifice that for creating more business value or other worldly success. I once worked for a company with massive internal strife. We argued endlessly about minutiae that seemed important at the time, gossiped, disrespected and hated each other. Everyone thought everyone else was an idiot. Then one day in the middle of all this we got called into a conference room to be told that our entire division had been laid off. All of a sudden our petty disagreements all went out the window and I once again saw my former coworkers as people again. I’m not saying to be soft, if someone isn’t delivering on a team then that needs to be dealt with, but that is never an excuse for disrespect.

And now you know what I’ve learned so far about how to lead successful software development teams.