RWDevCon 2016 Inspiration Talk – The Power of Small by Cesare Rocchi

Note from Ray: At our recent RWDevCon tutorial conference, in addition to hands-on tutorials, we also had a number of “inspiration talks” – non-technical talks with the goal of giving you a new idea, some battle-won advice, and leaving you excited and energized.

We recorded these talks so that you can enjoy them, even if you didn’t get to attend the conference. Here’s our next talk – The Power of Small by Cesare Rocchi – I hope you enjoy!

Transcript

Grow, grow, grow!

We are surrounded by podcasts, conferences, books, blog posts, all forcing us to grow. Grow our user base, grow the number of downloads of our apps, grow our mailing lists. Always grow!

This is probably propelled by the Silicon Valley movement in which hockey stick growth is a requirement if you want to chase the next round of funding.

We also are used to hearing that size matters.

Even excluding all the nasty interpretations of that, probably you’ll think that the bigger the better. The bigger my team is, the more projects I can take on. The bigger is the market, the bigger is the potential income. I don’t want to even mention the bigger the code base…

It’s all true. Grow, grow, it’s all true. Probably. But is it worth it? Have you ever asked yourself is it worth it to chase something bigger? Do I want to give up the power of small?

Well, in the 70’s IBM was the king – I’d say the emperor of computers. Then out of the blue, two dudes in a garage started small – and you know the rest of the story.

Today I’m going to talk about the power of small. I’m going to show you some example of the advantages of working in a small market with a small team and exploiting the advantages of a small launch.

The Power of Small

Let’s start with the advantages of a small market or niche.

Note it’s pronounced niche, not nitch, because it’s French.

1. First of all, big companies do not usually care about small markets because there’s not a lot of money to be made there.
2. Advertisements usually in niche markets are way cheaper and more cost effective.
3. The third part is there are fewer competitors, so it’s much easier for you to stand out.
4. The fourth point, probably the most important, is that probably you’ll end up talking to the real customers, experiencing the real problem that your app or product or service is trying to solve, as opposed for example to the enterprise in which you usually talk to the CTO or the marketing manager that represent the people having the real problem.

Here’s a quick example of a small successful market:

This is Soda Pop Stop. John Nese and his family have been running this business in LA for a long time. They started as a grocery store and now they have a website that sells and ships sodas worldwide. Probably you’ve never heard of this company. We all know that the sodas market is dominated by huge companies that I’m not even going to mention.

But Johnny’s family has been able to carve out a small niche in which people prefer something alternative, I’d say unique, like for example the Werewolf Howling Ginger Beer or the Pumpkin Spice Tonic, which you’ve probably never heard of. That’s fine. Because that’s a nitch or niche?

Audience replies: Niche.

Great. Johnny’s family have been able to run this company for 100 years. Are you seeing the power of small already?

Advantage 1: Moving Faster

Let’s talk about the advantages of a small team. You can move faster.

Let me tell you a quick story. I joined a startup a few years ago. I was the only mobile developer, front end developer, and the other developers took care of the back end. We used Git but honestly we could have used a shared Dropbox folder because we never had a merge issue, our changes never overlapped, and after years that we both spent in the enterprise and convoluted processes we felt wild and young and free.

Really, I was committing code to the master branch and I felt like this when I did it.

But things changed. The company grew. We had to put in place formal process and documents and agreeing on a time slot for a meeting took longer than the meeting itself.

I could not commit to the master branch anymore unfortunately. You know the drill. You had to branch out, do your thing, run the tests, code review and then merge, and then Q&A, and then staging, and then production.

Don’t get me wrong. I mean, having a process is a great thing, because you have fewer chances to screw up. But it also can enlarge the distance between you building the product and the people using the product.

Advantage 2: Easier Decision Making

Now a small team is a competitive advantage so make the most of it. In a small team for example making decisions is much easier.

This is a story that Luke Parham, an iOS team member at raywenderlich.com, told me. He worked at a company. They had an app that allowed to consult used car reports. So instead of going to the dealer you just browse cars in the app.

They had a back end in Java. It was in Struts framework. (I can’t believe I mentioned both Java and Struts at a Mac and iOS friendly conference!)

Now if you look in the dictionary for the definition of “long”, there are a few examples there. One of them is the discussion that you can spark when you ask a bunch of developers, “Should I use vi or Emacs?”

Still in the dictionary, if you look up the definition of endless, one of the examples says, “The discussion that you can spark when somebody in a room full of developer says, ‘We should use a more modern framework for our back end.’”

Now at Luke’s company there were 7 people, 7 developers. It’s an odd number. It should be easy to come up with a majority. 2 wanted to go with Rails, 2 with Django, 1 with node JS, 1 didn’t care, the other one wanted to stick with the old framework. You can image which kind of discussions they had.

At some point somebody started building prototypes trying to show the advantages of a framework over the other. As it happens usually the meeting started with 7 people and after 2 months 20 people were attending the meeting and contributing and discussing and essentially wasting time.

Guess what? In the end they decided to stick to the old framework.

Now who here heard or lived a similar story? I see somebody can relate to this. This is what happens in a big, big team unfortunately.