Do we need another book on communicating?

supercommunicator

Join 28,000 others and follow Sean Hull on twitter @hullsean.

I had to ask the question. There are so many books on communicating & presenting affectively, it begs the question, what can this book do that others haven’t?

While it’s a fair question, I don’t necessarily think it stands with peers. That said it’s a new book, with a new tone, preaching many of the best advice and doing it with a flair. If you’ve read a ton of communication books, you may not find something new, but if the topic is one you’re just digging into, Pietrucha is a great place to start.

1. Jobs vs Gates – inspired presentations

If you’ve ever seen these two companies CEO’s do new product demos, you’ll immediately get it. You don’t have to be an apple fanboy to appreciate how Jobs presents without buzzwords, and cuts to the heart of our hearts.

That means don’t get mired in jargon, speak to our passions, and be your own ambassador.

Also: Do managers underestimate operational costs?

2. Lead with a story & a question

In a recent discussion with a prospect I was asked about one experience that stood out over the years of consulting.

One popped into my head of a dot-com startup in the late 90’s. The company was trying to close an acquisition deal, but the web application was sick & feverish. My first few days involved conversations with lead engineers, DBA & operations team members. As I turn over more stones, I found a key component, the database, misconfigured. I sifted through configurations, and found the setup lacking. The server was using only 5% of memory. Some of the settings were even still at their default. Changing the right ones allowed the machine to flex it’s muscles like a marathon runner taken off a starvation diet. Things improved very quickly, and the site returned to a snappy responsive self.

The CEO beamed with approval, and just a few weeks later the firm was purchased for over 80 million dollars. Not bad work if you can get it. :)

Read: Which tech do startups use most?

3. Drop the vernacular & speak broadly

After recently doing some writing for muckrack on how to reach pitch journalists and then at Infoworld getting started with Amazon EC2. I’ve learned a ton. Having a professional editor explain what they want really puts things in perspective.

Editors will start by talking about their audience. If you’re a blogger, do you know who your audience is, and what they really get from your site? There may be many answers. Once you get your audience, how can you speak to all of them? In my case, I have readers who are programmers & devops, then I have CEO’s & VCs. But it doesn’t stop there. What about recruiters, and hiring managers? How about random internet searchers, and students?

All of these folks can get something from my site, and using broad language allows everyone to be within reach. Don’t sacrifice depth, but use language and stories to make your point.

Check this: 5 ways startups misstep on scalability

4. Analogies that resonate

I attend a lot of mini conferences, meetups, drinkups & social events in nyc. I find it’s one of the keys to success in consulting.

In an endless sea of conversations, you will find yourself talking about what your day-to-day business is all about. In my early years in nyc, these conversations would consist of technically correct descriptions, followed by glazed eyes, and a quick change of subject. After this happens often enough you start to wonder, how can I share such a technical description to a broader audience?

Truth is it’s only technical because you know so much about it. If I stand back I might say I’m “a sort of specialized surgeon for the internet”, or “a traffic cop of sorts, for the information highway we all share”, or better yet “a plumber, that you call when your pipes are backed up and your customers are screaming”.

Whichever analogy I use, I see eyes light up, and a look of understanding. “Oh I can see how that would be an important specialization”. Indeed.

The right analogy makes all the difference!

Related: Are startup CEO’s hiding their scalability problems?

5. Put your words on the chopping block

If you haven’t already done so, start chopping. Sentences & paragraphs all benefit from shortening & edit. Distill your big ideas in summary and let the story lend the detail. Your audience will pay closer attention, and see the big picture you are trying to share.

The guys at 37 signals do this eloquently in RE:Work .

Read this: Is Amazon RDS hard to manage?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Which tech do startups use most?

MySQL on Amazon Cloud AWS

Leo Polovets of Susa Ventures publishes an excellent blog called Coding VC. There you can find some excellent posts, such as pitches by analogy, and an algorithm for seed round valuations and analyzing product hunt data.

He recently wrote a blog post about a topic near and dear to my heart, Which Technologies do Startups Use. It’s worth a look.

One thing to keep in mind looking over the data, is that these are AngelList startups. So that’s not a cross section of all startups, nor does it cover more mature companies either.

In my experience startups can get it right by starting fresh, evaluating the spectrum of new technologies out there, balancing sheer solution power with a bit of prudence and long term thinking.

I like to ask these questions:

o Which technologies are fast & high performance?
o Which technologies have a big, vibrant & robust community?
o Which technologies can I find plenty of engineers to support?
o Which technologies have low operational overhead?
o Which technologies have low development overhead?

1. Database: MySQL

MySQL holds a slight lead according to the AngelList data. In my experience its not overly complex to setup and there are some experienced DBAs out there. That said database expertise can still be hard to find .

We hear a lot about MongoDB these days, and it is surely growing in popularity. Although it doesn’t support joins and arbitrary slicing and dicing of data, it is a very powerful database engine. If your application needs more straightforward data access, it can bring you amazing speed improvements.

Postgres is a close third. It’s a very sophisticated database engine. Although it may have a smaller community than MySQL, overall it’s a more full featured database. I’d have no reservations recommending it.

Also: Top MySQL DBA Interview questions

2. Hosting: Amazon

Amazon Web Services is obviously the giant in the room. They’re big, they’re cheap, they’re nimble. You have a lot of options for server types, they’ve fixed many of the problems around disk I/O and so forth. Although you may still experience latency around multi-tenant related problems, you’ll benefit from a truly global reach, and huge cost savings from the volume of customers they support.

Heroku is included although they’re a different type of service. In some sense their offering is one part operations team & one part automation. Yes ultimately you are getting hosting & virtualization, but some things are tied down. Amazon RDS provides some parallels here. I wrote Is Amazon RDS hard to manage?. Long term you’re likely going to switch to an AWS, Joyent or Rackspace for real scale.

I was surprised to see Azure on the list at all here, as I rarely see startups build on microsoft technologies. It may work for the desktop & office, but it’s not the right choice for the datacenter.

Read: Are generalists better at scaling the web?

3. Languages: Javascript

Javascript & Node.js are clearly very popular. They are also highly scalable.

In my experience I see a lot of PHP & of course Ruby too. Java although there is a lot out there, can tend to be a bear as a web dev language, and provide some additional complication, weight and overhead.

Related: Is Hunter Walk right about operations & startups?

4. Search: Elastic Search

I like that they broke apart search technology as a separate category. It is a key component of most web applications, and I do see a lot of Elastic Search & Solr.

That said I think this may be a bit skewed. I think by far the number one solution would be NO SPECIFIC SEARCH technology. That’s right, many times devs choose a database centric approach, like FULLTEXT or others that perform painfully bad.

If this is you, consider these search solutions. They will bring you huge performance gains.

Check this: Are SQL Databases Dead?

5. Automation: Chef

As with search above, I’d argue there is a far more prevalent trend, that is #1 to use none of these automation technologies.

Although I do think chef, docker & puppet can bring you real benefits, it’s a matter of having them in the right hands. Do you have an operations team that is comfortable with using them? When they leave in a years time, will your new devops also know the technology you’re using? Can you find a good balance between automation & manual configuration, and document accordingly?

Read: Why are database & operations experts so hard to find?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Is Hunter Walk right about operations & startups?

The.Rohit - Flickr
The.Rohit – Flickr

Join 26,000 others and follow Sean Hull on twitter @hullsean.

Hunter Walk blogged recently about the importance of building great operations teams. And while he was speaking primarily about business operations, the startup technical operations teams are equally difficult to get right.

1. performance & scalability

As your grows like Birchbox, your customer growth curve may begin to look like a hockey stick. That’s a good problem to have. Will your web application be able to keep up with the onslaught of traffic those customers bring?

Getting performance and scalability just right, will mean fewer site crashes during those key moments when all eyes are on your site.

Also: Is top operations talent hard to find?

2. Operations is key to architecture

Developers will always have strong opinions on architecture. However they may be heavily influenced by their own mandate, features, deliverability & deadlines. So it’s no surprise that they may sometimes choose to build on ORM’s, the middleware brought to you by Hibernate, Cake PHP, Active Record & the like.

And while these technologies seem a necessity in todays modern architectures, they play havoc with your long term scalability. Strong technical operations teams mean a better vision in this area. Heading off your reliance on these technologies will mean managing technical debt before it takes down your country.

Read: Are generalists better at scaling the web?

3. Operations informs strategy

Did you build in those operational switches to turn off the heaviest code, when your site gets overloaded? Operations strategy can help you see these problems on the horizon before they overwhelm you.

Have you considered building a browse only mode for your site? If you’ve ever visited Facebook or Yelp after hours you may have been greeted with the message “We can’t save your comments. Please try again later”. A small innocuous message to end users doesn’t disrupt their enjoyment of the site terribly. But from an technical operations perspective it’s huge. It means teams can perform backups, upgrades and maintenance without interrupting day-to-day activity on the site.

Related: Is scalability a big business?

4. Operations means resilience

We only learn real disaster recovery lessons from storms like Sandy. That’s because resilience highlighted best when it is a real & urgent need.

In technical operations, getting backups right & testing your recovery plan all form key steps in your path to excellence. Get them right before you need them, and ensure repeatability.

Read: Is high availability a real possibility?

5. Operations means technical strength

At the end of the day, getting technical operations right, means you can move from strength to strength. It means building on a solid foundation the likes of Google, Facebook, Foursquare & Etsy. It means you can evolve & grow with your customers, and meet their needs confidently.

Check out: Do startup CEO’s underestimate operational costs?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

5 ways startups misstep on scalability

Russian_Dolls

Join 27,000 others and follow Sean Hull on twitter @hullsean.

1. Ignoring the database

Yes, your internet site sits on top of a database. Have you forgotten to take care of it?

Like a garden, it must be watered & tended. And a gardener will always scold you for leaving plants to wither. I guess as a database administrator by background, I’ve seen a lot of this. But truth be told it is in large part the cause of slowness.

Queries

Are you writing them? If you’re using an ORM middleware, you may be leaving this heavy lifting to a library. These are inefficient. Avoid the Vietnam of computer science.

Testing

Now that you’re writing SQL, are you testing & tuning each one? Think of it like turning apps off on your phone that you’re not using. Saves memory, battery, and general headache.

Monitoring

Now that you’ve gotten in the habit of caring for your database, keep at it. Monitor its health regularly. NewRelic as a service or Cacti, Ganglia or Collectd if you’d like to roll your own. Real data can reap real benefits.

Read: Are SQL Databases Dead

2. Shortage of caching

You’ve heard it before, we’ll say it again, make sure you’re caching. But where?

Content Network
Amazon has it’s CloudFront, Rackspace uses Akamai. There are many choices but the results are the same. Static assets such as html & css files, images & video content all part all part of the page you are serving, get dished out closer to your users. It’s like only asking them to go to a corner deli for a soda, rather than the closest supermarket.

Webserver tier

There are many things you can do to cache at the webserver. In particular you can configure to tell browsers to cache objects. One example is Cache-Control. That means longer time-to-live, so objects don’t expire by default. You can always expire them manually. There are also ways to compress objects as well. See How to cache websites & boost speed.

Between webserver & database

Are you using Memcache or redis? Caching here can reduce load on your database by as much as 10x. That’s like buying you 10x free servers, or one large one that costs 10x the price!

Most languages such as PHP provide libraries to interact with memcache. Whenever you make a call out to your database, first check memcache. If you find your key, fetch the value & done. Otherwise grab the answer from the database, and pop it into memcache.

At the database

Databases of all kinds, be they postgres, Oracle, or MySQL have a query cache. Be sure you’ve enabled & tuned yours. Also check that your buffer cache is sizeable enough to fit most frequently hit data. A hit ratio may provide you a cheap guestimate on this.

Related: Why a four letter word divides dev and ops

3. Missing metrics collection

In a recent article Why Scalability is big business I talked about collecting metrics. These are invaluable.

If you’re a home owner or renting, and want to know what you spent on energy in the past year, what do you do? You look at your heating bills for the winter months. Similarly, collecting real data on all your servers, like with cacti, or a service like NewRelic allows you to do the same thing with your servers & infrastructure.

Real hindsight, and real visibility helps everyone from operations teams, to business units evaluating past problems.

Also: Why a killer title can make or break your content efforts

4. Not building feature flags

Tractor trailers use two tires on every axil. If one fails, you are still on the road. Planes use redundant engines. Having switches built into your application to turn off non-essential features may seem abstract when your deadlines for features are looming.

But operational switches for your devops team should be seen as good foundation, and solid bedrock to build on. It means you can do the maintenance that you will need to do, and do it without interrupting customers. It also means when your site gets hammered, and we hope that day will come, you can adjust the dials, and not go down.

Related: Is Amazon RDS Difficult to Manage

5. Building on a single database

Various NoSQL databases like MongoDB, Cassandra & Hbase are distributed out of the box. Keep in mind though they make various tradeoffs to achieve this.

Meanwhile the vast majority of web applications are still built on reliable relational databases. But they don’t scale seamlessly. Build a read-only mode into your application and you’ll thank yourself for years to come. This means you can browse, even while the master database is offline. What’s more it means you can scale more easily.

Avoid solutions that try to scale writes across multiple servers. Partitioning aka sharding is terribly complex to get right, both in planning & layout. Lets not forget how do we piece together a puzzle of 8 shards with 8 pieces to a backup. Recipe for trouble. There are some new cluster options for MySQL, such as Galera. Oracle has it’s own take. But in the end you’ll do better to get a bigger box for your central datastore and keep it central.

Related: How to Deploy on Amazon with Vagrant

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters