Recap: November Dinner with Rob Drimmie

This month we were back at the Communitech Hub, which was only fitting since our speaker is one of their staff. Also big thanks to Rob and Communitech for sponsoring the Dinner!

We settled in to nosh pizza, sneak Hallowe’en candy, and listen to Rob Drimmie tell us about who he is, what he does, what his team does, and some lessons learned from lots and lots of hiring and building teams.

Rob is Communitech Apps Factory‘s Development Manager, and one of two full-time staff. He describes his role as “grout”, filling in the spaces and needs of his regularly changing team, their clients, and Communitech.

The origins of Communitech and Apps Factory

Rob also gave us a bit of a primer on Communitech’s origins and history, which date back to 1997. Waterloo Region’s tech industry was much different then, and a lot smaller, particularly companies that would become global industry leaders like RIM and OpenText.

Entrepreneurs were kind of on their own if they had problems, questions, or just wanted to chat with others with similar challenges or experiences. And in classic DIY fashion, they started getting together regularly to have dinner, drinks, and network. Communitech’s roots can be found there.

Communitech’s Peer2Peer Network grew out of that as well, and now facilitates more than two dozen special-interest groups.

Many of the Region’s tech entrepreneurs at that time were technical people, with engineering and computer science backgrounds (much like today). But as critical as tech chops are, building a company requires many more skills. And these people had no good way to connect with business or marketing resources, among others. On the flip side, some established businesspeople knew how to building companies, sell, market, and otherwise be entrepreneurs, but they weren’t technical, and had no good way of connecting with technical resources.

Once it was brought to life, the Communitech folks made a priority of strengthening ties to the local schools, especially University of Waterloo, responsible for much of the area’s technical talent and research. This relationship has continued to grow over the years, and Apps Factory has hired most of its co-ops from the university.

Apps Factory was founded in the spring of 2011, when Rob was brought on board. The goal of the organization was to provide technical resources to those who didn’t have them in-house. For example, you have a business and a great idea for an app that will help you organize information, connect with your customers, or otherwise improve your work life, but you don’t have developers on hand or know where to start fleshing the idea out.

How Apps Factory works

Apps Factory initially solicited ideas that it then chose from, though that proved to be an unsuccessful model. There were issues with time frame (between the selection of the idea and when the team could build it). It encouraged desperate business people, which led to poor decision-making and stress from people who needed the work yesterday. And eight months between selection and development was just too long for startups, whose businesses could grow and change in many ways in that amount of time… or they could cease to exist all together.

The team now takes client applications and works on internal projects as well. They have a much better idea of realistic clients, projects, and timelines. Initially Rob and co. didn’t know if it would work to have co-ops doing the bulk of the work, but as it turns out it’s been a very successful decision.

The team focuses on prototypes, but does have relationships in place to broker referrals for clients to connect with developers to complete the development of their apps. The process begins with a first meeting with the client, and ends with a basic product. The co-ops are expected to own the relationships and the work end to end.

What to do if you have an idea for an app

Rob then shared his recommendations for what to do if you have an idea for an app.

Write it down. Write down the ideas anywhere. It will help you remember them, it makes you think more about what it is you really want, and it enables you to communicate the idea to others.

Share it. Tell people about your idea. Show them your napkin sketch. Discuss what they interpret from your explanation. The more people who know about your idea, the more feedback, validation, and diverse perspectives you’ll have access to. Don’t worry too much about IP. It is highly unlikely that anyone will try to steal your idea. Invoke a FriendDA if it makes you feel better.

Collect info. You will not get your idea perfect right out of your head. You will forget obvious parts, decide other parts are stupid, and have amazing secondary ideas. You will have other people tell you that this makes no sense, and that would be really cool if… Get corrections on your assumptions, get advice, but also know when it’s prudent to take the advice and when to ignore it. Because plenty of the advice will be bad.

Edit the idea. Take out the stuff you’ve realized isn’t important. Add the stuff that is. Focus on the core – what truly represents your idea. Add some of the good advice you got. Focus on what you’ll need for a minimum viable product (MVP), not the Super Ultimate Mega App Experience you may eventually want to get to. Rome wasn’t built in a day and neither are apps.

How an idea becomes an app (or at least a prototype)

And now the fun starts! Rob did give the disclaimer that all teams are different, but this is how his team works and what works for them.

The iteration begins with napkin drawings, essentially (or, possibly, literally). Low-fidelity wireframes follow, using tools like Balsamiq Mockups. After that comes high-fidelity wireframes, using tools like Photoshop. These can often be mistaken for real apps, since they at least look like real apps.

Wireframes, however, are like a house staged to be sold. Technically, it’s real, but “real” houses don’t look that nice. It gives you a certain idea and impression, but long-term it’s not realistic. The reality is messier and less fancy. (But in the end actually works!)

Once the app is fleshed out, it will also hopefully look better than the wireframe and have more features. Wireframes also change over the development process. A lot. (In some good ways, in some bad ways…)

After wireframing comes prototyping. Prototypes are not apps, either, though they are great for communicating what the app will be. As a development progression, prototypes are also much more expensive than wireframes in terms of time and resources, just as actual app development is much more expensive than prototyping. This is something clients need to balance when getting apps built.

Rob began hiring a student dedicated to user experience (UX) right from the beginning, so there is always someone whose work centres around design on the team. The UX person spearheads initial client meetings. Clients usually have plenty of documentation and whatnot, but the Apps Factory team likes to start pretty close to scratch.

First there is a one-hour introductory meeting. Rob kicks this off, but doesn’t usually stay. Apps Factory staff are expected to be very independent and own these projects and relationships. Rob has found it’s the best way to build skills, experience, and confidence. The team and clients are left to brainstorm and get an idea of what the desired app should be.

Once a wireframe is built, the team meets with the client again to go over it, line by line, feature by feature. They expect lots to be wrong. It’s just natural. Getting ideas out of our brains and into the real world is hard. Very likely 60% of the content of the original wireframe will be replaced.

One interesting thing that Rob noted is that lots of people will let small errors go by if they are not integrated into the development process. But if you put their idea down right in front of them and say “What about this?” and make them compare the wireframe to the contents of their brain and their expectations, they engage a lot more. They express what’s wrong, and once it’s okay for parts to be wrong, they think really deeply about their app, get more comfortable working with the team, and get them knowledgeable about explaining their app to others.

From this second meeting comes the second draft of the wireframe. If additional ideas or clarity are required from the client, the UX person can work to prompt ideas and catalyze more communication. This helps speed up the process of getting to the goal: a solid prototype.

At this point development on a prototype begins, and Rob talked about dev process and relationships. He noted that dev skill and experience are critical, but at least as important is the relationship with the client. If you’re working with a dev you hate, you’re not going to want to talk to them or go over ideas or try and correct incorrect assumptions. You’re going to resent every penny you spend, too.

Rob noted the value of trying something called the Three Developer Trial for outsourced work. Test potential relationships with devs by trying out several. Pick a small part of your overall project and hire three separate devs to complete it. Typically, one will fail to produce anything and disappear with your money. One will produce work, but it will be crap. And one will be a great dev with whom you have good communication and some rapport. This is a low-cost way to test a potentially much larger investment.

Rob noted that they recommend showing the wireframes or prototypes to an early potential customer. Do they get how it’s supposed to work? Does it solve a problem they have? What suggestions do they have. Would they buy it? This helps determine if the app has real-world viability.

Much like how much of the wireframe will get thrown out, so will the first prototype (and first major development work). Possibly all of it. It’s good to plan for this right from the beginning so no one’s upset or worried about wasting time on the project. Because of this flux, that’s why minimum viable product focus is important. Focus on a small app, with a few key features. It’s important to do the core things well, and then add on later.

It’s important to build enough of the prototype to get lots of feedback. The appearance, the user experience, the functions, the features. Ask as broad a group of people as you can to poke at it. From there development can continue and be refined until a solid prototype is achieved, and it can be handed over to a dev or team to be fully built out.

Building the Apps Factory teams

This is the point where Apps Factory’s work usually ends, and what they find to be the best use of them as resources for clients. At this point Rob switched gears to talk about the team itself, how it’s composed, and what he’s learned from hiring and mentoring co-ops, building teams, and building good employees and developers.

The preferred team format at Apps Factory is: manager, senior dev(s), co-ops (junior devs/UX). Because of the co-op hiring model, the team has high and regular turnover. Rob hires co-ops well in advance of when they will actually start, and usually hires early stage co-ops (i.e. younger ones who haven’t had a lot of terms yet).

Initially Rob tried to hire based on his highest aspirations. He went with students who knocked his socks off, and who had a fair bit of experience… and didn’t land a single one. As he learned, this is not uncommon, and over time he’s learned a lot of lessons about the process.

One of his biggest mistakes was not telling prospective co-ops what Communitech and Apps Factory could do for them, but rather what it did and had done for him. On top of that, Rob also had a much greater familiar with Communitech in general than the students did.

Rob forgot to focus on what challenges the co-ops would tackle, what interesting problems they would solve and cool things they could build. He also wasn’t thinking about the fact that he couldn’t offer them full-time work post-graduation, which is at the forefront of the minds of late-stage co-ops who are approaching graduating and thinking about where they want to go next.

Apps Factory was also an unknown. Who were they? What did they do? These were students who’d done terms at places like Google and Facebook, so right away Apps Factory was only likely to appeal to types who preferred smaller teams and larger individual contributions. And who didn’t care as much about “sexy”.

For these reasons Rob switched gears to hiring more early-stage co-ops, who didn’t have many pre-conceived notions yet, and were open to different kinds of challenges. Conveniently, first- or early-term co-op students are also cheap, relatively speaking. But at the same time, that doesn’t mean they’re not great talent, just somewhat unpolished.

Because Rob only has co-ops for a term, he needs people who can learn and ramp up quickly. One of his biggest hiring strategies is to hire the curious. Rob clarified that he meant both curious in terms of how they’re minds work, and their personalities. Curiosity tends to reveal a lot of valuable traits.

Rob discards any resumes that come in on the boilerplate template. (Co-ops get a set they can choose from.) He also discards any students who have only taken the same standard courses (or required ones) as everyone else (i.e. required for their degree). That first resume pass cuts about 50% of resumes.

The second round of resume analysis is deeper, and looks hard at personal projects. These are important, and Rob wants to know that these folks have played around with web development (and mobile). After all, that is what they’ll be doing. Good to know they have some interest in it…

With the first round of interviews there’s a basic programming test for technical ability. Not everyone gets it right. Now this could be because of nerves or because the person is a bad programmer, or for a number of other reasons. Getting people past the nerves to really interview them is important, because until you do you don’t see the real person, which is critical to determining team fit.

One of Rob’s best tricks for getting people past nerves and to open up is to ask about their personal projects. People who engage, show what they’ve been working on, get excited, and geek out do well. It shows off the aforementioned curiosity, and reveals the person’s true personality. (And that they’re not afraid to put something personal out there.)

One thing Rob avoids like the plague are people who self-identify as rock stars/ninjas/gurus and the like. He’s found those are negative indicators for personality and team fit. They tend to have a lot of ego and don’t integrate well, and for Rob’s team, fast and cohesive integration is key.

After hiring his cohort, for the first week the team sets up their work environments, starts getting to know each other, and works on a shared project. That project ships at the end of week one. Being thrown together to produce something fairly big bonds the team very quickly, and also orients them toward teamwork right from day one.

Early stage co-ops have the least experience, are unlikely to know each other, and often aren’t yet familiar with the tools they’ll be using. Everyone starts from a level playing field. (Hiring co-ops with a lot of experience and/or domain knowledge in one area generally means they’re weaker in others.) In addition to learning the tools and projects, they learn about each other, become friends, and form a cohesive team. This cohesion goes a long way toward building trust, confidence, and a group-oriented work ethic.

Client work starts week two, with the various meetings and processes discussed earlier. Builds ship every Thursday, so people get used to having a solid schedule to work to. Regular shipping also builds confidence in the team, as they learn they have what it takes to build good stuff and get it out the door, week after week.

Additional activities to bond the group include team lunches, which are good for general bonding, especially discussions beyond work activities. The team also uses Campfire for casual communications. Developers tend to go dark for periods of time while they’re in the zone, and also are often more comfortable with text as a medium, so tools like that work well. The team keeps each other in the loop, minimizes distraction, and engages on their own terms.

Online conversations often do spill over into the “real world” as well, which can then bring even more of the team into them. Rob also makes sure he and the senior devs participate in these conversations as well. Both as a strategy to make themselves part of the team, and to demonstrate that they are real people in terms of development as well. They forget things, make mistakes, make fun of each other, etc.

The team does a daily 9:30am-ish scrum-based standup meeting. Everyone shares: what they’re working on, what’s blocking them, etc. Commentary and respectful criticism are important for everyone on the team, and these meetings are good for getting that communication flowing. Because the timelines are tight and the team small, openness and honesty about the work and issues is important to prevent major issues.

Rob knows that the team has gelled when they start asking each other questions without reservations, or openly asking for help when they get stuck. This is also a good indicator that the co-ops are taking personal responsibility for the success of their work, and it build confidence to know other people have questions and get stuck, too, but there are always others there to help you out.

Rob does talk to the co-ops somewhat about strategies for identifying good companies and cultures to work for, but ultimately the best teacher is going through it. (Or, if they’re lucky, believing their friends’ horror stories.) Fortunately, students have pretty solid networks they can learn from.

In terms of what specialties the students come from, Rob said he hires a lot of Systems Design engineering students, especially for the UX work. He does occasionally re-hire co-ops for a second term, but that’s almost always under very specific circumstances. Mostly he encourages students to try out a wide variety of roles: big companies and startups, general and specific, internal-facing and external. This builds breadth into their skill set and helps them better determine what fits for them.

And with that, Rob’s presentation was completed. We had a few more specific questions in Q&A, but we think his talk about pretty exhaustive, and included some excellent real-world perspectives and common sense info about building both apps and teams. Thanks again, Rob!

What’s coming next?

Our December Dinner has been announced, and will be Detective Sharon Lloyd from the Forensic Identification Unit of Waterloo Regional Police Service on December 10th. Tickets are already on sale, and are already about half sold out, so don’t wait! (Oh, and Taco Farm will be catering this one, so it will be extra delish!)