What if I made an IT company - planning for growth?

Let's take a little tumble down the rabbit hole.

So I've got an idea, a mind boggling earth shattering idea, I make a company around that idea, it ends up being very successful - everyone's happy? No, not really.

It seems to me and in my experience that the Finnish way of management is set on the belief that growth is always in the amount of people you have sitting around the office. You had that really successful IP that made you a million and that was the signal to now have 100 people sitting around instead of the original 10 who made that first million.

The cost of having those people soars into the sky and there was no plan for how to manage that growth when it was there and now - because of the logistics of multi-team projects and lack of tooling in place to facilitate all that collaboration you have a dead fish that occasionally pumps out shitty software.

So what went wrong?

Well most companies, I think, do not plan their business for growth and I think it's absolutely necessary to do that. So - here's a few things you should think about before hiring more people or taking on new projects or both.

• What projects do you have? To hire is to have work for them and a lot of it. People can do an amazing amount of things in 8 hours a day if given the right conditions. You have to commit to having these people - they won't give you any value if you can't provide them work.

• Do you have the right conditions - can it be that the amount of people you currently have would just as well be able to produce what you have planned for the next year? Are they all working in the same room, do they have the best tools and is their productivity the highest? How often are your programmers in the zone, and if not, why?

• Adding more people to a project will make collaboration more complicated - have you thought about how you're going to facilitate that collaboration? Is it going to be okay for everyone to be talking all the time about what needs to be done or do you have some IM-tooling in place for that? What about interrupting each other to ask questions and perhaps taking coders out of their zone? What about version control tooling - can coders share code and review work without too much hassle?

• Is the project you want to hire for actually worth it? Does it fit the portfolio of your company - does it increase the competence of your people and your company? You do not want people doing a little bit of everything averagely, you want them doing their thing - efficiently and with gold nuggets of software coming out the other end.

• Does your people want to take on this project? You really need to ask them because quality software requires people who care about and own their work.

• If you take on the project, after all that, can you guarantee that you can deliver on that project on time with high quality and so that it solves the actual problem well. Have you made sure that your existing work force has time to show the new guy the ropes, and they have time to commit to the new project as well. You can't hire guys and dump a new project on them alone, you need to have a plan.

• If you're adding more people to a project already late, it'll be later - and you'll end up with workforce you don't necessarily need.

Taking on a project - taking new recruits, growth seems to me like a much bigger deal than just saying yes or no.