Written by: Chandrika Pasricha
25/02/2016
4 minutes read
![eye]()
232
![share]()
3shares
I’m a non-techie founder of a technology startup. At the time I started (Flexing It was launched in late 2012) I didn’t have a tech co-founder and it proved difficult to find the right match. At the same time, it was hard to get quality senior tech talent in an environment where demand was skyrocketing. Hiring coders with lesser experience were too risky. As a solution in early days, I opted to outsource technology to a strategic partner who became our outsourced technology team. They worked with our core team on the product’s evolution and owned the maintenance of the online marketplace platform we run.
Though a technology partnership has worked well for us this past year, there have been a lot (and ongoing!) learnings about managing tech when its core to your business but you are a non-techie. Here are 5 Mantras that worked for me:
#1. Think through the product choices carefully and in detail.
There will always be more features we want to implement than we have a capacity for – these may be improvements that will help current clients, new additions to the product or tools we need for a marketing campaign. Before handing a laundry list to the Product Manager to coordinate with the tech folks, it’s critical to have an internal discussion on what each change means in detail, how important it is to do now, whether it’s a small change or a big upgrade that needs time. We follow a simple A/B/C format to prioritize the most important requirements from a business stand-point so that the Product and tech team can keep that in mind as they estimate and plan.
#2. Rely on good old project management principles i.e., break-up into releases, manage deadlines, hold people accountable.
This sounds really simple but is crucial. After an initial period of haziness, we have settled into a rhythm of 3-week releases that everyone has bought into, and we typically try and have a broad line-of-sight for the 2 releases after as well in broad terms. This helps the team know what’s planned for when, and think through marketing and social media campaigns accordingly.
#3. Think as users and not just of technical implementation.
This again is the responsibility of the ‘business’ side as the technology folks will think in terms of implementation. We need to add the layer of extrapolating how it will work for the planned set of users and is the current spec enough. This step is probably most crucial while testing, as my experience is we always underestimate the time we need to test, and more importantly do not think ahead of time as to how we will test ‘functionality’ vs. ‘whether the feature works technically’.
#4. Test offline before coding no matter how painful.
Again this has been a lesson learned the hard way – while testing will always throw up bugs or improvements, the major issues can often be identified beforehand though may mean hard work. When we launched our skill matching algorithm FlexScore™, that uses a proprietary intelligent heuristic to match consultants to projects, it had multiple parameters, each with its own importance in the overall algorithm. While we had tested this for projects of different types before we finalized the algorithm we saved the really complete and detailed testing for once it had been coded - on the assumption that it would be easier (algo calculated vs. us having to do it in excel!). Unsurprisingly, in retrospect, this led to a delay in the launch as the testing yielded important tweak. Some of the changes were simple but some required a coding overhaul which made everyone unhappy!
#5. Always ask WHY, even if you won’t fully understand the answer.
I cannot stress this enough – I was taught this in management consulting school and it holds true here too. Whether it’s when you feel a feature implementation is taking longer than it should or cannot be implemented in a certain way, ask ‘why’ and look into the task break-up associated with it. More often than not one can find a solution or an alternative.
232
3shares
