bbrock

startups

I’ve been a worker bee with some team lead responsibilities at a startup. I’ve noticed trends in employees in that role. Startups have a feeling and culture that just doesn’t exist in other companies.

At one point, I worked in a tech support call center (about 10 employees) where 25% of the people previously did some kind of EMT-related work in ambulances. They dealt with customer emergencies more sanely than any other employees. If they were flustered, they kept working at the customer’s problem.

But employees often help coworkers with burnout. The savvier coworkers may do so preventatively rather than in reaction to signs of burnout. Also, there are often social events at a startup, some during the workday at key milestones. Those lead to employees seeing each other when they’re less stressed than during the workday, and provide crucial perspective.

In a startup, devotion to the company is more widespread. Folks at startups might hail from the same school, with similar ages and other demographics. If you’re growing a company, be sure to stop potential ageism and sexism before it becomes a larger issue. Personalities run strong and people tend to be driven. But more importantly, work is often treated competively as a contest of who can handle the most.

Don’t expect folks to stick around a startup forever. They may cash out when the company is bought, goes public, or grows even grows substantially. Those things all tend to alter a company’s culture to make it different from a startup. Also, employees might launch their own startups, possibly to be acquired by the company they left when both have grown. So pay attention to coworkers’ side projects.

You have to pay better attention to your health. Startups have longer hours, more stress, suspense, and unhealthy food and eating habits. Often the environment isn’t good – it’s a converted warehouse that’s still drafty and has an echo, it’s cramped, or its even temporary and changes quickly. Burnout and depression can affect employees outside of work. I’ve known several people who were divorced because they stayed at work late too much. Eat, drink, and sleep like those activities are bigger investments (they are) than the startup. Get some cardio. Make a stable routine. Take a real vacation every 6 months.

Some startups earn a reputation for valuing employee health or taking advantage of employees in unhealthy ways. I’ve seen a bad reputation like that sink a small business (web development, ISP) when it should have fluorished. Consider that interviews for places that promote employee health are often much more difficult places to land a job.
That higher retention of good employees is key to a company approaching profitability.

If the company sets the curve early in its life, it leads to some very sane HR practices. It also develops the skill of rapidly coming back up to speed after an absence.

Run it yourself.

I’ve worked on projects where one of the developers never ran their own code.  Never.  The results are obvious to everyone with 6 months of experience in QE.  It’s annoying and can come across as condescending.  Also it’s frighteningly naive.  That’s how segfaults during startup happen.  Or worse yet, entirely new features being completely or partially untested, if a developer is quiet about expected new output that QE never sees happen. So for the love of Kernighan & Ritchie, run your code just once as a smoke test before passing it along to the build process that ends in QA.

It doesn’t take very long. In QA it’s the first thing that I do, it’s just smoke testing at that point. Basically, determining if the build appear valid. By the time I’ve completed the part of integration testing covering the new features, I’ve spent 30 minutes setting up systems in a new configuration and 5 minutes testing. Many days I’ve tested something and the new feature immediately fails horribly, often badly enough that I can’t see how the feature worked at all.

It seriously helps to setup a test build system for pre-QA builds. It’s a couple of hours’ work once, and less than 10 to check out a build during development. It can save 1-2 hours / day for QA, frequently where the bottlenecks occur and at the most inconvenient time. I’ve seen software respin 3 times / day at various points, because of the lack of pre-QA smoke testing.

There are obvious ways to work around this in QA. They still require attention from QA, who will be logging the build’s status and initial smoke test results. It’s often a distraction from other testing in QA. I’ll cover that ground for QA in another article.