NoFeed ~ No Music for the Masses.

The good, the bad and the ugly of hiring a hacker for a startup.

2012-04-23T00:00:00-07:00

Lately I’ve been talking with a lot of startups: some with good ideas, some with bad ones, pretty much all of them with issues in their hiring process, which is very unfortunate. I never was under the impression that someone was trying to screw me up or doing something shady, I can generally say that it was (almost always) good people trying to make a good job for their companies.

This post is meant to help more than to criticize, different professions obviously carry a different sensitivity about some topics, and my guess is that most of the times these differences go unnoticed on the employer side but are like a punch in the face to the potential employee.

The Good.

Blondie - The Good.

Be friendly and informal.

If I take a job, especially a long term one, I'm not only choosing which project I'm going to develop for the next months, but also what kind of team I'm going to be part of. Being friendly and informal is a great start in every relationship, and work is no exception. I have communication skills as per your request, what about you?

Be honest.

Being nice is great, but please, be honest too. You're not only evaluating me, I'm doing the same with you. Ask me the questions you want to ask, speak your mind and do not act, never.

The situation is generally very good in this respect, the only time I had a very bad impression was with an in-house "technical recruiter" that just couldn't stop telling me how wonderful I was while in the meantime proving that she didn't even take the time to read my resume. Very unpleasant.

Down to earth.

I've been very pleased to see that entrepreneurs started being much more realistic than when I started dealing with startups (2005/2006), especially on the italian scene.

No more "you're a developer, you must sleep under your desk", but finally a helthier "don't work harder, work smarter". No more "they got funding so let's clone them", all the people I met is trying to build meaningful services that are worthy for consumers.

This was very refreshing and convinced me to concentrate on Italy much more than on the other countries, there is hope.

The Bad.

Angel Eyes - The Bad.

Drinking the kool aid.

This will always be a big problem in this industry, companies not having the slightest clue how to make money out of their projects. Maybe I'm unlucky, but I've never seen in my life a project like this not fading away in a way or another.

We all know that some projects have worked out very nicely for their founders without having a business model for years (Twitter and Instagram, I'm looking at you), but at least show me it's a matter of concern and not something more or less normal because "that's how startups work".

Again, maybe it's just me, but I don't know many ways that are more effective at killing my motivation than not getting any revenue from my work…

Asking for commitment.

If I work for you, I'm committed. I'm committed to the company, to the founders, to the idea. I chose you over the others.

Still, I'm not a believer. I think about what I do and I carefully choose between my options. Explicitly asking for commitment is a cheap shot. As a professional and as a person, it appears like you're asking for uncritical support, something you will never have from a decent professional and a decent person who is honestly committed to a project and want to see it work properly.

Careless over the tools.

I'm a crafter, I know and care about my tools. You want me in your technical team to help you choose the best tools, I've invested countless hours to be very good at it, and I take great pride out of my skills.

If you don't care about your tools, environment and development process, you don't need me, because that is exactly what I'm supposed to do.

On a side note, the next time I hear a comparison between programming languages and girls I will just step out of the office and go away. It's not blondes vs. brunettes, I can explain my technical choices without making stupid metaphors, you can't and that's why you need me. Being stupid and gross is a deal breaker.

Too much care over the tools.

You're very excited about RubyOnRails, Node.js, Erlang, Clojure, Bootstrap or whatever cool technology Techcrunch is mentioning right now. You also love using Basecamp, Asana, Optimizely or whatever cool tool the market has to offer and people is babbling about (on Techcrunch).

You already took every decision, apparently without knowing much about what you were doing or you wouldn't be trying to hire me.

Unfortunately, it doesn't seem there's much left to do here for me. Enjoy your buzzwords.

The Ugly.

Tuco Ramirez - The Ugly.

Remember my name.

Do I have to say anything else? Seriously, constantly calling me with another name is pretty bad, and not exactly for me but for you.

Respect my time as much as I respect yours.

This is both bad and ugly.

I had a company ask me for some sample code, literally disappear for two or three weeks, reappear just to schedule a call three times because it doesn't seem like they are able to manage their own time, give me a “been there done that” interview that could be done very easily by email, and then disappear.

I had another company asking me to refactor some very pointless code (mostly one-liners) and write specs for it, and then disappear.

This means first of all that if an interview doesn't go right I can't act on it: simply put, I have no idea what went wrong.

It also means that you don't value my time, which apparently is up for your indiscriminate use until you notice that for some reasons I'm not useful to you or your company anymore.

Other than saying again that I don't want to have anything to do with such companies, I must say that I'm deeply sorry for their employees. I hope you all find a better company very soon.

Developers and product managers are fundamental in the economy of a startup, when you hire, you want to do it right. These very simple points might be just a matter of common sense for a developer, but as I said, different professions carry different sensibilities.

Keeping these few points in mind would be a wonderful improvement already, at least when dealing with this developer.

Of foxes and bacon: an ode to _why.

2012-03-24T00:00:00-07:00

I wanted to write this post since I’ve read an article appeared on Slate about one of my heroes: _why the lucky stiff. The article is very thorough and enjoyable, it definitely worths a read, so if you don’t know who _why was and are for some inexplicable reasons interested in what I have to say, you should go there first.

One of the first things I did when I went to Seattle for the first time was hooking up with the local Ruby community. After a quick chat by email with a super-nice Ryan Davis I picked up my dev team of the time and went to Vivace Cafe. We’re talking about the end of 2008, more or less.

I’m not a community guy, I don’t like talking in public about “my stuff”, I’m an introvert, and that was a “no-no” situation for me: a room full of geeks with whom I share at least one interest (Ruby). In these situation, this is what happens in my head:

“Look, Ryan Davies and Eric Hodel, I read their blogs since forever. How many interesting informations I can gather from this lucky encounter. Let's just grab some beer and make stupid and inappropriate jokes now„

I started talking a little bit around about my project, losing the interest of most in a matter of seconds (and rightly so!) and torturing a poor guy that was too nice to just go away. After a while, following a discussion, I’ve started playing with Merb, going back to my natural environment: me, my Mac, something to do that involves a keyboard.

At that point I noticed a guy. He was alone, without a computer, a bit scrubby, drawing comics. I did what every self-respecting rubyst would do.

The joy of doing what makes you happy in the way you want.

Some foxes, rejoice!

It wasn’t him. It was a guy that was there since before I came, and has been sent away because the room was reserved.

My point is still valid, _why was a guy drawing stuff in a room full of developers. From time to time, he used Ruby to draw instead of a pencil.

Thinking about it, _why is a very strange and uncommon personality in our field.

One of the last personalities to emerge, for example, is Eric Ries, the father of the Lean Startup movement, which I covered not long ago. Eric came up with the core of his theory working for a startup called IMVU and writing about his discoveries on his blog. Soon enough a group of likely minded followers started to use those practices in their projects and document their success.

_why was different in the sense that he probably never wanted to be a so called “thought leader”, everything he did was for fun, for the joy of it, and directly for someone else. The poignant guide to Ruby and Hackety Hack were for teaching programming and having fun while learning. I’m also sure that he had a lot of fun writing all that stuff, at least as much fun as I had reading it.

I must say that I’ve always been surprised and admired about this. If it’s not fun, if it doesn’t give me joy, it’s not worth it. You want to build a web framework? Let’s keep it under 4 KB. You want to write a book about programming? Let’s fill it with comics and with a soundtrack.

What a sloppy sloppy sloppy boy.

Some castles and Dr. Cham!

_why’s code was sloppy. He was an amazing thinker, but not as good when it came to execution. So, he saw a lot of people take his ideas, and then build them out into more sustainable or workable projects.

If I put my programmer hat I can eventually agree with Mr. Vanderburg. Well, not as much as to call another programmer’s code “sloppy” in public with a journalist, but yeah, sometimes _why’s code was kinda difficult to understand and probably maintain. This is by no means an attack to Glenn Vanderburg, he is the person behind the whyday and obviously didn’t intend anything wrong.

On the other hand, I doubt that a web framework built to stay under 4 KB like camping was built with maintainability in mind. It was clearly a show off of skills to me.

I believe that we’re mixing _why’s motivations with out own here. He wanted to build something to have fun, to show some tricks, to “wow” people, and maybe to have fun watching people try to understand what the freck was happening in those 4 KB. Executable poetry, as the official mirror says.

I would like to build a company to see my own idea flourish and to help a business I care about and not to sell it to Facebook/Google like most: does this make me a sloppy entrepreneur? I don’t think so.

At this point, I’m convinced that _why was one of the main reasons, if not the main, to think that the Ruby community is nice. Yes, if you ask a question on ruby-talk it’s most likely the answers you will get will be super-nice, and Matz is probably one of the nicest guys in the industry. _why, on the other hand, was so uncommon and weirdly gentle to give a very strong example and leave a lasting impression. His way of approaching problems, taking always not immediately obvious paths, is something you can see all over the Ruby ecosystem.

Seppuku.

The porcupine is now at the sea.

I seriously couldn’t care less about _why’s real name. It’s just not an information I care about. I respect his wish to stay anonymous as something that doesn’t affect me in any way.

I believe his seppuku is definitely in line with the man - f*ck, I already spend most of my life thinking about software, I can’t keep whining about it when a guy that gave me so much just wants to go away.

I’m very grateful to _why as I’m grateful to a friend with whom I spent some good time, and then lost touch with.

If one day I’m in a local listening to a weird band singing about rabbits and lemonade I guess I will get a bottle of good Cabernet Sauvignon and send it to the band, but this is really it.

And thanks for all the fish.

Product management is dead. Long live product management.

2012-03-08T00:00:00-08:00

The role of a product manager in a startup has always been the one of the shaman. Normally you have one visionary (or worst, more) that explains his “vision”, and the shaman performs a ritual to enter the spirit world of good and bad features to tell the tribe what and how to execute.

It’s a very difficult job, the product manager is always the guy with more enemies in the company: just say no to someones idea, and you have a new one. And be prepared to the “you told me no 5 times already” argument, it will come up, and also to deal with internal politics very soon.

Having worked as a product manager myself, I felt the process and the idea as a whole was bad, all the experience of this world doesn’t give you a crystal ball.

The day product development died.

Eric Ries and “Lean Startups” represent for canonical product development wisdom what the meteor has been for dinosaurs. Nothing incredibly new, most of us used to do some (or most) of the things Eric devises since forever. For example, only an idiot wouldn’t measure the outcome of a new feature, or not gather all the feedback he can from customers.

What we never had was a common and shared framework to manage our work and dramatically reduce waste. What I hope will happen for product development is that it will be somewhat standardized in a set of practices that are recognized by the industry, in fact removing every temptation to guess.

How does it work?

The lean startup cycle.

What is a product? A product is an assumption. You think that some people need something, and that something is what you need to build. For Lean Startup proponents, this is when you build an Minimal Viable Product, which is the bare minimum product you can build to test your assumption and nothing else.

Before	After
Someone thinks some people need something, you build a full featured product that responds to that need.	Someone thinks people need something, you build an MVP to know if it's true.

Quite a jump, isn’t it? This has very deep implications on the whole project. Nobody likes to kill his own darlings, but here we have a process that does just that and is meant from the very beginning to validate every step you make in the development of a product.

Now that you have your MVP you must, in fact, validate it. This is where things get really interesting and fascinating: the point of Lean Startups is to build a company that lets you learn by introducing the concept of validated learning.

To make it simpler, your MVP must be measurable, and the unit of measurement is validated learning. This part should be well known to product managers, you use metrics like a/b tests, time on page, face to face interviews and many other metrics, to learn how to improve what you just built. What’s different is the context a product manager is moving in, normally we build something because we believe that it’s somewhat needed, and if data tells us the contrary it’s an implementation problem. Lean startups take a wider approach by questioning the existence of the feature itself and it’s usefulness for the customer/market the product is serving, and this changes significantly the way an interview is conducted or data interpreted.

Before	After
A product/feature is built to follow a "vision".	A question is made through a product/feature to learn how to serve a market.

At this point you should have plenty of feedback and data to make an informed decision about your product. If you like your data you just move on to the next feature and start the process from the beginning. If you don’t and the market response was bad, you can pivot.

As recently happened to me the market response was really bad, and I indeed learned a lot in the process. I can now isolate the problem rather easily and pivot another solution for serving the same market much better than before - this is what will happen to StyleJam anyway, we will release a different barebones product sooner or later to validate the concept, under a different name.

I obviously only scratched the surface of what really is the Lean Startup process, but I think that the point that product management must radically change to survive is pretty clear. As always happens, revolutions don’t happen through a radical change of the tools or basic concepts, but through a radical change of perspective.

Product managers, face it, you might be wrong, embrace the change and reduce waste.

If you want to know more, Eric Ries just published a book. Another book you might be interested in is Ash Maurya’s book. The main difference between the two is that tha latter is more in the form of a manual, while the first is more an explanation of the concepts (with plenty of very interesting examples). I honestly can’t give an advice here, I loved both and both are on my desk right now.

Let’s talk about us…

Eric Ries, pioneer of the lean startup movement.

My guess is that soon enough knowing in detail the Lean Startup process will be a required skill for everybody who cares about product development. If I had to hire a product manager tomorrow, I know for sure that I would ask his familiarity and experience with it.

At the end, as most of you probably already noticed, the Lean Startup process has many things in common with the Agile Software Development methodology, and I believe it will have the same success (hopefully in less time). As with Agile, there’s no magic tool to solve all problems, but only a set of practices to remove risk.

I strongly suggest to start from Eric’s book today (there’s a Kindle version too) and embrace change. It works, trust me.

The world will end in 2012: I fucked up.

2012-02-22T00:00:00-08:00

StyleJam is closing down. It’s closing down mainly because of my poor management. Don’t worry, it’s ok, that was my first startup and I never bought the “open a company - magic happens - you’re Zuck” loop. Shit happens.

I still managed to learn something out of what happened, and I’ll gladly share it with everyone else. I don’t think that what I’m going to write is that original or interesting, but I decided to leave the classic “note to myself” in order to, at least, move to a different set of mistakes with my next adventure without repeating the old ones.

For clarity: StyleJam was a platform web designers could use to host their portfolios. The “cool” thing about it is that the only thing we did was generating the HTML with the data the designer provided, and then let him be completely free when styling it by uploading his own CSS and images. It was some kind of CSSZenGarden on steroids.

Do stuff people need.

First thing first, the main reason StyleJam went down was that it was unneeded. I discovered that as soon as mid November of last year, after talking with a good amount of web designers.

Someone might think that discovering something like this 2 months after release is incredibly stupid. I must agree with that.

I started conducting interviews before writing the first line of code, unfortunately I did that through my ego. Asking about a problem and being sure about the solution is a very very very bad idea.

The main thing that should have started ringing every kind of alarm bell was that during the interviews StyleJam was incredibly cool, but always for someone else. UX people said it was great for web developers, web developers said it was great for UX people. Older web designers told me it was wonderful for younger ones, younger ones didn’t want to compete with older ones. A guy I highly respect told me he wanted to be in control of everything, but that it was good for the vast majority who didn’t.

If you want an interview to be useful, you’re going to need personal direct commitment, not a guess. I’m very thankful to the people I interviewed, they would have been very helpful if I actually read and understood what they were telling me.

Refuse the temptation to be cool.

One of the things that struck me the most in this whole adventure was the fact that I’ve been completely unable to reduce the product to its minimal terms. I kept concentrating on the how, and ignored the why.

If you reduce StyleJam to its minimal terms what you have is a lesser Behance. Yes, designers could have appreciated the fact that they were actually using their real skills to produce their own portfolios instead of only uploading a ton of screenshots, but what are the real benefits?

When we discussed internally the whole idea it was “hey, then it will be pretty much like a real website isn’t it? It will be some kind of useful CSSZenGarden!”. The fact I love CSS and design and the fact that it was super cool to have a platform based on CSS completely blindfolded me.

It’s quite embarassing now, but web designers tend to make websites, and this makes the whole proposition a moot point. Hey, I make websites for a living, what a wonderful platform we have here that makes me do what I already do 24/7. Gosh.

Add to this a very steep learning curve and you have a recipe for disaster.

Here I must really thank Andy Rutledge for pointing that out when asked to be one of our advisors. Unfortunately I had to learn it the hard way. Andy, once again, you were right. We didn’t have any disagreement for what it worths, I was in love and you told me my girlfriend was cheating on me.

Bottom line: be useful, not cool.

Be evil.

Sorry people, but I must admit: being nice and patient definitely doesn’t pay off. Not even close.

I had one iteration available without even knowing it, just because I trusted the wrong people. I have no knowledge of any startup that succeeded at the first try: I am not using Twitter through SMS, I’m not looking at “thefacebook” because I’m a student, and I’m not playing Flickr.

If everybody that had to give me a service actually did it, or if everybody that actually had to work on the project really worked, I would maybe be telling a different story. Unfortunately there’s a good and nice guy under this BOFH shell, and I avoided contrast at all costs. I was wrong, if you want to make a business you have to become a businessman. Most important: friendship is a two way relationship - once I will get it, I promise.

Once again, talk is very cheap: you want personal and direct commitment, and you want it by facts, not chitchat.

I don’t say this because ”I’ve been screwed”, I was the CEO and I had to make it happen. I say this because if you don’t insist and you don’t pretend people to deliver what they promised you’re hurting yourself, your company, your investors, and making your startup’s environment very unhealthy and unpleasant.

Beware of shortcuts.

In the web design industry there are a lot of important personalities, and one of my strategies included offering shares to one of these gurus in exchange of some advisory.

Doing something like that is rather normal, my mistake was relying way too much on this people, especially after discovering that most of them are, ^cough^, a little bit volatile.

In the best case, a discussion was started and after a while the guy just stopped answering. I mean, seriously, like you’re talking with someone and suddenly he drops down dead. Impolite, a little bit childish, but still more or less normal.

What’s weird is when one of these guys actually accepted to be my advisor, I paid a lawyer to give him shares, I told my team and my investors, and again, he completely disappeared. I’m not going to say who it was, just trust me, big big name. He didn’t even answer to a “Merry Christmas” email. And before you ask, we’re talking about at most 6 emails in 6 months, I definitely wasn’t bugging him all day long. I’m not whining about him changing his mind, I just think that it’s very bad not telling me. Ok, you changed your mind, it’s not like I’m going to do something or be angry, it happens. Just tell me.

Do not rely on shortcuts, as I already said, talk is cheap, lots of people is willing to jump on the winner’s bandwagon, not many are willing to do the work, even if it’s only answering a couple of emails or telling a bunch of friends about you.

This is it, all my mistakes on a single page, for future reference and in all its shame. I hope it’s of some help for who’s starting right now, and I also hope it will be useful for me in the future.