13 Tips for a New Software Start-Up

I was lucky enough to be the Co-Founder/VP Engineering, then CTO of a great start-up. Great in so many aspects:

Great partners
Fun, intelligent, hard-working team
Customer-driven product vision
Successful product deliveries
Supportive Board
Happy, loyal customers

The best job I ever had!

What tips would I give to new software start-up entrepreneurs about Do’s and Don’ts for software start-ups?

Jan’s 13 Tips:

Pick your partners/executives well. Co-founders and/or executive team needs the same vision and priorities and ideals. The team needs to trust the leaders and the leaders need to trust the team. Management needs to talk the talk AND walk the walk.
People, people, people. Hire smart, hard-working engineers. I quickly recruited key engineers plus found a local company to provide consultants for a quicker ramp-up. If someone isn’t working out, do the hard thing that’s right for the rest of the team. Make the cut. This can be really, really tough and we all want to make it work out, particularly for nice, eager folks. But in a really small team, everyone needs to ramp up quickly and contribute.
Don’t Over-hire. This one didn’t seem intuitive to me at first but worked extremely well for us. Our CEO had the belief that it’s human nature for people to always find work to fill their day. No one in a start-up is ever “not busy” – but are they busy on the right tasks? Another way to look at it is “focus”. If there are “just enough” people, then only the important tasks are done, instead of a lot of non-essential activity. In a start-up, non-essential personnel could include managers who aren’t hands-on part of the time, project managers there just to track status, IT resources, etc. Instead, initially hire for the key spots: Sales/Marketing, hands-on Engineers (including somebody that will also manage), one Finance guy (unless the CEO is also an MBA then they cover it). When the product is ready to be released, add services people, IT, Finance, and someone at the front desk.
Keep the software team co-located. Nothing is as distracting to a small software team as trying to establish a remote, off-shoring facility. Team focus is extremely important.
Focus on delivering what the customer wants. If you’re lucky, you’ll have what we had – early employees who had worked in our target business area that were smart and knew exactly what the customers wanted. If not, find those people – they are key to your team. We built a prototype. Showed it to perpective clients. Got feedback. Updated the prototype. On the day we officially formed the company, we had a robust prototype (HTML screens and flow) plus our first customer and $1 million from Angel investors (most of whom were also from our target business area).
Focus on delivering what the customer needs. If you’re building the software, also think about all of the aspects of the product including how the IT managers will want to customize it, install it, take releases. Plan for that up-front in the way the software is architected and built. We did this in the first release through business properties so the clients could change business policies to match their needs. Also the code read from resource files that contained every word displayed on the screen, including error messages (I highly recommend all software be designed this way) so the clients can use their own terminology easily or even localize to different languages. Later we added a GUI configurator. The easy installer was built in an early release. The upgradability was part of the development thought-process. If you’re building software that needs to be installed and upgraded, this is key. If you’re building cloud software then you’ll obviously need to have easy configuration, install and upgrade tools. And plan for global users – review how “time” affects your application and if important (e.g., contract start/expire timestamps) convert to UTC/GMT global time and build functions to handle time appropriately/consistently.
Pick the right architect. Monitor initial concepts and progress and pick as the key architect the engineer with the best sense of a clean and simple design, regardless of whether he had the most experience or was your initial architect candidate. The right architect is key to product success!
Keep it simple. Don’t try to build an architecture that will be everything to everyone – build what you need. Refactor as you go along if necessary to keep the code clean and efficient. A simple framework will be quicker to develop new features on, more reliable, and more maintainable.
Don’t be afraid to build it. Your CEO may say to buy, lease, integrate but for a small company if it keeps things simple to build, keep it simple. Originally we used a 3rd party object-to-relational layer. The night before a major demo it failed. If two people clicked the same button at the same time on their separate browsers, kaboom! We limped through the demo by having copies of the app running on each training system instead of the normal browser configuration. Our architect had, for fun, built a layer for his own use and we quickly migrated to that. It was exactly right for our needs. Simple, clean, just enough. Someone years later asked me if I were to do it again if I wouldn’t use Hyperion, said he would. “Better to buy than build. Better for the engineers resumes,” he said. No, I’d do it exactly the same way but start with the build, not buy version. There are exceptions – I wouldn’t build my own relational database, Java compiler, charting package, etc. But I’m not one for adding tens of thousands of external library files to my release “just in case” one of the handy, dandy tools comes in useful. Keep it simple.
Implement a Practical Software Process and Tools. Choose a software process and tools that are simple and streamlined while you’re small but that can grow and support a scaling business model. Our recommendation is one tool that handles your key process (e.g., Agile story management, task tracking) and provides on-line automated spec viewing.
Focus on quality. Fix the bugs as they are found. Use a quick, iterative method for ongoing maintenance releases. The only bugs that should not be fixed ASAP are ones that are found internally due to some weird, illogical path through the software or that are so small and cosmetic no one will notice them. DO fix even small bugs that are cosmetic if they are visible on the screen (typos, etc.) as they detract from the professionalism of the software. To streamline the process, use a good bug tracker tool. Have a cross-functional team meet weekly to review new bug reports and keep the funnel flowing. We called it our SDRB (Software Design Review Board). In the early years the head of each cross-functional group would attend, including the CEO (who was also Product Marketing). As we grew the QA Director was the lead but still heads of each org attended: Director of Customer Support, VP Engineering, VP Product Marketing, etc. The top person would attend (if in town), else his/her delegate, so decisions could be made at that meeting and each new bug report allocated to the appropriate release. That way, bug reports and client issues don’t get revisited again and again but are reviewed and assigned to the right delivery timeframe once, promptly.
Focus on application speed, performance. Performance is an extremely important aspect of quality. At Ford Motor, when they built CAD/CAM systems internally for their car designers, they found that more than a second delay in when the designer clicked the light pen to when the screen responded would cause the designer to lose focus and made the tool less effective. Screens must be blazingly fast. Anything taking more than a few seconds needs to give the user the option to “click refresh” or go elsewhere to do work while the screen completes (not hold the user hostage until the processing is done).
Lucky # 13 – Work hard but have fun. We had off-sites. Most importantly, we worked to be sure that everyone, even our Indian consultants would attend them. So the entire team became a close-knit group and everyone was treated with respect. We had yearly “Star Wars”, then “The Matrix” movie outings where our CEO handed out hot dogs and popcorn. Make “fun” part of the culture, part of the daily dynamic. The engineering group had fun with humorous email comments (always respectful but cute). As a manager, play along, encourage it. Don’t be stuffy. We added ‘quotable quotes’ to our bug tracker tool so every time someone submitted a new bug or enhancement request, they saw a random quote. Something someone had said but taken out of context and therefore very hilarious to all of us. At cross-functional meetings when someone says something that can be misconstrued, someone will say “Ahah! Quotable quote.” and it will end up in the system. The more a team is willing to be playful, it shows they trust and respect each other.

As another example, decorating the cubes when someone goes away on vacation. My favorite: The engineers were going to nail a big piece of plywood over our Dev Manager’s office door when he went on vacation but I said “No nail holes in the building!” (We were leasing after all.) Just then our CEO came up and saw what the engineers were about to do. “Wait a minute.” he said and darted away. He returned with his power drill. “We need this! Nails won’t do,” and proceeded to tightly drill, screw, and seal the plywood over the doorway. Gary sure had trouble getting into his office when he returned 🙂

Of course, the fun is part two – the tip is “Work Hard” THEN have fun.