Don't let perks blind you from bad culture

Many discussions I have surrounding culture include what the company is doing for their employees (free lunches, gifts, trips, etc.) -- things that should be considered perks, not culture. The culture of a company isn't what founders provide for their employees in an indirect monetary way, in fact culture really has little to do with founders outside of hiring the first 10-ish people. From a founders perspective, after a candidate has passed all of the standard (skill, experience, etc.) check points, you have to examine their ability to make decisions. Hire people who given all the resources necessary, are capable of making the right decision about direction, work load, implementation, and priority -- because in the end they are the ones that will be growing the culture.

Keep in mind that you can't just expect to hire people, and wash your hands of any oversight. As founders it is your responsibility to ensure that you are transparent with what is happening, if your team members don't know what is going on, it will be impossible for them to make the decisions you are expecting them to make.

I think that one of the hardest parts of this topic is that not many of us have been through this, and therefore the stress that comes along with launching and growing a company is only magnified when you start hiring. There are two sides to this story though:

  1. Founders: You have a responsibility to create a company that people want to work for. The old-time mentality of "I sign your paycheck so deal with it" just doesn't fly anymore (never should have). Give your employees the access they need, to you and to the company. Encourage them. Embrace them. Empower them. Reward them.
  2. Employees: Your new employer respects you, a lot. You are likely 1 of less than 20 people, which means you are crucial to the companies success and the founders of said company will do everything in their power to make you successful and happy. But keep in mind, you joined a start-up -- founders are not experienced veterans in managing people, companies, clients, etc. While this is not an excuse for shitty founders, take it into consideration and offer your feedback to them before making any drastic decisions or comments.

Ultimately culture is something that an outsider can sense when they walk into your office. It's a vibe, an aura, and most people can read it like a book. If your company has a bad culture, you simply cannot cover it up with free lunch and week long trips. 

Impact is the new sexy

The term 'sexy' being applied to start-ups seems a bit... unfitting. As far as I'm concerned sexy is a relative term, plenty of things I find sexy, that others find boring, ugly, or otherwise not desirable.

So really, what does it mean? Advertised "sexy startups" are typically those that relate to a broad audience, meaning people who work there don't have to explain themselves when asked where they work. Is that really what makes a job worth having? Being able to feel cool when telling people where you work? 

    "Choose a job you love, and you will never have to work a day in your life." -Confucius

I feel as though you should work for a company that you can personally be passionate about; a company that solves a problem you believe in, not one that deems itself sexy. When looking for a new job I would suggest avoiding

  • Cool technologies, for the sake of being cool. Is it being used in a way that makes any sense, or just because someone went off on a tangent one afternoon following a HN post?
  • A focus on gimmicks. If a companies pitch to you is about the perks, and only the perks, what assumptions can be made about the work environment and their focus?
  • Growth statistics. Wouldn't it make sense that a company would be knowledgable of their potential, and plan for these things? Hiring because they are growing sounds like a job that you would walk into and receive zero direction, and be expected to bring a hose and/or bucket. Find a fire, put it out.

EDIT: Just read a comment from Steve Cheney (@stevecheney) which brought to light another hot topic in start ups -- engineer retention. I think this is something that you see far more often in sexy start ups, because the company spent more time making the job posting sound cool, and not enough time building a company people want to work for. If you accept a job at a sexy job, just prepared to look for something else going to work gives you an empty feeling. Thanks Steve!

As I look for technical talent to hire at Science Exchange I've avoided using the term sexy on purpose. I don't feel like it's a good way to measure anything in life.

That being said -- Science Exchange is looking for passionate engineers to join our team. We are built almost entirely on Ruby on Rails (3.2.13). We use asset pipeline, icon fonts, Imgix, Solr, Memcached, and Amazon RDS, S3, Route53. We're currently on Heroku (have a good number of complaints and are looking to switch). We use Asana for task management, Github for version control, and Hipchat for.. chat. We just moved into a rad new office on High St. in Palo Alto (91 Walk Score).

What is the problem we're solving?

Access to Research
We're helping democratize access to research facilities. This allows researchers from smaller less-well-funded universities, independent researchers, and even citizen scientists to access cutting-edge research technologies at the leading US research universities.

Cost of Research
By using experts who can achieve economies of scale to conduct specific experiments very efficiently, researchers save time and money.

Quality of Research
We provide an independent rating system which makes it possible to evaluate the quality of potential partners and allows independent validation of key experimental results at multiple sites to ensure reproducibility.

Sound like something you'd be interested in? We have a cool form that uses the Asana API to provide us your answers to a few questions and your resume. Give it a read, and consider applying:

Marrying a developer gets you more than cat pictures

I'm getting married in May of 2013. I wanted to create an app for my wedding that would help my guests interact with the event as much as possible. I wanted them to be able to get directions, easily contact designated people with questions and see the guest list, but most importantly -- share photos... in real-time! Currently there appear to be multiple apps available that have all or part of this functionality, but at the time I thought of this nothing existed. And in all reality, even now that they exist, I still wanted to build something (looking at the apps available, I'm not impressed with the quality) :)

So, given that I'm an Android owner, I decided the best way to go about this would be to build the app for Android, and see where I could get. I could build the backend in Rails which I know quite well, and throw in a few other new tools where I see fit.

Long story short, I ended up creating something that I'm quite happy with, and really pretty proud of. The app is called OURSVP (get it, our.. s.v.p) and can be downloaded for free in Google Play.

Some things I used that I think are neat (and what I used them for):

  • Imgix: This allowed me to serve different image sizes, both dimensions and quality, depending on the screen densities and operating systems ensuring a consistent experience across all phones.
  • Node.js: All photos are uploaded to a node.js endpoint that streams them directly to S3 (using a forked repo since the owner won't accept pull requests to the original), which makes them immediately available to Imgix, the app, and the live stream. This also pulls the heaviest operation of the app to a separate, asynchronous application that is served from Heroku
  • Pusher: I realize there are more complex, robust ways of doing this but given my time constraints I had to fall short on some things. This provides the real-time functionality for the photo viewer to display photos as guests take them.
  • Rabl: The web app is written in rails, so I decided to create a JSON API for the app using Rabl which is what the mobile apps use to communicate with the app.
  • ActionBarSherlock: Awesome library that allowed me to provide the same experience on older Android devices, very well done and extremely useful.

Some challenges I ran into and/or things that I need to fix:

  • Syncing to the device: I'm still not convinced I've done this correctly, I think there are far more efficient ways of doing it, and there are bugs.. mostly to due with timezones.
  • Legacy Support: Even with ABS, and the Support Library from Google, dealing with older APIs is tough and resulted in functionality (mostly cool affects) being left out due to a lack of support in older OSs.
  • Testing: I love my Android, and you cannot convince me to switch away -- but testing 1,456,345,004 different phones and operating systems is tough
  • Design: The default design of Android UI elements is.. well, shit. So making things purty took a bit longer than I had hoped it would. That being said I'm quite happy with the result.
  • I've not quite figured out why it doesn't work on Android tablets yet :-/

If you are kind enough to download the app and try it out, you'll notice that its not focused on weddings (even though the design is kind of.. weddingy). My thought was that if I made it more broad I could use it for the holidays, sporting events, and random gatherings. This worked out surprisingly well as I used it for Christmas, New Years, parties at my house, and even an NFL game.

Over the next two months I'll be doing my best to make improvements (if you have any suggestions, or constructive criticism, feel free to shoot me an email at ryan [at] oursvp (dot) com) and ensure that the app will live through my wedding :)

Not so surprisingly many of the things I learned in creating this app have already been implemented in Science Exchange. It's always a great feeling when you create something as a chance to learn, and realize how much that new *thing* applies to applications you've already created. 

Shout out to Raphael Caixeta who whipped together the iPhone app for me, and to Eric Alli for the website design -- much appreciated guys!

Side Projects: Learning experience vs. Distraction

There seems to be a lot of confusion around side projects as more and more people are moving from 'corporate jobs' to start-ups. I made the move to start-ups nearly 5 years ago (after 2 years in a corporate job) because the idea of side projects to my employer was so foreign -- they thought for some reason they owned everything I created, at any time, ever (sorry, no). I learn by doing, as many people do. Side projects are an amazing way for someone to set an end goal and force themselves to learn a new technology, method, and/or to experiment.

With the number of tech start-ups increasing drastically faster than the number of engineers available, we've all started attempting to tap corporate talent. It seems as though, coming from outside the startup world, side projects are looked at as a distraction, and often get the "shouldn't you be working on ___" looks/comments.

Maybe its just where the line is drawn? I've heard many opinions on the topic, and I see a spectrum with two clear ends:

  • You build an app that never leaves your computer, and purely alleviates your own curiosity
  • You build an app that goes as far as being in a production environment, and accepts money from users

Personally, I have projects on both ends of the spectrum, and a few in various places in between. My typical thought process goes something like this:

  1. Find new (to me) technology that looks cool, and in some way useful
  2. Figure out a way to use that technology in very useless way (process log files, backup photos, send reminders)
  3. Look at what I've built, think through how it might work with an app in a more useful way
  4. Build a new application using what I learned. This allows me to implement the new tool without issues from existing code and allows me to understand a bit more of the intricacies and possible issues I'd run into if incorporated into a production application

Sometimes I stop at 2, sometimes I stop at 4, a few times I've gone further and implemented my newfound knowledge into the app I am "employed" to build.

Lastly, there are times that things I build in step 4 live on, and receive attention from me -- including updates and marketing. I have a few that I use for personal use and a few people have picked up so I keep live. There are others that I use for experimenting with marketing and user acquisition techniques including ads, emails, word of mouth, forums, etc., and sometimes I just think they are cool.

At the end of the day I have a single application that gets my attention, and the things I build, experiment with, promote, and use, are learning tools -- Science Exchange wouldn't be where it is today with out side projects (among other things). Engineers, how do you use side projects? Employers, how do you look at side projects?