Follow posts tagged #tech tuesday in seconds.

Tech Tuesday: Security in Startups

Last week in Tech Tuesday I asked for topics to write about in my series on technology in startups. There seemed to be a fair bit of interest in security, so here we go. First off a disclaimer. As with any general purpose advice, you need to think a lot about what it is you are trying to do. The security requirements for a bitcoin startup are vastly different from those for a social media one.

When you are just getting going you should treat security the same way as scalability: make sure you have the basics covered but don’t spend too much time on it as your bigger problem is to build something that people actually want to use. Again, please keep the disclaimer from above in mind though!

As it turns out even the basics still seem harder than they should for a lot of folks. Here is what I consider to be included: hashed paswords, SSL for all logged in users, safeguards against SQL injection and cross site scripting attacks, two factor auth or VPN requirement for web based site administration, key based auth for all server access (and limit dramatically who has server access), disciplined access to all cloud services.

One way to get a lot of the basics is through widely used web development frameworks. That comes with a *very* important caveat. Because those frameworks are widely used lots of people are looking for exploits and when a zero-day exploit is found you will be vulnerable and you *must* apply all security patches immediately and generally stay up to date with the framework.

For managing coud services access there are two promising startups: Meldium and Bitium. These are both relatively young and so might turn out to have their own security issues but they are a lot better than emailing cloud services passwords around or keeping them in Google Docs which is what a lot of startups are doing right now.

Bottom line: when you are just getting going be pragmatic and focus on the must have items. Once you start to grow though make sure not to neglect security — you will need to upgrade as you scale.

Tech Tuesday: Remote Engineers

I have been writing the last couple of Tech Tuesdays about hiring and retaining engineers. One of the questions that comes up a lot in that context is what to do about people who are in other locations. Is it a good idea to have remote engineers? There are people who seem to have near religious believes about this ranging from it can never work to it being the only thing to get anything done.

In practice I have found that pretty much anything can work if you support it with the right culture and systems. I have seen both success and failure with entirely distributed teams (everyone is remote) and with entirely centralized teams. So what do you need to do if you have some remote engineers? Much of the following applies to whether they work individually from home or from a satellite office.

You need to invest heavily in communication. Having some kind of realtime channel seems to help a lot and IRC still appears to be the best way to do that. But in addition to realtime you also need to spend time on communicating company strategy, goals, values.

Having people come and visit so that they can meet in person at least once in a while also makes a big difference. There is some sense of being connected that comes from having met someone in person that is still quite difficult to establish purely online.

It is very difficult to handle remote engineers (or remote employees of any kind for that matter) if you have a face time culture where being in the office for long hours is how performance is judged. In order to make remote work you have to have good systems for tracking progress and measuring individual productivity.

The one thing to be super careful about is to avoid any us vs. them mentality emerging. If there is any sign of that whether between two offices or between office and remote employees you need to get to the bottom of it immediately. That can become very corrosive quickly and hard to recover from if it goes on for some time.

Finally, not everyone is good at working remotely. Some people need the structure of an office environment. Others need the in person social interactions. So if you recruit someone to work remotely make sure there are some indications in their personality or history that this will be a good fit for them.

I would love to hear from readers what has worked or not for them in having remote engineers or a second office.

PS Speaking of hiring engineers, Ziggeo is also looking for engineering summer interns.