LEADERSHIP AND YOUR TEAM

Let's accept as a rule that the best chance at app success rests with the people on your team. Therefore, for any size team, it's vitally important that competent leadership be demonstrated from the top down. Of course, not everyone was born a charismatic and natural leader. But, based on this author's experience, it is something that can be learned, practiced, and honed to at least semi-competency.

The following traits from those in a leadership position will be appreciated by the rest of your team, thus ensuring a smoother development process:

• Leave your ego at the door — The best leaders are those who make others feel valued. Lead by example, rather than expecting others to automatically follow because of your title or past achievements.
• Empower others — Allow others a sense of control and ownership over their parts, and they'll achieve much better results than when you hand-hold them. This also allows you more time to manage the project.
• Be positive and enthusiastic — Show that you're excited about the project and it will rub off on others.
• Accept criticism — Be willing to find the truth in any criticism, and how to politely ignore that which won't result in being productive.
• Be honest — If you're wrong, admit it and get back on track. If you don't know, find out or ask. Just don't pretend.
• Make decisions — Being indecisive is counter-productive to the team in that you're being relied upon for action. Learn to make decisions early so that you can maximize the time for action. Also, practice providing your team with some insight into your decision-making process so that they know you're not blindly making those decisions.
• Be reliable — Following through with your commitments and making decisions objectively (and without allowing emotion to tug you one way or another) demonstrates integrity. People respect and follow integrity.

Obviously, it takes much more than a few guidelines to become an efficient leader. However, these should provide a helpful framework or reminder for the mindset needed to complete an app.

Assumptions about Your Role

Because you've chosen to delve into this particular book, the advice presented here assumes that you want to become a factor in (or you already are a factor in) at least some of the major decision-making processes throughout development of your app. These will most typically include some or all of the following:

• Design and/or direction of a design document (sometimes referred to as a functional spec or specification)
• Creating/managing production schedules
• Assessing/planning milestones
• Directly hiring or managing in-house or external producer(s), designer(s), coder(s), audio engineer(s), and/or artist(s)
• Finding/evaluating new tools for efficiency
• Making frequent high-level decisions about adding/cutting features
• Managing the bug-tracking process
• Making marketing strategy decisions

The many (often simultaneous) processes shown here need at least a few people to manage in full. But the one role that manages most of these the best is the Producer. In the game industry, the Producer is typically responsible for planning, scheduling, hiring, assessing risk, managing teams, being aware of and mitigating development issues, facilitating getting things done, and making decisions on issues that crop up (with consensus being the goal).

Your Starting Lineup

Rather than go into too much in-depth examination of each role on a development team (other development books do that), and instead focusing on the business aspect, let's concentrate on team composition, the individuals you'll need to get things done, and what they'll do for you.

Producer

As mentioned previously, a Producer is the facilitator of action and the mitigator against risk. You'll have a team member performing this role to begin with and throughout development, even if someone on the team doesn't have this specific title. For very small teams, sometimes it's the lead programmer, one or both managing partners, or sometimes even the president of the company! It's the person wearing the Producer's hat who initially works with the Designer in fleshing out a game or app idea, and then facilitates getting it actually made throughout all development stages.

Designer(s)

At the beginning of a project, a Designer is the team member tasked with coming up with a detailed concept, and then (when the concept is approved) creating a functional design document or design plan. When work starts, the Designer will shift focus to testing early prototypes and iterating on the design to iron out flaws or tweak/cut existing features. Notice that adding new features was not included in that description — that's what's known as “feature creep,” and is usually bad for development schedules and the bottom line. You'll learn more about the design process soon.

For many small studios that are producing one or two apps, hiring a freelance designer makes more sense than having a full-time designer, even if that person helps out for the duration of the title. Because of complexity, a designer would more commonly help out throughout development of a game or full-featured application (for user experience tweaking) than for a simple app.

Programmer(s)

As perhaps one of your largest variables during development, it is crucial that you hire a Programmer, or put together a team with experience in your genre of app, and ask for references and demos. If it is a three-dimensional (3D) app, you'll want people who have proof that they have done that before. For example, many outsourcing “we can do it all” teams claim to have experience with interactive games, but actually outsource the work again to those with questionable track records.

Programmers will be responsible for early prototypes using placeholder art/sounds as necessary, and then for delivering normal milestone builds that can be tested frequently and iterated upon.

Artist(s)

Most apps need art, even if (or, rather, especially if) it's just for the App Store Icon. As you saw in Chapter 3, your art style is critical. Whether polished or unrefined, it will define your app, and should consistently match the theme and functionality you are trying to convey. If your app is a simple utility, it may be easy enough to get away with art mostly from the standard iPhone GUI library. However, in all likelihood, you'll need a bit here or there regardless of app type (for loading screens, icons, and so on), and even more so for games. For smaller studios, art is almost always outsourced.

Audio Engineer(s)

Although it may not be a problem for some simple apps, with most projects, a few sounds in key places can go a long way toward making your app feel fleshed out. The job of an Audio Engineer is almost always outsourced. Your Audio Engineer(s) will be responsible for music and/or required sound effects (commonly referred to as “sfx”) throughout your game or app. If you have talent within your studio, you can do this fairly cheaply using royalty-free libraries (with links provided in Appendix B). For games especially, it cannot be stressed enough how music and sound can influence not only the feel, but the responsiveness of your app.

Quality Assurance

Unless you're a major game application developer (and you may be), chances are you'll need a few people — rather than a full-time test house (those can be expensive) — helping to find bugs and entering them into a database for the Producer or Quality Assurance (QA) lead to assign to programmers. With smaller applications, this can be done in house. But for more complex apps, you'll definitely want to outsource QA. Of course, you will have to add in the cost of providing the test devices to these users, and be sure to keep legacy iOS devices kicking around just for this purpose!

Speaking of QA, there are now new innovations for testing applications. One such example is an actual integrated web and iOS app named TestFlight (https://testflightapp.com/). It automatically loads a provisioning profile onto test devices, and can make installing new builds seamless, wireless, and amazingly quick. It even has e-mail notifications when a new build is uploaded. This is a highly recommended approach!

Localization

Localization is the process of translating every word in your app to one or more languages using localization translators. The extra revenue you get from making your app available in multiple languages can be worth it if you can keep costs and implementation down using just one or two people managing the process, rather than adding another communication channel (such as at a full-service QA company). This translation is almost always outsourced.

Marketing

Prior to launch, you should have a marketing plan, and then budget accordingly so that, when released, as much “hype” and buzz as possible surrounds your app. How to do this is explained in the section “Coordinating Marketing,” later in this chapter. The better your app does initially, the easier it is to stay afloat, or even sail to success.

Parting Note about Roles

Whichever the role, for better production output and creativity, it's important that each individual on the team be autonomously empowered to take ownership of his or her particular task(s). With outsourced teams becoming more the norm, that communication should be effective and filtered through the right channels. You learn more about efficient methods of communication in the section, “Coordinating Outsourcing and Effective Communication,” later in this chapter.

With a good overview of the general functions each role provides for developing (and shipping!) a software product under your belt — in this case, for iOS devices — you'll have an easier time throughout development if you begin with the following advice that can help direct effective decision making.

A Controlling Idea to Kick Things Off

At the beginning of development, it is important for everyone to be on the same page as far as the overall direction of the project (which can prevent questions and problems down the line). Those who are in charge should come up with and agree upon what's called a controlling idea — which is a one-sentence, concise vision of the ideal of the app or game. Here's an example for an app:

Beginning a project with a controlling idea is a technique the author learned while at Fisher-Price during a Masterclass seminar led by Pixar Story Artist Matthew Luhn. It drives the entire creative cycle of each of Pixar's amazing cinematic successes. What he conveyed was that for each project, the teams at Pixar buy into the controlling idea so that whenever an issue of “should we add this?” or “does this fit?” or even “in general, should we do this?” comes up, the team refers back to the controlling idea and typically finds the answer.

That's a powerful thing. While providing focus and direction throughout development, one simple sentence can prevent many of the creative conundrums that are so common.

So, what constitutes a good controlling idea? For the idea itself, you'll want to include simple, specific ways to subjectively look at the concept. In the previous example, several subjectively measurable terms were used. For example, the phrase “simplifies social networking” was used to imply that social networking can be complex and could be more manageable. How? That's how you get your features! It could mean other things, too, but those would (and should) be part of a more robust initial features list.

Let's keep going. Another subjective term used was “core functionality.” So, what exactly is that? That's what you want team members (in particular, the Designer) to reflect on, extract, and then highlight when creating features. It is specific enough to mean something definite for each team member. For example, Facebook's core functionality could be reading updates about friends. Or, it could be posting to your own wall. But, objectively, you might all see “playing flash games” as not a part of Facebook's core functionality, because that can be done on most any platform.

The phrase “minimum fuss” may mean “with fewer clicks” to some, or “accomplished in a fast manner” to others. Both interpretations are correct. Finally, “maximum efficiency” may mean accomplishing more with less, in whatever manner that can be done (maybe fewer menu layers and more icons on a single screen, for example).

The reason to be subjective rather than objective is that each person will have his or her own ideas as to how far each of these terms goes. But on the whole, each person should have his or her own intuitive “clue” about what is needed when a particular issue arises. On the whole, this can lead to better innovation.

This is not to say that each team member should take what he or she wants from the controlling idea and run with it in his or her own way. Rather, the overriding theme is to use the controlling idea when considering whether features stay or go.

Designers can use the controlling idea to help with assigning features. Artists can use it as a general direction for creating simplistic, efficient icons. Audio engineers can use it for not getting too dramatic with special effects — simplicity and efficiency are key. Programmers can use it to maximize menu-driven responsiveness.

Just to round out this discussion, consider what actually makes a bad controlling idea. Following is an example:

Ouch! That was even hard to put a period on. It's a lofty enough goal, but for providing boundaries, direction, or answering any sort of creative questions or issues that arise, it is just plain generic and unhelpful.

In Chapter 9, there are further tips on how to create what they call a definition statement, so when you're ready for this step, be sure to reference that as well in the “Value-Added Benefits” section.

By now you should have a concrete handle on how to create a controlling idea. It is time to discuss the overall method you'll use for development and get agile.