I’m a Florida-native now living in Silicon Valley, interested in startups, programming, UX, and building great web products. More about me.
We’ve been getting some great press and feedback since launching Close.io software for salespeople.
They’ve got a couple good quotes from me in the PandoDaily article.
At the end of a year I like looking back and seeing what I’ve accomplished and what new technologies I started working with in the year. Here’s a little summary.
On Close.io we originally implemented Filepicker.io to allow for file uploads while sending emails. While it was a quick way to get started with file uploading initially, after several minutes of downtime of their API and then an unannounced change in their JSON response format, I was reminded once again that you shouldn’t to rely on small startups for critical parts of your tech infrastructure.
There’s nothing wrong with filepicker.io if you want to use a lot of their features, but in our case we just needed to allow simple uploading of files to our own AWS S3 bucket. Here’s how:
Read the rest of this entry »
I had my first guest post on TechCrunch last week! Here’s an excerpt:
There is often confusion about the various roles of a web engineering team. I have had to explain, even to technical recruiters, the differences between these roles and that the lines that separate them are often fuzzy. I thought I’d share the framework I like to use to evaluate whether someone is a good fit for a startup’s technical team.
In a startup, you can’t afford to have people who are only able to do one thing. Someone could be adept at writing HTML/CSS, but if they don’t have a great eye for design or know JavaScript well, it’s just not worth having them on the core team. Similarly, somebody who knows a little bit of everything but isn’t advanced in anything will just drag the team down.
The size of the company or startup will determine how many different hats each engineer must wear. Many startups get off the ground with a single founder who does a little bit of everything until he or she can grow the team. It’s also possible to outsource some roles completely. Just as cloud-hosting providers such as Amazon Web Services have drastically reduced the need for hardware/network engineers in web startups, platforms like Heroku take it further and (for a price) can reduce sysadmin and DevOps work almost entirely in the beginning.
In pretty much every case, when a startup grows, people will inevitably start specializing. Even those rare gems, who in the early days can spend the first half of the day in Photoshop and the second half scaling a database, will eventually specialize at least somewhat. If you’re hiring well, you’ll always find someone who can outperform you in at least one area.
I’m a big fan of “full stack” people and think specializing too much, too early, is a bad sign for startups. At Elastic, each of our engineers has written CSS and done database/server management. It’s good when a problem arises for there to be more than one person capable of fixing it. That said, I’m spending the bulk of my day writing in JavaScript/Backbone.js because I enjoy it much more than a coworker who’d rather be in Python as much as possible. That’s healthy and it works.
You can read the rest over there.
I just launched a website for Close.io, the product we’ve been working on at Elastic for the past few months.
Go check it out: http://close.io/
We’ve built this as “sales communication software”, which we believe didn’t really exist before. CRMs (salesforce.com, I’m looking at you!) are inadequate because they are more like databases of contacts than software that really helps you do the selling. We’ve trying to change that by making your sales phone calling and sales emailing experience tightly coupled with your lead data (CRM).
Would love to hear any feedback you have about the product!
I got to go to Y Combinator’s Startup School this year and had a great time. Between the reception dinner the night before and the day of event I got to meet a lot of great people and reconnect with some I’d met in the past or only talked to online. Most of the speakers were really good.
I took some very brief notes during some of the talks of the 1 or 2 things that stuck out to me as either surprising, motivational, or instructional.
I watched Jeff Veen’s “Designing for Disaster” talk (below) and took away a couple of parts that I thought were really good. Some notes:
How to do Product Reviews (can be design, product, process, anything) — making an objective process out of something that is very subjective.
It’s 2012 and the web and mobile devices are capable of amazing things, which is why it’s so surprising to me that some of the simplest things are still so hard.
I’ve got the latest iPhone with its 8MP camera and HD video camera, complete with iOS 5 and I pay for extra storage on iCloud. Apple’s supposed to be the best at designing simple user experiences across hardware and software – and I believe they are.
So when I want to take a bunch of photos and videos that I took from my iPhone and share those with some family members, it should be simple right?
The last two years (2010-2011) I spent working at Quizlet were an incredible learning experience.
Like I did in Jan 2010, I wanted to reflect on some of the technologies I learned and things I did over the last 2 years…
I hate to have my first blog post after over a year be a negative one, but I feel like these guys need calling out.
I recently received an email from a company, Honestly.com, that got me quite curious. I looked up the website to see what it was all about, and I saw that they are a way of reviewing former/current coworkers and business partners. Their tag lines are “Get the inside scoop on your potential boss, coworkers, or business partners.” and “Candid community-created reviews of business professionals.” I sort of expected them to be a more extensive version of CubeDuel (which was quite fun for the first few minutes), but with full reviews rather than just ratings…
