For 4 years now, I've been the solo developer for a small company. We have a handful of well establish products in a niche industry. We will be hiring 1-2 developers soon, and that will likely change the way things operate around here.

While I won't have a "real" title, I will be "in charge" of this team. What I want to do is establish a very organized and productive programming department for my company. I got this solo job right out of college, so while I've become proficient as a programmer in this industry, I lack a lot of team programming experience. I feel that starting out on the right foot will be key.

Right now it's just me, a few computers, and an SVN server. I'm looking for any general guidance on building a team from the ground up.

  • One thing lacking in the otherwise good answers is thus: instructions on how new developers will setup their new development environment. E.g. get this SDK, install that IDE, install FooTest, setup YourSQL client, get these build scripts and put them here, configure NPM or pip or Maven, or Webpack or whatever... You should create a first draft, then let your first hire test it out and edit. – user949300 Dec 27 '17 at 20:22

Get your house in order and ensure that things are setup for a collaborative effort.

  • Version Control - You mentioned that you already have an SVN server, which is great. Make sure that you have established the repo and organized the projects in a standardized way.
  • Automated Builds
  • Issue/Bug tracking software
  • Unit/Integration tests
  • Continuous Integration server

Having the following items setup and integrated into your development process makes it much easier to bring people on board, track what is being done, and keep things from getting "messy".

  • While all the answers to this question are great, this one is closest to what I'm looking for. Thanks Mads. – bufferz Nov 1 '10 at 16:07
  • I have one I would suggest adding: Code Review. It will help new people learn the system, help you understand the new contributions, and can make everyone a better programmer. Set up the system with the right tool and the mindset that it isn't adversarial but a tool for learning, improvement, and clarification. – BrianH Jan 24 '14 at 18:08
  • Also a wiki. And get used to very short feedback loops. Commits will happen every five minutes, you will get merge conflicts. You will need to coordinate bigger refactorings. And don't be afraid of letting go when others pick up speed, but do have reviews and ddo pair programming to avoid diverging. Oh, and set clear goals. – Alexander Torstling Jan 25 '14 at 11:27
  • When thinking about it, I think its best to have someone more experienced showing you the way. Solo coding and team coding are so different, and the methods that do work might be very counter-intuitive for a solioist. – Alexander Torstling Jan 25 '14 at 11:29

hire someone a lot more competent than you

... and with experience in large enterprise software project.

They will help you industrialize your processes and you will probably learn a lot from them.

You will teach them your niche market.

If you can't find such a person, I suggest you to go to trainings related to team management. I suggest you a Scrum Certification as a starter.


It may be obvious, but make sure you think you'll actually like working with the new hires. Try to arrange for a couple of beers when they both start to try and get the team to feel like one.

You'll also need to make them aware of any coding standards you follow and any common techinques you use, common as in repeated in your code base.

Eventually you should all be able to feed back into the process and improve... assuming you follow other advise and hire someone with the skills to complement yours.


Lacking a real title, I will be "in charge" of this team.

Don't make the mistake of letting your desire / ambition to be "in charge" get in the way. If your company hires developers with more experience than you, the new hires may be a lot more suited to the team leader role than you are.

Your real value to the team and the company is your intimate knowledge of the products as currently implemented.


This is very similar to the situation I was in a few months ago. The best advice I can give is drop the typical hubris of being a programmer and hire the best of the best your company can afford.

I was "in charge" for a while, but a team member with more experience stepped up and I gladly relinquished my administrative duties so I could do what I'm best at, writing quality code. I'm still a mentor to the team as you will be.

If you do what's best for the company in this situation, you will be rewarded.


There are going to be heated technical discussions: new programmers have a bias, they have experienced a few ways to do things and when confronted with a new way that they don't understand, they'll first think it makes no sense and needs changing. Programmers who have worked on their own for years are likely to be defensive about their work, and also their work will be somewhat idiosyncratic, because of the number of problems they've solved without discussing things with other people.

Be aware of those biases, welcome the fresh input, don't be too defensive and don't make rash decisions to change everything either.

There are many good sides to working in a team, especially getting your code reviewed by a colleague. Insist on that for all team members including yourself from the start.


As the senior developer you will need manager hat on and start looking at your company's hr policies. (especially items such as holiday entitlement, sick leave procedures and disciplinary process although I hope you will never need it)

Now depending on the new hires skills and ability start delegating some aspects of your current work, you will need the time for managing priorities and scheduling.

One good source of simple and basic management skills on what to do and how in a professional manner is http://www.manager-tools.com. They do regular podcasts on management and career advice, not to mention a sizeable back catalog of material for you.


A lot of the tips provided are excellent, I would just add a few from my experience in a similar position.

  1. Get involved in the hiring decisions and don't be afraid to veto candidates that are not . You'll need to work closely with the team and they'll represent your to your clients and to management.
  2. Establish a culture of honesty with your team members and expect honesty from them especially when the situations are difficult.
  3. Learn to delegate and then focus on solutions and not process.

The book Brownfield Application Development in .Net has some ideas that I think should help. Part of the advice is how to set things up so that they're repeatable across team members, and across time.

Not the answer you're looking for? Browse other questions tagged or ask your own question.