Does migrating to the cloud require a mindset change of your team?

via GIPHY

We’ve all heard the success stories at firms that have grappled with automation. The dividends are legendary.

Take Amazon themselves for example. By decoupling their teams, allowing each to grow independently and at their own pace, they’ve been able to scale massively.

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

One look at the AWS dashboard these days, or their wikipedia page, reveals over 90 services on offer. And each of those is growing and expanding by day.

I’ve worked with a lot of startups, trying to get there. They’ve heard the gospel, and want to gain the benefits themselves.

Here are the challenges I’ve found.

1. Building ain’t easy

One example story was building an ELK box. ELK is elasticsearch, Logstash and Kibana. It provides a centralized place to send all your application & service logs, collect them all together on one dashboard. It’s the business intelligence of devops & software development. Super valuable tool.

In building our solution, we took a marketplace AMI off the shelf, and then customized that. After building the terraform code to spinup the server, we added Ansible scripts to further customize. This allowed us to add a cronjob for backups, set a password, add additional logstash configs, and a few other important housekeeping tasks.

All was great until we hit a snag, we found some CloudWatch logs were not making there way into ELK. Digging through the log messages, we eventually uncovered an error. And that was caused by a conflicting port configuration. So we removed that unused in logstash.conf, and problem solved.

Later, we rebuilt the server and that was pretty quick. Having all the scripts in place, meant we could rebuild quickly. In this case we just needed to resize the root volume by 25x to make room for future logs. This was 3 lines of terraform code and then done!

A couple of weeks later however, we found missing logs again. Digging digging digging, and then we finally discover it is a repeat of our old problem! Turns out the change to logstash.conf never got rolled into the automation scripts. It was done manually! Bad bad!

Moral of the story, with automation, your workflow needs to change. You should *always be working on the scripts* and then reapplying those. Never work on the server directly!

Time to eat my own dogfood!

Related: Is AGILE right for fixing performance issues?

2. Troubleshooting is tough

In the automation universe, as I wrote above, you really want to avoid logging into servers and doing things manually. But that may be easier said than done.

Take another example, I had an ssh key distribution script. I repurposed from the Terraform Community Modules. It works great when it works. It gets injected onto the server at boot time, by terraform inside the user-data script.

The code gets added to cron, and relies on awscli. As it turns out awscli is *not* on all of the aws linux images. Who knows why?!? But that’s where we are.

Should be easy to install. Use yum to get pip (python package manager) installed. Then use pip to install awscli. The script even has *both* yum and apt-get commands to attempt to install pip on either ubuntu or amzn linux. Problem is sometimes it doesn’t. Sometimes? You ask. Yes indeed.

Digging further, it seems that the new pip package gets installed in /usr/local/bin, while it used to install in /usr/bin/. Seems simple. Add a symlink. Yeah did that. Sometimes the package has a different name, such as python-pip3. Great!

Now all this is magnified because you can’t just go on the box and go through the steps. Why? Because in the primordial cromagnon universe that is linux server boot time, sometimes things happen in weird orders, or slower. So you may have something missing during that period, that is later available. So after boot you see no errors.

Yes complicated. Yes you need to build, destory, build destroy the server in endless cycles.

At the next level of automation, we will implement infrastructure testing pipeline. This will automatically build the server for you. The infrastructure unit testing framework seems pretty darn cool. And there is also Gruntworks Terratest.

Related: Is automation killing old-school operations?

3. The dividend is agility

What have i seen in terms of agility?

Well moving our application to a new region takes 20 minutes. Crazy as that sounds, from vpc, to 3 private subnets, 3 public subnets, bastion boxes, load balancers, rds & redis instances, security groups, ingress rules, iam roles, users, s3 buckets, ecs cluster, and various ec2 instances, route 53 zones & cnames, plus even EIPs all can be moved with a few simple code changes. Wow!

What else? We can resize our ELK box root volume by deploying a brand new setup, all in about ten minutes.

This kind of speed is so exciting. It brings repeatability to your engineering processes. It brings confidence to all of those components.

And best of all it allows the business to experiment with new product ideas, and accelerate in the marketplace.

And we all know what that means!

Related: I have a new appreciation for AGILE

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

How best to do discovery in cloud & devops engagements?

via GIPHY

Customers reach out to me asking to do implementations, that is architecting applications, deploying code to the cloud, optimizing, tuning, and automating all the things.

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

But there are also a portion of engagements the require an amount of discovery. Some of that is technical in nature, and some is more around people and process.

Here are my thoughts.

1. Technical discovery

This is the most obvious type of discovery I might do. It would involve code reviews to begin, and then architecture reviews. Diagrams, microservice communication, apis and so forth.

Here’s a sample executive summary I did for one engagement, with names changed.

Next there is infrastructure, which of course should be defined in code. Terraform and CloudFormation provide good solutions here.

There also is hopefully documentation to review. This includes README’s and code comments, but also confluence docs as well.

Related: Can progress reports help engagements succeed?

2. Process discovery

Understanding the process of how the engineering team builds software, and gets new features to customers cannot be overstated.

What is the methodology? How are deployments managed? Do they break often? How quickly can a developer get changes to production?

I’d recommend this a16z podcast on devops to get a better understanding of this process.

Related: When clients don’t pay

3. Team discovery

This is another area that is key to success. Is there an offshore team? Are SRE’s working remote? Are devs all here in New York or elsewhere? How well is communication happening? Are there trouble spots? Bottlenecks?

In particular it’s worth looking at strengths, weaknesses, opportunities and threats to team and cohesion.

Related: A CTO must never do this

4. Tools discovery

I’m often surprised how many firms don’t know what they have. As enterprises grow, and as team turnover changes, the institutional knowledge can sometimes move with them.

In these cases review of systems and tools in place can be very helpful. Tracking a product, its deployment, and the components in place to facilitate that.

This process can uncover surprises and much room for improvement.

Related: When you have to take the fall

5. In Summary

I’ve uncovered opportunities for improvement in all of the four areas. Although technical discovery high on the list, the other areas can also be ripe areas for investigation.

Production quality, efficiency, and speed of execution and overall team morale and communication all contribute to the velocity of the firm in the marketplace.

Related: 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

Is there a serious skills shortage around devops space?

via GIPHY

As devops adoption picks up pace, the signs are everywhere. Infrastructure as code once a backwater concept, and a hoped for ideal, has become an essential to many startups.

Why might that be?

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

My theory is that devops enables the business in a lot of profound ways. Sure it means one sysadmin can do much more, manage a fleet of servers, and support a large user base. But it goes much deeper than that.





Being able to standup your entire dev, qa, or production environment at the click of the button transforms software delivery dramatically. It means it can happen more often, more easily, and with less risk to the business. It means you can do things like blue/green deployments, rolling out featues without any risk to the production environment running in parallel.

What kind of chops does it take?

Strong generalist skills

For starters you’ll need a pragmatist mindset. Not fanatical about one technology, but open to the many choices available. And as a generalist, you start with a familiarity with a broad spectrum of skills, from coding, troubleshooting & debugging, to performance tuning & integration testing.

Stir into the mix good operating system fundamentals, top to bottom knowledge of Unix & Linux, networking, configuration and more. Maybe you’ve built kernels, compiled packages by hand, or better yet contributed to a few open source projects yourself.

You’ll be comfortable with databases, frontend frameworks, backend technologies & APIs. But that’s not all. You’ll need a broad understanding of cloud technologies, from GCP to AWS. S3, EC2, VPCs, EBS, webservers, caching servers, load balancing, Route53 DNS, serverless lambda. Add to all of that programmable infrastructure through CloudFormation or Terraform.

Related: 30 questions to ask a serverless fanboy

Competent programmer

Although as a devop you probably won’t be doing frontend dev, you’ll need some cursory understanding of those. You should be competent at Python and perhaps Nodejs. Maybe Ruby & bash scripts. You’ll need to understand JSON & Yaml, CloudFormation & Terraform if you want to deliver IAC.

Related: Does a 4-letter-word divide dev & ops?

Strong sysadmin with ops mindset

These are fundamental. But what does that mean? Ops mindset is born out of necessity. Having seen failures & outages, you prioritize around uptime. A simpler stack means fewer moving parts & less to manage. Do as Martin Weiner would suggest & use boring tech.

But you’ll also need to reason about all these components. That’ll come from dozens of debug & troubleshooting sessions you’ll do through years of practice.

Related: How to hire a developer that doesn’t suck

Understand build systems & deployment models

Build systems like CircleCI, Jenkins or Gitlab offer a way to automate code delivery. And as their use becomes more widespread knowing them becomes de rigueur. But it doesn’t end there.

With deployments you’ll have a lot to choose from. At the very simplest a single target deploy, to all-at-once, minimum in service and rolling upgrades. But if you have completely automated your dev, qa & prod infra buildout, you can dive into blue/green deployments, where you make a completely knew infra for each deploy, test, then tear down the old.

Related: Is AWS too complex for small dev teams?

Personality to communicate across organization

I think if you’ve made it this far you will agree that the technical know-how is a broad spectrum of modern computing expertise. But you’ll also need excellent people skills to put all this into practice.

That’s because devops is also about organizational transformation. Yes devs & ops have to get up to speed on the tech, but the organization has to get on board too. Many entrenched orgs pay lip service to devops, but still do a lot of things manually. This is out of fear as much as it stands as technical debt.

But getting past that requires evangelizing, and advocating. For that a leader in the devops department will need superb people skills. They’ll communicate concepts broadly across the organization to win hearts and minds.

Related: Will Microservices just die already?

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

What have I learned in 10 years of blogging?

via GIPHY

I was just reading Andrew Chen’s latest posting, where he distills many of the things he’s learned from blogging over a decade.

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

This reminded me that I’ve been blogging that long as well. And to be sure it has brought great benefits. In the way that public speaking gives you visibility, but also forces you to communicate better, form your voice, and so on.

All the great things you gain by talking to other people, and getting into the conversation.

1. Understand your audience

I struggled with this when I first started blogging. As any engineer might approach things, I thought I should publish technical material. What better way to show what I know. And further how I can help a customer.

What I didn’t realize is that all of your readers aren’t technical. So it goes a long way if you can appeal to a broader audience.

I found that my readers fell into a few big categories.

1. Fellow engineers & peers
2. Hiring managers & startup CTOs
3. Recruiters & other publishers

This really helped me divide up the types of content I would write, some directed towards each of the different audiences.

Related: Why does Reddit CTO Martin Weiner advocate boring tech?

2. Tell your story

I’ve written often about why I wrote the book on Oracle. In it I outlined a long arc of datacenter evolution which started with the maturity of Linux, and today provides the bedrock of the cloud that is Amazon Web Services among others.

What this also allowed me to do is tell my own history.

Related: 5 reasons devops should blog

3. Form your voice

Forming your voice is different than speaking to specific audiences. It’s about having opinions & getting into the line of fire. Being passionate about a subject, you’re sure to care & sit on one side or the other of a particular argument.

For example I argued the Android ecosystem was broken. Although Google has fixed some of these problems, many remain as a symptom of the platform itself.

I also argued with Fred Wilson’s estimation of Apple being overvalued. At the time in May 2014 the price was at $85. Now it sits comfortably at $177.

Related: How to hire a developer that doesn’t suck

4. Put yourself out there

Putting yourself out there isn’t easy. You’ll be open to criticism. And sometimes you’ll be wrong. But by challenging yourself in this way you’ll grow too. And prospects will notice this. More than engineering might, and power at the keyboard, your perspective of what’s happening in computing generally, and what is on the horizon is invaluable to customers.

Related: 30 questions to ask a serverless fanboy

5. Learn & Share

Writing howtos is a great challenge too. By forcing yourself to teach something, you in turn learn the material better. You become better at executing, and formulating solutions.

As you share knowledge, you’ll also learn from others. As the disqus.com comments on my site can attest. Sure you get much of this same value from having an active account on Reddit.com, but your own real estate carries even more weight for your personal brand.

Related: Why you should always be publishing

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

Is AWS too complex for small dev teams & startups?

via GIPHY

I was discussing a server outage with a colleague recently. AWS had done some confusing things, and the team was rallying to troublehsoot & fix.

He made an offhand comment that caught my attention…


AWS is too complex for small dev teams. I’d recommend we host in a traditional datacenter.

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

It’s an interesting point. For all the fanfare over Amazon, lost in the shuffle is the staggering complexity that we’re taking on. For small firms, this is a cost that’s often forgotten when we smell the on-demand cool-aid that is EC2.

Here are my thoughts…

1. Over 70 services offered

Everytime I login to the AWS console there’s a new service offering. Lambda & serverless computing. CodeDeploy, Redshift, EMR, VPC’s, developer tools, IOT, the list goes on. If you haven’t enabled MFA on your IAM accounts you’re not alone!

Also: Is Amazon too big to fail?

2. Still complex to build high availability

The song I hear out of Amazon is, we offer all the components for a high availability infrastructure. multiple availability zones, regions, load balancers, autoscaling, geo & latency dns routing. What’s more companies like Netflix have open sourced tools to help.

But at a lot of startups that I see, all these components are not in use, nor are they well understood. Many admins are still using Amazon like an old-school datacenter. And that’s not good.

Sometimes it seems that AWS is a patient in need of constant medication.

Related: Are we fast approaching cloud-mageddon?

3. Need a dedicated devops

As AWS becomes more complex, and the offering more robust, so too the need for dedicated ops. If you’re devs are already out of bandwidth, but you don’t quite have so much need for a fulltime resource a consultant may be an option. Round out the team & keep costs manageable.

If you’re looking for an aws solutions architect, we can help!

Check out: Does Amazon eat it’s own dogfood?

4. Orchestration involves many moving parts

Infrastructure as code offers the promise of completely versioning all your servers, configurations and changes. From there we can apply test driven development & bring a more professional level of service to our business. That’s the theory anyway.

In practice it brings an incredible number of new toolsets to master and a more complex stack besides. All those components can have bugs, need troubleshooting. This sometimes just kicks the can down the road, moving the complexity elsewhere.

It’s not clear that for smaller shops, all this complexity is manageable.

Also: 5 things toxic to scalability

5. Troubleshooting failed deployments

I was looking at a problem with a broken deploy recently. Turns out a developer had copy & pasted some code solution off the internet, possibly from a tutorial, and broke deployments to staging.

Yes perhaps this was avoidable, and more checks & balances can fix. But my thought is continuous integration & continuous deployments are not a panacea. More complexity brings a more complex web to unweave.

I sometimes wonder if we aren’t fast approaching cloud-mageddon?

Read: 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

What events are good for tech & startup networking in New York City?

garys guide events

I’ve worked in the NYC startup scene since the mid-nineties. It seems to keep growing every year, and there are so many events it’s hard to keep track.

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

Here’s where to look for the best stuff.

1. Gary’s Guide

Gary Sharma hosts an authoritative guide to all the events in the new york tech & startup scene. It’s sort of the one-stop shop for knowing what’s going on.

Lucky for us, in a city the size of new york, there’s an opportunity to meet & network with people everyday of the week.

Also: 5 core pieces of the Amazon cloud puzzle to get your project off the ground

2. Meetups

Meetup.com is another invaluable resource. There are technical groups & social ones, and plenty of niche groups to for specific areas of interest.

For example there’s NYC Tech Talks, NY Women in Tech, Tech for good & NY Entrepreneurs & Startup Network. There are plenty more.

Related: Some thoughts on 12-factor apps

3. Eventbrite

A lot of events us Eventbrite for ticketing, so it turns out to be a great place to search. Some of the startup related events .

Read: Why dropbox didn’t have to fail

4. Techdrinkup

Michael Gold’s #techdrinkup event keeps getting bigger & better. More social hour than presentations & such, you’re sure to bump elbows with some folks in NY’s exploding tech scene.

Take a look at some of the event photos on their facebook page.

Also: How do hackers secure their Amazon Web Services account?

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

What happens when entrepreneurs treat data as a product?

Sneachta Pix
Sneachta Pix

I’ve been reading DJ Patil’s thoughts on building data products. As the chief data scientist of the united states, he knows a thing or two.

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

I also attended a recent Look & Tell event, where Lincoln Ritter talked about Data Democracy at Animoto. He expressed many of Patil’s lessons.

I took away a few key lessons from these that seem to be repeating refrains…

1. UX of data

UX design involves looking at how customers actually use a product in the real world. What parts of the product work for them, how they flow through that product and so on.

That same design sense can be applied to data. At high level that means exposing data in a measured, meaningful & authoritative way. Not all the tables & all the data points but rather key ones that help the business make decisions. Then layering on top discovery tools like Looker to allow the biz-ops to make more informed decisions.

Also: 5 Reasons to move data to Amazon Redshift

2. Be iterative

Clean data, presented to business operations in a meaningful way, allows them to explore the data, and find useful trends. What’s more with good discovery tools, biz-ops is empowered to do their own reporting.

All this reduces the need to go to engineering for each report. It reduces friction and facilitates faster iteration. That’s agile!

Related: Is automation killing old-school operations?

3. Be authoritative

Handing the keys to the data kingdom over to business means more eyes on the prize. That may well surface data inconsistencies. Each such case can reduce trust on your data.

Being authoritative means building checks into your data feeds, and identifying where data is amiss. Then fixing it at the source.

Read: Are SQL Databases dead?

4. Spot checks & balances

Spot checks on data are like unit tests on code. They keep you honest. Those rules for how your business works, and what your data should look like, can be captured in code, then applied as tests against source data.

Also: Is Apple betting against big data?

5. Monitoring for data outages

As data is treated as a product, it should be monitored just like other production systems. A data inconsistency or failed spot check then becomes an “outage”. By taking these very seriously, and fire fighting just as you do other production systems, you can build trust in that data, as those fires become less frequent.

Also: 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

5 Things I learned from Fred Wilson & Mark Suster

I was recently flipping through AVC.com and saw this interview by Mark Suster of Upfront Ventures. He talks in depth with veteran in the VC world, Fred Wilson.

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

Here’s a more in-depth blog post on Mark’s interview with Fred Wilson from Union Square Ventures.

1. I’m not into debt

Around the 20:25 in the interview, Fred is discussing a period in his career before some of his first big investments, where things were financially challenging. He makes a rather candid comment about personal debt:

“I’m not that kinda person. I don’t like debt. I’m not into debt”

I think this is key. I also think it frames the whole way people approach business & career.

Also: Are generalists better at scaling the web?

2. Brains & hustle is key

Among the most successful entrepreneurs there are certainly many who are very intellectually astute. Meanwhile there are others who are great speakers, who can sell an idea, and persuade, but perhaps not as deep product wise or deeply technical.

The very best though, tend to have both brains & hustle.

Related: 8 questions to ask an AWS expert

3. Best technology doesn’t win markets

Around 11:45 in the interview, Mark & Fred are discussing Novell & Banyan.

“That was when I learned that best technology doesn’t win markets”

t’s interesting because as you hear the story of how Banyan lost out to Novell, it resonates today with companies that often have the best tech, but don’t win in markets. Interesting.

Read: Why Airbnb didn’t have to fail

4. Find answers through blogging

“It’s like Venus Fly Paper. When I write about topics that are relevant, suddenly anybody with a startup solution in that field will approach us. This works brilliantly.”

Indeed, I’ve found blogging to be crucial myself to career building. It helps in a myriad of ways.

Blogging brings visibility, as your blog gains in popularity. That is certainly big. But also it helps you craft & formalize your voice & your vision. Blogging asks you everyday to think about your perspective, and share it in a way that appeals to a broad audience. And analytics give you real feedback that you are saying something of value to people.

Also: Are SQL databases dead?

5. Listen to the younger generation

Around 1:11:15 in the interview, there’s an interesting point where Mark asks Fred if there were any deals that they regret not getting into. Fred responds that AirBNB was such a deal, as it was a quintessential Union Square ventures company.

As it turns out they didn’t invest because they couldn’t imagine using the service. Meanwhile the younger members of their team had a different perspective.

“We’re not gonna reject anything that we wouldn’t do and the younger team would.”

Interesting point. I think of Venmo as another example of this. I personally wouldn’t use the service, meanwhile it is clearly very popular among teen & twenty something demographic.

Also: 5 Things toxic to scalability

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

5 Things Frans Johansson says about innovation

medici affect johansson

You may not have heard of Medici before, but you’ve probably heard of the renaissance. The medici family hosted the round tables, the meetups, the social gatherings & mixers. They brought diverse artisans engineers & thinkers together, and the world hasn’t been the same since!

b>Join 16,000 others and follow Sean Hull on twitter @hullsean.

In the Medici Effect, Frans dissects what this famous family did. His case studies include the likes of Richard Branson, Deepak Chopra, Charles Darwin, Thomas Edison, Orit Gadiesh, Marcus Samuelsson, George Soros & our own favorite Linus Torvalds,

What he discovered really surprised me.

1. Swim at the intersection

Hanging out with folks in your field is great. Whether you’re a physician, financial analyst, Ruby programmer, or artist. But it won’t expose us to enough new ideas. To get that, you need to hang out with those in other disciplines. Learn a language, take dance classes, try your hand at a new sport, or attend meetups of wedding planners or DJs. Whatever it takes to get out of your comfort zone is what will put you at the intersection.

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

2. You need quantity to get quality

This was a very surprising finding of their research. One might think that greats like Albert Einstein were geniuses from the start. But it turns out one consistent factor between all these folks is the quantity of their attempts. They came up with many many ideas, and chased as many as they could. Of course they are only remembered for their successes, but this hides the underlying mathematics. It’s a numbers game in almost all of these cases.

Read: Are SQL Databases Dead?

3. Peel all the potatoes and cook them together

Peel one potato and cook it. Then peel another and cook it. Doesn’t sound like a recipe for efficiently preparing dinner does it? Turns out it’s also not great for innovating. Peel & prepare many ideas at once, and try to execute them in parallel if you can. That’s what these greats have done.

Related: Why generalists are better at scaling the web

4. Be ok with more failures

This is a tricky one. But Johansson puts in perspective with this key quote:

”Inaction is far worse than failure.”

Viewed that way, our caution about diving into a new idea seems more limiting. True it costs money, time & resources to pursue new ideas, ventures & startups. So be sure to reserve resources. That’s right spend that money & time carefully lest you run out before hitting on the big one.

He also says to be suspicious of low failure rates. In yourself or those you’re evaluating. This probably indicates you’re not risking enough, or trying new things constantly.

Read this: Why Oracle Won’t Kill MySQL

5. break out of your network

Your network is powerful to pursue your career, or following existing well traveled paths. But they can be an obstacle when forging new paths, which is what innovation is all about.

So break away from your networks. One way you can do this is by building a new one. But be sure to surround yourself with diverse cultures, upbringing, backgrounds & expertise.

Also: RDS or MySQL 10 Use Cases

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