Category Archives: All

Why Healthcare.gov desperately needs techops

healthcare.gov logo

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

1. Tech-what? A quick education

Techops is operational excellence. It’s the handoff when code is complete. These are the folks who are up at 2am when a website is down. They manage servers, keep the pipes clean, and the hackers out. They also help plan for capacity needs, and may help with load testing too.

If you’re new to technology, imagine a movie set. Story writers (programmers) have already done their part. The producers (venture capital folks) have financed the project. The director (architect) is there trying to put the vision together. But the folks who manage everything on set, from sound guys, camera guys, lighting people, and all the coordination, this is operations. In web application deployments it is devops, sysops or techops.

Also: Why the Twitter IPO is afraid of scalability

2. In contrast with Obama election campaign

Notice how phenomenally well Obama for America project was run. Like a finely tuned machine. Harper Reed and team pulled off one of the most data backed election campaigns in history.

That project used AWS cloud technologies to the fullest, from devops tools like Puppet and Asgard, collaboration tools like Campfire & Github, and superb monitoring & instrumentation tools NewRelic and Chartbeat.

Clearly Obama knows how to run an election. Something is drastically different with the healthcare.gov project. Too many cooks in the kitchen, perhaps?

Read: Why your startup needs professional techops

3. A failure in capacity planning

Many popular news outlets covered the outage, but most pointed to “bugs”, which caused the outage. But when a site dies under load, while it’s working in test & Q/A, that’s a failure of load testing, and capacity planning.

I would wager a good bet, database tuning would definitely help as it’s the most common and prevalent cause of

Read this: What four letter word divides dev and ops?

4. More testing & more Agility needed

Modern software projects take advantage of continuous integration & agile methods. That is they make small incremental changes. Developers build unit tests, and the code is always in a working state. There is no multi-month dev cycle, where your current software is in doubt.

Reports indicate that the healthcare.gov software was being designed & developed using this old and most agree inferior method of software development, the waterfall method. New Yorker criticises it in Don’t go chasing waterfalls.

Read: Why devops talent is in short supply

5. Caching is desperately needed

All high performance, high scale websites need to take advantage of various types of caching as I’ve discussed in detail before. From browser caching, to page & object caching on the server side.

Hayden James investigated in depth, and found healthcare.gov severely lacking. Again this is a huge failure in techops, sysops or devops. It’s not a bug, and not something the developers are responsible to deliver.

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

Why Oracle won’t kill MySQL

oracle mysql database

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

1. MySQL does not compete with Oracle

It’s a myth that MySQL somehow poses a threat to Oracle. Oracle’s customers tend to be large enterprises running apps like e-business suite. These are certified to run on Oracle, and further they sit close to finance.

MySQL tends to be a choice of scrappy but nimble startups for their web-facing applications. They want to deploy in the cloud, and don’t want to deal with licenses. Plus they have the techops chops to handle the bushwacking of open source.

Related: Why I wrote the book on Oracle & Open Source

2. Oracle bought Sun for the hardware business

Remember when Oracle acquired Sun? A lot of folks assumed Larry was after MySQL. Grab it & slowly smother it. But actually it was more frosting on the cake. Larry had for years expressed interest in cubes and clusters, and building an Oracle appliance. Whether this ever came to profitable fruition in the form of Exadata remains to be seen. But buying Sun for a song helped him do this.

Also: Why bemoaning AWS performance sounds like Linux detractors circa 1999

3. Larry blows with the wind on open source

He’s money minded, so you’ll see in his decisions that comes first.

In the late 90’s when a customer might spend $100k on Sun and $100k on Oracle licenses, Larry realized porting to Linux and pushing commodity hardware would be a win. So he pushed Linux, and customers could now spend $20k on commodity hardware and $180k on Oracle licenses for them. Imagine the 10million dollar budget if you’re having trouble with the math here.

He also eventually moved the middle tier to Apache for similar reasons. I would argue Oracle corp overall pays lip service to contributing to open source, but they do that to some degree.

Read: Why MySQL dbas are so hard to find

4. MySQL support business is real

What’s more, just as adopting Linux, and then offering their “unbreakable Linux” distro, and pricey support along with it, they’re doing similar things with MySQL. For enterprise customers, and those already comfortable with making the call to Redwood Shores, sales folks will happily direct them support contracts and enterprise add-ons. Naturally.

Read: Why your startup needs real techops

5. There are real viable alternatives to keep balance

And let’s not forget folks, there are already a bunch of forks. There’s the popular and every growing Mariadb which Google has put their muscle behind.

Of course let’s not forget the very popular, very capable, and very bulletproof Percona distribution, along with the Percona toolkit and xtrabackup for real hotbackups.

And for those looking to experiment, there’s Drizzle a work in progress, complete rewrite, and one that’s unfortunately not a drop-in replacement.

Read this: What’s the four letter word dividing dev and ops?

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

Lulzsec, Anonymous and the sorry state of internet security

zalgo text

If you’ve been hiding under a rock for the past few years, you might not have heard of Anonymous, the headline grabbing hacker group that’s famous for attacking citibank, ebay, Sony, the FBI, CIA and the websites of various world governments.

Parmy Olson takes us on a ride, through tales that are riveting, and quite a bit scary for what they reveal about today’s internet, and the false sense of security we all have.

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

Kids these days!

By now you’ve probably heard their names T-flow, Topiary, Sabu, & Kayla. And then there was AVunit, pwnsauce, Sup_g, and Havij. Cool characters, sitting at keyboards all over the world hatching menacing attacks, and seeming more organized than they actually were…

Topiary jumped into the role as spokesman for the group. Listening to this live hack only seems amusing in retrospect, now that the group has been brought down…

Read: Why devops talent is in short supply

For all the subcultures you’ve never heard of…

Today’s internet is rife with fascinating subcultures, many I’d never heard of. Parmy’s book on Anonymous takes us to the door of all these places, and gives us a candid peak at what goes on there. Kids these days are up to no good!

The bizarro Encyclopedia Dramatica is a wikipedia of weirdness. And then there’s Googledorks, a hackers delight of exploits (ways to break into systems online), and hacks.

And let’s not forget 4Chan the online community and forum that hatched Anonymous.

You thought Ascii Art was cool, but have you heard of zalgo text? That’s the text garbling software that created this posts image.

If you’re looking to dig a little deeper, browse over to know your meme, a sort of urban dictionary for internet subcultures.

Don’t forget the 47 rules of the internet. I’m still looking for rules two through thirty three. Does this have something to do with this 33?

Read: How to evaluate an independent consultant expert

With only a very thin blanket to secure us…

If you’re not already a touch paranoid with the risks of online banking, social networks and identity theft you will be after reading this tale.

Anonymous troublemakers were able to send SWAT teams to unsuspecting people’s homes, crowd source personal information, social engineer their way to facts about someone and then dox them publishing all that personal information online.

On the more technical side, many sites are vulnerable to SQL Injection a rather technical sounding method to trick websites into dumping the contents of their databases back to a hacker. There’s even an automated tool called sqlmap to help you with the dirty work.

And then there are the very illegal denial of service attack tools like the ominous sounding low orbit ion cannon. Please don’t try this at home!

Definitely the worst of all offenders are the botnets, swarms of infected computers that can be controlled from a central location, to wreak havoc on users and internet firms alike. Thanks Bill!

As a parting word, take a quick look at this instructional video on using backtrack5, a hacking & security testing tool…

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

The older roots of hacking circa 80’s and 90’s

I remember back in the 80’s when War Games came out. It was a scary premise. With the cold war between the US and the former Soviet Union in full bloom, it felt very real.

The 90’s brought Clifford Stoll hunting a hacker through his computer systems in The Cuckoo’s Egg.

And then along comes Kevin Mitnick, turning his finger up at US agents, and wreaking his own havoc in his wake.

The anonymous story turns more political when they meet the likes of Julian Assange, but even that isn’t new. Remember the Pentagon Papers?

What’s really knew is how the internet has grown, but how computers have not gotten more secure through that period. It has all grown more brittle, with many websites, and personal computers steered by unsuspecting users.

Read: Why high availability is so very hard to deliver

Surprisingly soft landing

One thing that really surprised me in this tale, was the sentences many Anons received. The way the headlines read, this was real all-out warfare on governments and corporations a like. But reading the judgements, it appears judges had a different perspective.

Although there were certainly compromises of personal information, the group really wasn’t responsible for a huge amount of theft & fraud. Sure they took down some websites, but whom does that really harm. It makes great headlines, but the bigger systems behind the scenes are actually more secure than that.

”IRC is just the crap out of everyone’s minds…” – Topiary on words thought-typed in IRC chats

After flipping through to the end, it seems we’ve taken a ride through the internet underground, but not through the criminal underworld. That is out there surely, but it’s not run by this scattered team of recluse misfits.

Related: Why Airbnb didn’t have to fail

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

When fat fingers take down your business

apple sad mac fail

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

Github goes nuclear

I was flipping through reddit last night, and hit this crazy story. strange pushes on GitHub. For those who don’t know, github houses source code. It’s version control for the software world. Lots of projects use it, to keep track of change management.

Jenkins is a continuous integration platform. Someone working on the project accidentally did a force push up to the server. They overwrote not only their own work, but the work of hundreds of other plugins unrelated to his own project.

This is like doing a demolition to put up a new building, and taking down all the buildings on your block and the next. Not very neighborly, to say the list. They’re still at the time of this writing, doing cleanup, and digging through the rubble.

Read: Why DynamoDB can increase availability

How to kill a database

I worked a startup a few years back that had an interesting business model. Users would sit and watch videos, and get paid for their time. Watch the video, note the code, enter the code, earn cash. Somehow the advertisers had found a way to make this work.

The whole infrastructure ran on Amazon EC2 servers, and was managed by Rightscale. Well it was actually managed by an west coast outsourcing shop, whose specialty was managing deployments on Righscale.

The site kept it’s information in a MySQL database. They had various scripts to spinup slaves, remaster, switch roles and so forth. Of course MySQL can be finicky and is prone to throwing surprises your way from time to time.

One time this automation failed in a big way, switching over production customers to a database that took way way way too long to rebuild. As their automation didn’t perform checksums to bulletproof the setup it couldn’t know that all the data wasn’t finished moving!

Customers sure did notice though when the site fell over. Yes this was a failure of automation. But not of the Rightscale platform, but of the outsourcing firm managing the process, checking the pieces and components and ensuring the computer systems did their thing to completion. Huge fail!

Read: Why devops talent is in short supply

Your website will fail

Sites big and small fail. Hopefully these stories illustrate that fact. I’ve said over and over why perfect availability is a pipe dream.

At the end of the day, the difference between the successful sites and the sloppy ones isn’t failure and perfection. It’s *how* they fail, and how they get back up on their feet. What type of planning did they do for disaster recovery like many firms in NYC did before and after Sandy.

Also: Why startups need both devs and ops for scalability

Reducing failure

So instead of thinking about eliminating failure, let’s think about *reducing* it from happening, and when it does, reducing the fallout. One thing you can do is signup for scalable startups where we share tips once a month on the topic. Meanwhile try to put these best practices into play.

1. Test your DR plan by running real life fire drills
2. Use more than one hosting provider, data center or cloud provider
3. Give each op or end user the least privileges they need to do their job
4. Embrace a culture of caution in operations
5. Check, double check and triple check those fat fingers!

Read this: Why a four letter word divides dev and ops

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

What is eventually consistent and will it work for you?

aws dynamodb

In the tech world we’re fond of inventing all sorts of technical terms, that are admittedly kind of confusing.

Join 13,500 others and follow Sean Hull on twitter @hullsean.

I was attending an excellent talk recently called Data at Scale, part of the Database Month series that Eric Benari hosts. In it Mark Uhrmacher presented some phenomenal solutions which worked for flash site ideeli. It allowed them to support their incredible business model, where 15% of traffic would happen in 15 minutes everyday. As he called it a “self-imposed denial of service attack”. Interesting analogy.

What occurred to me though, is that a lot of companies and startups struggle to understand which database solutions will work for them, and what the strengths and weaknesses of each are, and further what tradeoffs they’ll grapple with.

One concept that we hear a lot is “eventually consistent”. Many of the new NoSQL databases achieve their speed & availability this way. But what’s it all about?

Let’s change a smartphone contact

I’m sure you have a smartphone in your pocket, and for demonstration sake I’ll use the iphone configured with iCloud.

Let’s go ahead and dial up your *OWN* contact card. Click “Edit” and go ahead and change something. Let’s change your title to “rock star”. Now click “Done”. We’ll wait a minute. Now go to your desktop and open up Contacts. Scroll through to your contact and verify that the Title field now shows “rock star”.

How does all this happen? When you click the “Done” button, the iphone sends changes up to iCloud. iCloud then lets your laptop know a change has happened and those then sync up.

Now let’s run through the same exercise, but change it in two places. We’ll change the smartphone contact to “Founder” and the desktop Contacts record title to “Consultant”. Wait a little bit and you’ll notice they will both eventually show “Consultant”.

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

How long were laptop & phone out of sync?

As you probably noticed, the iCloud seems to lean in favor of the desktop client. It’s not clear to me what rules it uses here, nor does it seem to be configurable. Nevertheless eventually both the desktop and smartphone with have the same contact card for you. Quite a feat of magic!

Read: Why high availability is so very hard to deliver

Handling collisions

There is only one *YOU* and presumably your digital rolodex reflects that too. You have one and only one contact card. Or do you? As far as these digital tools are concerned there are actually THREE! One on your desktop, one in iCloud and one on your phone. Each time you change in any of those places, it syncs *UP* to iCloud and then down to the other devices.

Collisions happen if you make changes in two places. Imagine if you’re a road warrior and your laptop was offline for some days, or your smartphone for that matter. In those cases that syncing would happen much later, and collisions more likely.

Related: Why the twitter IPO made a shocking admission on scalability

In the high frequency world of online databases

With online databases, all of this becomes vastly more complex. Web based applications may have 100,000 simultaneous users. Some may be coming from IMEA while others the Americas. It gets pretty darn complex when you have databases in each of those regions.

We deploy applications this way, so one datacenter, say the East Coast region one version, can fail, but all the others still operate. They can still change data, read and write, without being impacted by the New York outage.

Once that datacenter is restored, the databases will then sync up and reconcile missing data.

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

MariaDB and Amazon RDS read replicas

MySQL and it’s variants of MariaDB, Percona and Amazon RDS can do something like this with read-replicas. The read-only copies of the database are asynchronous and take time to catch up to changes. You can have the read-only copies in different regions.

This improves availability for browsing your application, but not for making changes. In other words MySQL can use this method to scale reads but not writes. That’s why I recommend your applications also support a browse only mode which means availability won’t be impacted if your authoritative master dies.

Although you can try to do the same for writes by sharding your MySQL instances, this starts to get very messy very fast. Imagine backing up 10 shards, 10x the complexity, and even more when you want to go and do a restore.

Read: Why devops talent is in short supply

Amazon’s Dynamo DB

Amazon’s DynamoDB is a technology based around the original Dynamo whitepaper which attempts to solve a whole class of problems by easing eventually consistent constraints.

What you get is more availability, it’s hard for the whole cluster to go down. That’s great for applications because they can continue to operate if one or more nodes fails. It also scales writes, which is a sort of holy grail in the database world as it’s typically hard to do.

But remember all this comes at a cost. Traditionally scaling writes is hard to do because all changes are kept in one place. You maintain a single authoritative master. If you want to imagine why this matters, think back to our smartphone example. We changed our contact card on our phone and our desktop at the same time. One of those two changes won the battle. But that’s a case where we’re not overly concerned.

If you imagine a bank doing the same thing, and you wire $1000 via phone and desktop, you can quickly see that there is a whole class of applications that won’t be happy with eventually consistent. Your web application may be one of those. Or it may not. Consider carefully before you go with Amazon RDS or DynamoDB as your datastore.

Read: Why startups need more than great developers to achieve scalability

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

Why startups need techops

devops divide

I was at a talk recently on node.js. Even if I’m not working with a technology directly, it’s exciting to see what’s out there, and node.js is bringing some hyper fast performance to a certain category of web applications.

During the keynote, the speaker mentioned a service to deploy applications on. I can’t name names unfortunately but it was a cloud solution on top of which you could deploy your application. Go this route
and you can do without an operations team. Avoid overhead of hiring ops, he claimed. And hey, then you can hire more developers!

To be fair I’ve heard much of the same thing at DBA or linux conferences. I can’t count the number of stories that start with “what some idiot developer did that took down our production systems…”.

Yes, it seems dev & ops are still just a tad bit adverserial.

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

1. My little known origins as a developer

Many colleagues and clients I’ve met in the New York City startup industry know me primarily as an operations & scalability guy. I tune databases, infrastructure and components to make things lightening fast.

I spent my earliest years at university on the computer lab operations staff. We watched and managed, made sure level zero backups were taken care of, and moved the tapes. Directly after college, I started at a software firm. I did C++ GUI development on the Mac, using the toolbox libraries with Metrowerks Codewarrior. I built split windows, and scroll bars, and displayed rows of data with nice resizable columns. All this wasn’t built into the class library, so for a lot of it we needed to roll our own solution.

We always had a long list of features coming from the business units. I also fielded many support calls, often from the windows platform as the code there hadn’t been managed and built as carefully. But that too was instructive as you could feel the pain of customers day-to-day challenges. It also illustrated the tradeoffs between new code and features, and existing bug fixes and support.

Also: Why generalists are better at scaling the web

2. A trip through the dot-com bubble as Oracle DBA

Through a circuitous path, I moved to New York in the mid-nineties and joined a startup. I had the opportunity to wear a lot of hats there, and apply my computer lab and Linux operating systems experience to the challenge of managed Oracle. I got a lot more involved with operations quick.

As the dot-com bubble grew, I saw a hot and growing demand for Oracle DBAs as most startups used Oracle, but the talent was in short supply. In one startup 80 million dollars was on the line as performance hobbled the website, and investors feared the worst.

Read: Why the Twitter IPO made a shocking admission about scalability

3. Different priorities & mandates

I remember working at Starmedia a media darling at the time. I was analyzing the database & server systems, and finding some code & jobs running during peak daytime hours. Management claimed that could not be the case. Yet for the next days and weeks I saw the same jobs running. I held strong and spoke truth to power as they say. That’s not always easy when you have a lot of investors, screaming CTOs and 100+ hour weeks. But eventually the source of the job was located, and disabled. And the website returned to it’s speedy self.

These experiences though do underline in my mind the different priorities and focus that developers and operations staff have.

Techops, system administrators & DBAs are typically averse to change. They fight it tooth and nail. That isn’t because they like to be curmudgeons though. They are typically very concerned about the business, but from a dramatically different perspective of stability, and reliability, even at 2am in the morning. They are concerned about the longevity of data, consistency, and durability of it.

Developers on the other hand have a different mandate. They are responsible for new business features, solutions to business requirements. Rapid prototyping & reactive or agile is embraced because it means you can deliver quicker to the business.

Crucially, both of these folks care very much for the business. Just with very different priorities.

Check this: Why AirBNB didn’t have to fail

4. Can developers do operations for you?

In a lot of small startups, the initial phase is obviously on building a product. That’s the build phase, and not surprisingly you hire a lot of developers. As you should. But as you grow you may find the operational tasks that are defaulting to one or more developers are taking more and more of their time. As your customer base grows and you’ve seen your first few spikes, it’s time to start thinking about hiring for a real ops role.

In summary, yes they can, but perhaps not well.

Related: How to hire a developer that you can work with

5. Volume discount, made to order or instant coffee

You may choose to go with instant coffee, by bringing someone in-house. You may find the right talent is hard to find. I wrote about this: Why techops and DBAs are in short supply.

Alternatively you may prefer a volume discount from one of the larger remote DBA or managed support solutions such as Oracle’s, Pythian or Percona. These guys all provide great service, but keep in mind how big of a fish you are. You’ll likely work through a ticketing system, and in some cases different engineers will look at your systems at different times. You will likely need either a very hands-on technical CTO or other in-house person to take ownership, and manage things closely.

The third option is a made-to-order coffee. Yes you pay more for Toby’s, Blue Bottle, or Ninth Street Espresso but you get what you pay for as they say. A boutique shop or independent consultant will provide a lot more hand holding, help your internal staff get up to speed, and communicate intimately about the process. If you’re a more non-technical CTO, or you’re very busy running the business, this solution may make a lot of sense for you.

Also: Why cloud detractors need a history lesson

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

Round up of recent scalability, startup & social media posts

strawberries

If you’re checking back in, we’ve written a lot of new content recently. Here are some highlights for digging a little deeper.

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

1. Why you should evaluate carefully before hiring a consultant

You’re a startup, and you’re grappling with some particularly thorny problems. You’ve gotten pocked and scratched, and are still struggling with big issues. So you’ve decided to hire a consultant, now what?

Evaluating consultants is a key step to ensure you find someone you can work with. But how is the process different from interviewing a candidate for a fulltime role? Here’s our thoughts on it.

2. Why a killer title can make or break your content efforts

For devops & techops bloggers out there, I’ve put together this quick howto guide. Titles really make the difference as to whether your content gets noticed, or ends up dying on the vine.

Don’t let it happen. Practice some creative title writing and other tips and you’ll be zooming your way to the top!

3. Why real world high availability is so hard to deliver

Five nines, goes the saying, is the gold standard for availability. But if it is really a standard, then why the heck isn’t anybody really achieving it?

4. Why a four letter word divides dev and ops

The on-going battle between developers and operations teams rages, devops be damned. Here’s our take on the age-old turf war!

5. Why Amazon RDS doesn’t support Percona or MariaDB

Should I use Amazon RDS or build my own MySQL box on EC2? It’s a question I hear constantly from clients and prospects. The answer of course is it depends!

In this short article, I hit on some of the typical use cases, and discuss which solution is best. If you’re interested in Percona & MariaDB, you’ll want to take a look.

6. Why techops talent is in short supply

Database administrators? Systems administrators? Ops teams? They don’t carry the sexy allure that rock star developers do, but once code is deployed, and out in the wild, these are the swat teams, and national guardsmen that you’ll rely on everyday. They’ll monitor your systems, and when necessary wake at 3am to repair things that have fallen over.

Despite their crucial role in web application deployments in the cloud, they remain in short supply.

7. 5 more things deadly to scalability

Scalability is the goal every fast growth startup struggles with. Here are some key best practices to keep reliability and capacity in the crosshairs.

8. Why the Twitter IPO makes a shocking admission about scalability

Flip through a tech company IPO filing, and you’ll find some rather vulnerable admissions about data centers and fragile architectures. How can this even be possible, for a major internet firm that’s dealt with the fail whale many times before?

9. Why reaching journalists with email fails where social media & twitter succeed

After reading Adrienne Erin’s 7 deadly sins of pitching I felt discouraged. Everything she said in there I had done. Pitching is a game neither writers or journalists enjoy. I’d long since given up on it.

Then I thought about it some more. Actually I’d had some good success reaching journalists on social media. I just didn’t really think of it as pitching per se. That’s because it was more like getting into the conversation. It was almost like the networking and hob nobbing we do naturally at conferences and meetups. So I wrote about what worked for me. Read more

10. 25 Rumsfelds Rules for startups & managers with tweetible links

Donald Rumsfeld, what can be said? What can’t be said? Well for all controversy and bad press you have to give him credit for some great one liners.

I picked up his new book, and couldn’t put it down. There’s inspiration on every page!

So I selected out my twenty five favorite quotes, and included them here for your twitter enjoyment!

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

Why email pitching fails when social media succeeds

Editor & writer in friendly dialog

I was reading Adrienne Erin’s muck rack list 7 deadly sins of pitching. It struck me that I had committed many of the sins she mentioned. Maybe I was writing too much, or emailing at the wrong time, or being boring. It’s possible. Unfortunately I don’t know which of the sins to work on. Because there was no dialog.

But thinking about it more, maybe it’s just the nature of email? I’ve definitely tried pitching before, and didn’t seem to get anywhere. Not even a response. It seemed all that formality was falling flat. Ultimately email pitching is a waste of time. There I said it. I’ve sent them, never seemed to get me very far, try, try as I might.

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

Reading her sins though, I did feel inspired a bit to write about what has worked for me. And what has worked from time to time is having real conversations on twitter.

What I’ve learned is, drum roll please… don’t make pitching like cold calling or online dating. Because those lack context. Without that, you’re just a stranger…

So what do I do? Here’s what’s worked for me.

1. Twitter has tools, make a list

Search google for a Gigaom, Forbes, Pando or ReadWrite and you can find a list of twitter handles. But they’re all not created equally.

Some folks use twitter as a one-way ticker, but don’t converse much. Or they focus on topics not related to industry & business. Others actively use twitter professionally. Look for the latter folks.

Related: Why the Twitter IPO makes a shocking admission on scalability

2. Check that list, get interested

I could use the word “engage” but I feel it’s lost it’s meaning. The point here is that twitter is one giant conversation, among folks some known personally, and some only in the social sphere..

Comment on articles, add your opinion, or mention a quote or bit of the piece you thought really struck a nerve.

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

3. Be helpful, share something you know

Don’t just charge in like a bull, asking for something. No one likes this in business. It’s why I’m frustrated sometimes with recruiters.

See a typo in a title or article, or something that might be awry? Spot a fact that needs clarification? Why not help a reporter out. LOL Think if you were hiring, what type of people would you most likely hire? Those who are helpful.

Read: Why high availability is so very hard to deliver

4. Strike while the iron is hot!

Making a connection is great. And not easy. So don’t go screwing it up asking for too much. Ask if they’re looking for guest bloggers, and who to talk to on your selected topic. Hopefully if you’re already working this hard for a publication, you’ve checked that!

When you have someone’s ear it’s important to avail yourself of it. Email offline, and share some topic ideas, and sexy titles. To me the title is the name of the game these days. Have some in mind. Show that you’re already playing with titles. If you get a good, vibe, write some new material

Read this: Why you should evaluate before hiring a consultant

5. Be open to criticism

Listen more than you speak and heed the guest posting guidelines.

Hear what the editor is suggesting, and be willing to move in a direction that might appeal to the largest audience.

Get something back in a few days. Extending the hot iron metaphor, no time like the present!

Good luck!

Read: Why generalists are better at scaling the web

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

25 Rumsfelds Rules for Startups

RumsfeldsRules

Join 12,100 others and follow Sean Hull on twitter @hullsean.

While we are still deep in the woods of a government shutdown, I thought it would be interesting to sum up some of our former Defense Secretary’s words of wisdom.

Rumsfeld may not have done everything right, but some of his quotes are priceless. What’s more they appeal to Startups quite nicely…

1 If you are working from your inbox, you are working on other people’s priorities.

Click To Tweet

2 Men count up the faults of those who keep them waiting.

Click To Tweet

3 In unanimity, there may well be either cowardice or uncritical thinking.

Click To Tweet

4 Test ideas in the marketplace. You learn from hearing a range of perspectives.

Click To Tweet

5. You can’t recover a fumble unless you’re on the field. Get out there.

Click To Tweet

Read this: Why the Twitter IPO mentioned scalability

6. First law of holes. If you get in one, stop digging.

Click To Tweet

7. Talent hits a target no one else can hit. Genius hits a target no one else can see.

Click To Tweet

8. You pay the same price for doing something halfway as for doing it completely so you might as well do it completely.

Click To Tweet

9. It is difficulties that show what men are.

Click To Tweet

10. What you measure, improves.

Click To Tweet

Also: Why I don’t work with recruiters

11. If you are lost, “climb, conserve and confess”

Click To Tweet

12. It is not the strongest species that survives, nor the most intelligent, but the one most responsive to change.

Click To Tweet

13. Luck is what happens when preparation meets opportunity.

Click To Tweet

14. People don’t spend money earned by others with the same care that they spend their own.

Click To Tweet

15. Disagreement is not disloyalty.

Click To Tweet

Related: Why a CTO must never do this

16. A lie travels halfway around the world before the truth gets its shoes on.

Click To Tweet

17. It is easier to convince someone they’re right, than to convince them they’re wrong.

Click To Tweet

18. Your best question is often why.

Click To Tweet

19. Simply because a problem is shown to exist, it doesn’t necessarily follow that there is a solution.

Click To Tweet

20. The world is run by those who show up.

Click To Tweet

Read: Who is Sean Hull?

21. Don’t panic. Things may be going better than they seem from the inside.

Click To Tweet

22. Know that the amount of criticism you receive may correlate closely to the amount of publicity you get.

Click To Tweet

23. Sunshine is a weather report, a flood is news.

Click To Tweet

24. If you expect people to be in on the landing, include them in the takeoff.

Click To Tweet

25. If a problem cannot be solved, enlarge it.

Click To Tweet

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

Get more in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample

http://www.flickr.com/photos/estabrook/5729555412/

Why weekly billing amps up time pressure

http://www.flickr.com/photos/estabrook/5729555412/

Join 11,500 others and follow Sean Hull on twitter @hullsean.

This past year I worked on an 8 week contract. I was tasked with helping improve scalability, measuring current throughput, then troubleshooting systems & infrastructure to find the big problem areas.

Slow process of on-boarding

In only six months, the firm had grown from a small startup, to a larger mid-sized company. That kind of growth is great for margins & investors, but it’s tough on teams & management.

We had outlined a nice todo list up front. Tasks would fit well within our eight week budget, with some additional time for things that came up along the way.

As it turned out, on-boarding for the project got drawn out. I got tangled in email problems, configuring, forwarding, and so forth. The default on-boarding process placed me on various general lists about office parties, and treasure hunts. Having all this email forwarded to me became a problem to untangle.

Meanwhile getting credentials and logins to the correct servers was a challenge. Tickets were created, emails flew back and forth and time rolled on.

Read this: Why operations & MySQL DBA talent is hard to find

Time pressure at the end of engagement

As the engagement barreled on, we reached the final two weeks mark. It was then that I scheduled another meeting with the director of operations, and to go over status.

At that point the team was fighting some new fires with database change management. I was intrigued by the problem, and wanted to dig in and see if I could assist. But at that point we both agreed there wasn’t sufficient time left to devote to it.

Having spent a large portion of the engagement up front on administrative tasks, we now had time pressure at the end to finish the tasks agreed to.

Related: 8 Questions to ask an AWS expert

The hourly billing experience

I’d worked on many hourly clients over the past decade. With hourly projects the VPN configuration, logins & admin tasks sometimes fell through the cracks. Firms of all sizes, even small startups, often have a lot of balls in the air at once.

On hourly billing, when things get drawn out, there’s no real pressure. The cost to the firm is the same whether they drag their feet or push to get things done rapidly.

Read this: Why Amazon RDS doesn’t support Maria DB or Percona

Contrast with weekly billing – mutual accountabilities

The contrast with weekly billing engagements is palpable. You feel it right out of the gates. We both want to make good use of time. And clients feel they don’t want to waste resources, and budgets.

That’s a good thing. There’s an incentive on everybody’s part to keep things moving.

Also: Why generalists are better at scaling the web

We act when we feel it in our wallet

My conclusion from these experiences, we act when we feel pressure on our wallet. With weekly billing the client will pressure their own teams on mutual accountabilities. They’ll also pressure you the consultant or service provider. So be prepared to pull your own weight.

When things are not moving along smoothly, expect discussion to quickly bubble to the surface. Embrace these moments, for everyone will have incentive to solve those problems.

Time pressure & budgets – keys to successful consulting engagement.

Related: Why I don’t work with recruiters

Get more in your inbox: Exclusive monthly Scalable Startups. We share tips and special content. Here’s a sample