Tweet

• February 24, 2009
• By Photis Patriotis
• 6 Comments

When I first started at Brazen Careerist, I was used to working at a large company with a large budget (i.e. buying two servers for everything so the failure rates go down to something like 0.0001% from 0.1%). At a start-up, you can’t exactly do that; you can’t rely on $10-100k/year support contracts, but you have to be able to spend or save strategically and with good timing. I read over and over that one of the biggest advantages of a start-up is agility. Being able to thoughtfully adjust your start-up’s development group as your company grows its user base, gains or loses its ability to spend money, and manages the features available for its users is crucial. My post today is about the growth phase, I will address contraction next week.

Part I: Expansion at Brazen Careerist

Do you have growth potential?

When I decided to move to Madison and really start working on Brazen Careerist full time, we had just received a seed round and already had plans for what type of software we were going to be working on. The scope for the ideas floating around was huge, such as building entire blogging platforms and creating systems to handle a large user base, but we also had the money to back these ideas up. I knew that we were going to be needing a lot more development help. So, in-between making regular updates to the site, I started preparing for the influx of programmers/architects/testers/designers that would be walking through the door any day.

Determine what your standard tools are and set them up

As a manager, it’s absolutely necessary to have all of your tools and systems in place in an organized fashion so that when the people actually come, everyone can work the same way and talk the same language.

Every developer needs a playground, so I bought a development server. All of my non-production environments are hosted on this, development, alpha-testing, beta-testing, etc., and everyone logs in the same way throughout the server for these environments.

I’m also a strong believer in using an IDE for development, especially when you’re writing code 8-10 hours a day; Eclipse is a great choice for PHP and Drupal development. Now you can have a contractor or developer set up, working, and following your standards within 30 minutes. This environment should also support a moderate number of developers (1 to 4) and a fair number of testers (10 to 30).

Engage the local development community

Just as important as systems preparation, engaging the local community of developers is vital for the growth of your team. Being new to Madison, this was a small challenge, but one that you must face and overcome quickly. Two days after we decided we were going to use the Drupal platform, I had already signed up to attend Madison’s Drupal Users Group. Within weeks I was attending Bar Camps, local web group meetings (web608), and meeting a ton of people that were involved in web development and social media.

Madison amazed me in this respect, but these groups exist all over the U.S. and are great places to network, even if you don’t have time to go for every single meeting. I now had a diverse network of talented people that I have called back on time and again for consulting work, full-time employment, and even just regular idea exchanges.

Create standards and manage change

After having any more than three people involved in making changes to your site, it is absolutely imperative that all of the changes made to the live site are managed. This task is even more important if you already have a live site cannot afford to have your entire userbase be affected by poor roll-outs and buggy features. Scheduling and budgetting also start becoming more and more important when there is more money on the line.

Keeping strict versions of the software is a start. These versions should not only be imprinted in the brains of the developers, but also the sales, marketing, community mangers, and executive leaders in your business. At Brazen Careerist, once we determined what goes into a certain version number, it makes communication much easier to discuss and no one is surprised when the product actually goes live.

Alpha and Beta: these words get thrown around a lot nowadays, but when rolling out reliable sites, it’s all about the testing. Alpha Testing = testing done by internal employees. Beta Testing = testing done by third parties. Unless you have a user base in the single digits, both of these are required for almost every deployment (except emergency bug fixes). At Brazen, our community manager must also be very involved because he’s the one that brings in the beta testers. Hold developers and testers accountable for making sure these phases are done, because YOU are accountable when it goes live.