Over the past few months, I’ve engaged in a series of quick strike efforts to spike up about a dozen or so mashup up ideas involving facebook, twitter, LinkedIn, Salesforce, Skype (among others), and the two mobile platforms (iOs and Android). I was given tight budgets, unreasonable deadlines, and asked to deliver not just functional Proof of Concept integrations, but products that would demo well and would wow the executive team. And I was told that failure was not an option.
What I have learned during these past months is, first of all, that there is nothing more clarifying to the mind than an impossible mission. Having to deliver quality on a tight budget and on tight deadlines is one of the hardest undertakings that one could tackle. In a real sense, you are defying the laws of physics: if you want quality fast, you need to pay for it; if you want quality cheap, you need to be patient; and if you want fast and cheap, you need to accept mediocre results. Pushing to achieve on all three axes is an extremely difficult proposition to fulfill.
During this heady period, I have learned A LOT about what it takes to execute. Harsh survival conditions help you boil things down to their essence — and do so mainly because you really don’t have time and can’t afford to put up with Bullshit. You need to smell the BS quickly, avoid it or get rid of it, and keep your focus on the deliverable.
The good news is that the lessons I have learned are directly transferrable to not only my regular day time job of Product Manager (where I deal with relatively more reasonable delivery roadmaps and adequate budgets), but to Life in general.
I want to share some of those lessons with you.
The first thing I did when I was given my first assignment early this year was to look up in the Sky supplicantly and reach out for the Cloud: not only in terms of technology (Amazon, Force.com, Godaddy, etc.), but also in terms of talent. I needed people with skill and energy who could work with my crazy timelines, but also people that I could afford. And so, I turned to some of the online development marketplace services, such as e-Lance, oDesk, vWorker, etc.
What I discovered astonished me: the depth and breadth of the “virtual” talent was beyond what I could have ever expected. People literally from all over the world, with every imaginable skill, are available to engage in projects as small as putting together a graphic for you, to as complex as a ready-for-the-App Store iPhone App and beyond. And, most importantly for my immediate needs, this talent was within striking distance of my budgets.
So, I must confess, that when the realization sunk in that I had access to all of this eager talent and that perhaps my missions were possible to deliver after all, I literally salivated.
But what happened next was no bed of roses. The laws of physics still applied, I discovered. Along the way, here are the lessons that I learned:
(1) Find People With the Right Skills
The projects that I have been engaged in have been short, 1-2 week projects, with a well defined mash-up idea, a small budget, and a specific deadline. Each one of the projects has required relatively specialized skills — or at least, has required, by necessity, that the people I engage needed to possess the required skills from the get go rather than learn them on the job (e.g., they needed to be very familiar with the facebook or twitter APIs). So, one of the first things I always do before hiring anyone, is to ask them very specific questions about their experience: Did they or did they not code against the API I want them to code against. When someone tells me that an API is an API and that they can code against any API, I move on to the next candidate. I ask them for references and examples of previous works – and I CONTACT those references and REVIEW their previous work.
(2) Pick People you can Communicate with Easily
Since I have no time repeating myself and I need people to get what I mean the first time I say it, in my initial interview I describe the project to them and watch how fast they grasp what I am telling them. If I find myself repeating myself on points that I feel are relatively obvious, I end the interview and move to the next one. Since most of my communications will be written (Skype Chat and Email), I look for people with strong writing skills — or strong enough that I don’t find myself spending time asking for clarifications. A key sign that has been useful to me is: are they comfortable with preposition based verbs — do they understand what “turn in,” “pan out,” “move up,” “carve out” mean? I am not saying they need to be experts on American idioms, but if someone is comfortable with them, you know that communication won’t be your biggest problem.
(3) Terminate Early and Cut Your Losses
One of the things I watch out for after I hire someone is: do they deliver according to specs. So, I usually start the project with a very specific initial deliverable that takes them a few hours to deliver. What I am looking for in that initial deliverable is whether or not they have delivered EXACTLY what I asked for. If I ask for a Restful Middleware API that takes 4 parameters with specific names that I provided and specific XML output when the API is invoked, is that what they delivered or did they deliver an API whose input parameters are things that the developer chose themselves? Same with the output: is it EXACTLY what I asked for or did they introduce “improvements” I didn’t ask for. If I don’t get exactly what I asked for, I terminate without further discussion.
(4) Be Clear about what you Want
Specs, Specs, Specs: you live and die by them. The more anally specific you are with them, the better EVERYTHING will be. This is so fundamentally obvious when you have no time to waste, but just as equally fundamental when you are not so strapped for time (or at least you think you are not). When I engage with someone who asks for clear specs, and complains about the specs not being clear and clean, I know I am dealing with a professional. If on the other hand, someone starts coding from my general conversations with them, I know have someone green: I appreciate their enthusiasm but their over-eagerness worries me. In such situations, move carefully and keep a watchful eye on progress.
(5) Provide the Larger Context
A mistake that I made early on was to confine my specs to exactly what I needed to be done without providing the people on the other side with the larger context. I did this mainly because I thought that the larger context would be distracting. The truth is that the more context you give, the better: where does their work fit in the larger picture of things? What is the larger picture? Why are we doing this in the first place? Why is it interesting and meaningful? Even when you are dealing with someone who will perhaps engage you just this one time for a few days, giving them the full picture is essential. Almost every time I have done so, they told me something that helped my project beyond the task at hand that I had set for them.
(6) Remember that you are Dealing with Human Beings
Which brings me to my next point: NEVER treat a human being as anything other than a HUMAN BEING. They may be somewhere distant and your encounter with them may be brief, but you are dealing not only with a human being, but probably a human being who is smarter than you. Be respectful and caring and don’t make unreasonable demands on them. Better yet, if you are satisfied with their work and they have exceeded your expectations, reward them by paying them a little more than the agreed upon amount. You will discover that 9 out of 10 times, they will appreciate your behavior and go the extra mile for you when you need them to.
(7) Are they Just about the Money?
By the same token, watch out for people whose only interest is the money at the end of the rainbow. For most of the people I have hired, the most important thing for them was delivering something good that met my needs. And they did this not only because they needed to ensure that I gave them good ratings when the project was done, but also because they had strong professional egos and could not stand it when I told them that I was not totally satisfied. Those who are about just the money will negotiate hard initially (which is not a bad thing as I indicated), but then will nickel and dime you for any little change you request. In such situations, what I have done is to push back just as hard if I thought that the requests were not fair, kept the contractor if the project was moving along satisfactorily, and then crossed them from my list of my go-to-people once the project was done.
(8) Do they Know How to Assess The Work?
And yet, I am equally wary of those who don’t negotiate hard for themselves. Sometimes it is because I am dealing with an Engineer who just doesn’t know how to negotiate (and there are many of them out there), but at other times it is a sign of something more than that, such as not having a good grasp of the magnitude of the problem at hand and what it will take to solve it. In the former case, I actually go the extra mile to make sure that I have settled on a fair price: there is nothing less pleasant to deal with than an engineer who feels that he was duped into doing more work than the money you are paying them to do it. But the latter case is the bigger problem: someone who does not know how to assess their work accurately, since it means that the possibility is real that they may miss your deadlines. What you are looking for is someone who can scope your needs, translate them to hours of work, and then give you a fair price that reflects the effort at hand.
(9) Always have a Back up
A lesson I have learned the hard way: NEVER have a single point of failure. First, you don’t want to be dead in the water should the contractor fail or disappear on you. And second, you don’t want to trap yourself by being at the mercy of ONE vendor. Always interview more than one candidate and have the second and third one in close proximity should you want to turn the project to them. Make sure that you have whatever artifacts that you paid for safely stored, and make sure that someone with skills equal to your contractor can relatively pick up from where the work was left off.
(10) Document, Document, Document
Which brings me to my last point: Document Everything, Damit! It’s the civilized thing to do! And I mean not just the code, but also the specs, the plans, the timelines, and keep a log of the important things that happened (should you need to reconstruct what transpired) along the way. This is something that I have believed in very strongly in my Day Time job as THE KEY to delivering excellence. I am not surprised that this is confirmed a thousand times over for the compressed projects that I have had to deliver.
Read Full Post »
bouzidthoughts 