All right stop.
Collaborate and listen.
Yes, I’m crazy enough to work for a startup. And let me tell you, there’s no easy task when it comes to building a new business. However, at the expense of pissing off the boss, I’m just going to come out and say it: The most difficult part of all is keeping pace on the technical side.
Yup, you got it right: I manage that side — project development.
I work for OpiaTalk, which was very ambitious from the beginning. We were “simply” working to disrupt eCommerce. We harness consumer psychology to help retailers dramatically lift site conversion and increase AOV, and we use a hyper-conversion widget to do it. I’m one of those building the core technology, and it has been a crazy ride — crazy, but successful.
How were we able to shift gears and adjust rapidly? How was it possible to beta test with small retailers and quickly scale up to some huge, high-volume, very demanding SLA eCommerce sites seamlessly?
In a rapidly changing environment, you can’t think of lengthy features. You just can’t. Lengthy features are guaranteed to change before they even make it to production, which means everything must be sliced thin.
Direction has to be evaluated on a daily basis. You can choose whatever agile process fits you the best at that time, but the important thing is to keep it simple (as simple as possible, when possible), keep it small, and keep it fast – of course without compromising quality.
Moving quickly doesn’t mean running blindly. Before making any dramatic changes, stop and take a few minutes to think. Is there a better way to achieve the same goal? Will it interfere with other requirements? What could go wrong? Is it worth the effort?
Don’t be afraid to challenge requirements coming from the business side. Don’t be afraid to speak up. You’re valuable because of your technical expertise; don’t hide it. Evaluate alternatives. Evaluate risks. Evaluate ROI. Looking good? Go!
This is probably the most important one. In a true startup, there are no separate sales, financial, operations, and development teams. There’s just one team, with one goal.
Always make sure the development team has deep insight into the business ecosystem as a whole, and vice versa. This is what separates good developers from the ninjas. This is what will make a difference when things go south and you really need to rely on your team. So ask the questions that go beyond execution. Your goal should be to really listen and understand the business overall, then support that.
[At this point I wish Vanilla Ice‘s wisdom would have gone further to make this article perfect, but I’ll have to continue rapping myself.]
You’ve learned to slice. That means that now, if direction shifts, you should feel no shame or guilt over discarding whatever slice of the application was implemented. That’s right: There’s nothing bad about throwing some code in the trash. Actually, being willing to let go reflects how fearless the team is in adjusting to business needs.
Things are going to change; it’s not a matter of if, it’s when. You just need to be prepared and know how to react. The leaner you get, the better.
Don’t over-architect, but keep scaling considerations very closely in mind – this will have a tremendous impact on the business. Yes, it’s important to keep things lean (avoid thinking about conditions that are not actually required in that moment). But you never want to find yourself in a position where you need to scale and can’t. Delaying will affect the business – you’ll have to reject sales or risk a very bad experience. When the time comes to scale up, you want to have done your homework to make it possible.
For example, in our case clustering and stress testing seemed like a waste of money while we were working with small sites (100 uniques/day). Then we landed Skype, and it was all worth it. It was a smart investment in our technological resources to make sure we’d be able to handle large retailers. We knew what we wanted and where we were headed, so we prepped for it.
The most important thing when it comes to successfully managing development projects for startups is flexibility. As humans, we like to settle into routines. We like to know what to expect and what’s next.
But with startup life, that’s not always possible. In fact, it’s not even likely. And when you expect change, it makes it easier. It switches your mindset to know that this is what we’re working on right now because it’s the most important thing, but that could change tomorrow.
Constantly evaluating what’s truly important is actually the best way to build, even if it’s stressful or frustrating. What will make the biggest impact in the immediate short-term, while still keeping the big picture in mind?
That’s the question, and the answer should be — you guessed it — flexible.