5 Techniques to Get the Most Out of Your Software Team

softwater-team-meeting

Congrats! You have identified a high-performing, top-notch software development team to design and build your product. (If you are still looking for a team read this.) Want to know how to get the most out of the team? Below are 5 techniques to turn up the high-performance dial.

1. Learn the Process

Good software teams tend to have a software development process that they follow, and those processes are commonly well documented. Ask the team for recommendations about what books you should read to better understand their process. Read the books and then ask follow-up questions. Understanding how your team works makes everyone’s life easier. This small gesture and commitment will garner a lot of respect from the team.

If you work for another organization, and that organization requires a separate process (gates, documentation, reports, etc.), then work with the team to figure out how you can meet the needs of your organization without changing how the team works. It is easier to tweak the team’s process to meet your organizations needs, then force the team to switch to your organization’s process.

2. Be Available & Participate

Good teams will want your active involvement. During a software project, concepts will be refined on a daily basis. Decisions will need to be made about the richness of features, integration with other systems, user experience, new opportunities, and budgetary constraints. Not being actively involved in this process can cause frustration and rework.

Before you start working with your team, makes sure you have proper time allocated. Plan on at least a few full days to kickoff the project and then at least 2-5 hours per week after that.

The actual amount of time required will vary between projects. Work with your team to determine the amount required for success.

3. Give Your Team All the Information They Need

Share everything you know. Software teams are amazing at identifying, prioritizing, and implementing solutions given high-level constraints. Not taking the time to educate your team and instead simply feeding them low-level feature requirements is penny wise and pound foolish.

Most importantly, communicate your high-level business goals and your personal goals:

  • How do you make money?
  • What value is being exchanged?
  • Who pays for the software?
  • How does this affect your personal career?

And discuss the people that are going to use the software:

  • What do they value?
  • What are their goals?
  • How do they find the software?
  • When do they use the software?

If your team understands your business goals and the needs of your users, they can more easily present tradeoffs and alternative implementation ideas that most likely are more effective and less expensive.

4. Challenge Your Team

Setting aggressive but possible milestones is a wonderful way to focus the team’s energy and build product excitement. The key to making the milestones feel real to everyone on the team is to make the milestones real. Identify outside opportunities that are associated with calendar dates, such as like trade shows, beta-releases, real customer usability testing, etc.

Work with your team to define a plan and possible set of functionality. Work hand-in-hand with the team to meet the deadline, and the team will go above and beyond and make it a reality. Nothing brings out creative thinking like real deadlines and camaraderie.

5. Trust Your Team

Trust is the key to every relationship. One of the biggest fears of many software makers is lack of trust. Since you are driving the team, the trust needs to start with you.

It’s also important to realize that by nature, software makers are extremely loyal people (at least the ones we hire). Show them trust, and they will reward you by caring as deeply about your product as you do. You’ll be surprised by the loyalty you’ll receive from your software team — they want to win as much as you do. At Atomic, it’s not uncommon for our makers to prioritize the needs of their clients over the needs of Atomic. This can be difficult at times, but we wouldn’t have it any other way.

Here are some simple ways that you can extend trust to your team.

  • Trust their estimates.
  • Trust their technology choices.
  • Listen to and consider their ideas.
  • Be willing to conduct controlled experiments.

What other techniques have people used to get the most of their software teams?