So you’ve worked out what kind of application you need to create, and now it’s time to build the team to do it. What you do now will have a profound effect on the success of your development. For the sake of this discussion, I’ll focus on the composition of the team, and not on recruiting specific people; that’s a whole different topic.
First, let’s start with that word “team.” One person is not a team, so don’t think that all you need to do is “find a really good programmer” to build your application. No one can develop an application well in isolation.
Sure, if you need a very small, targeted app, you can probably do it with one programmer (although you’ll still have to work out usability; your nose-to-the-code programmers are not usually good at that).
Any serious application development effort requires a multidisciplinary team. How big a team, and how many disciplines, is determined by the scale and nature of the project.
There are some basic team composition ideas that we can work with. In talking about this it helps to avoid actual job titles; those are always loaded with preconceptions and emotions that get in the way of rational thought. Save the titles for when you do the recruiting.
It’s difficult to talk about the team without talking about the process, but that’s also a larger discussion best left for another time. All you need to know is that the process best suited to customer-facing applications is called “Agile” (in particular, a flavor of it called “Agile Scrum,” perhaps so named because developing applications is as much fun as having two dozen rugby players fall on you).
Don’t be tempted to put yourself on this team. You may think you know your customer better than anyone, or perhaps you’ve done development and think you can lead this effort. But you’re probably involved in so many other things in your business that you will have a hard time being a productive participant in this effort. There is no “U” in Team. The best teams include:
User Representative
This person represents the needs and wants of your user. They know how users think, what they care about, and what frustrates them. They “negotiate” with the development team, helping to set priorities based on their understanding of what’s important to the user/customer. Ideally this person should come from the “business” side—such as a product manager or business analyst.
Designer
As we’ve discussed, your team needs this on some level, depending upon the nature of the application. It might be a single user-experience designer, or you may need a human factors expert if things are complicated. But be careful. There’s a difference between “design” and “art.” There are “user interface designers” who are able to create beautiful-looking screens, but who do not understand the usability issues that inform proper design.
Leader
You may hear from Agile followers that there are no leaders anymore, in the traditional sense. Everyone is supposed to work together equally (and interchangeably) toward a common goal. But in development, as in most walks of life, every group of people united by some mission longs for a leader. Someone to make decisions, to inspire, and to motivate. Just remember that there is a difference between leading and managing; developers like to be led, but they do not appreciate being managed.
The leader is most often a developer, because that’s where leadership is most often needed: choosing programming languages, debating the relative merits of different frameworks, and so on. You’ll want an alpha male or female, who is respected and can lead the team with grace and wisdom. But the leader must also have a strong feel for the whole picture, including business goals; the customer’s perspective and desires; a realistic sense of what the team can accomplish; and an appreciation for how similar applications have been developed by competitors.
Developers
These are your builders. They crank out code all day, and are happy to do it. There are subtle differences between developers, programmers, and coders, but overall they are the ones cutting the stones and building your cathedral. They come in many different forms, and while we’re not going to go into the details of recruiting, it helps to at least understand the three main types of developers.
There are the plodders
They’ve learned one tool or language (maybe two) and they are inclined to stick with that tool going forward. Yes, they can learn new languages and skills, but mostly they will only do that if it’s a job requirement. They do yeoman’s work. They can get bogged down and often fail to ask for help, because they often don’t interact successfully with other human beings.
There are rock stars
brilliant developers who can tear through code, often to the admiration and envy of their peers. Avoid them. Their resumes will be incredibly impressive, but when you put them to work, you won’t get what you need out of them. You will get what they think you need. That said, if you’re up against an impossible deadline and you have solid design for usability and a strong leader to guide things, rock stars can be useful. Especially for challenging backend code that doesn’t face the user.
In between are the innovators
They are not afraid to try new things—a very important trait in a successful developer. While they are open to experimentation, they also have a sense of appropriateness; they do not make arbitrary choices. Innovators recognize and deal with roadblocks. (“Wait. This isn’t working. We need to recognize this and discuss alternatives.”) The innovator will look for another way to solve the problem, working with, and at times guiding, the rest of the team. Most leaders are innovators; when you find one, don’t let go.
Testers
A tenet of Agile is that every sprint produces a working release that can be shown to users, so your team needs testers. Many organizations have a “quality assurance department” that waits for the developers to say it’s all done before they go in and test things. In Agile, it’s different; the testers are an integral part of the team. At the start of the sprint, they listen to what the team says they will be building, and they figure out how they will test it. They share that with the team—the “acceptance criteria” of the work—so the developers know what it means to be “done.” They test early and often, and they communicate constantly with the developers.
Playing well with others
We touched briefly on how some people are better fit for a team than others, but it bears a closer look. You can spend a lot of time studying team dynamics; you probably should (and you probably have). But for now let’s consider the qualities that you should look for in everyone you add to your development team:
Communication
Good teamwork requires clear, unambiguous communication. That includes speaking and writing. Email, messaging, and issue-tracking systems are the most common channels, but team meetings are also important. Phones are often involved. So the ability to communicate verbally is a critical skill, and is particularly important for those who need to communicate outside the team with users, customers, or the company’s stakeholders.
Empathy
Something often lacking in developers, and especially in rock star developers, is an appreciation for other people’s issues, concerns, and feelings. That’s been an issue since the first cavemen got together to discuss making a fire, but it is magnified by the fast pace, unpredictability, and high pressure of application development.
Collaboration and humility
This is the willingness to leave your ego home, accept criticism, be open to change, and forego your own needs for the good of the team. This is what makes a “team player.”
Proper software development methodologies begin with having a great team. I won’t say you can’t succeed without the right people, but you’ll certainly need some luck. Best to have the right people, doing the right jobs, at the outset.
This article was excerpted and adapted from The CEO’s Guide to Creating Great Software for Your Customers, When Software Isn’t What You Do, by Frank Zinghini. Click here to download the full guide for free.
hbspt.cta.load(2637494, ‘7be9b60b-533e-4a11-9fb1-d6f541024810’, {});
