One of the most difficulties that exists when managing a small professional services firm is to guarantee that exists a common culture which identifies all the developers in the firm. It is not uncommon to have one developer exclusively dedicated to a customer during a while, or for example, have a team of two developers mixed with customer developers to develop some project. We have some projects that can be developed in-house, and other that cannot. Of course we prefer to develop projects in-house. The daily living is one of the major contributions to build a culture. We can know better each other, and we can see the team as a family. When this kind of dally living is impossible, we must have alternatives to promote our culture.
Recruitment
The culture of a firm starts at the recruitment. When managing a small company, making a mistake when hiring can be the END. I will not detail our recruitment process here, but at interviews we always mention some characteristics that must be present to work at Agilior. Basically we tell our motto: "Learn or Out". We tell to the candidate that at Agilior we are always in continuous learning, and that we have passion about technology. We are always trying to evolve all the time. We tell to the candidate if he does not identify with this kind of behavior he is free to finish the interview.
Conventions
We have conventions defined to our projects at many levels
- Source control organization
- Visual studio (project structure)
- C#
- Database
- BizTalk
- Unit Tests
The main goal of conventions is to define some practices that must be used in all projects. The use of conventions guarantee some consistency between projects, and switching between projects is easy for a developer. The definition of conventions is a "work in progress", since there are always changes to be included. Some time ago we did a task force to draft the initial version. Of course we discussed a lot, since we all have different tastes. But the important is to have our people being committed in the process. We have also to be careful when defining conventions, since the developer creativity can be compromised when defining excessive conventions.
Sharing Knowledge
Having mechanisms to sharing knowledge is extremely important. We have an internal blog, which is much more active that our public blog. Many posts in the internal blog are links: interesting posts, tools, applications, etc. Right now we have 288 posts since January 2008.
We also have a Wiki and Forums in our intranet, however not so active.
One of our fringe benefits is to give to every developer an annual budget to buy books (remember: Learn or Out). The budget can only be used in books (technology, management, entrepreneurship). There is a list in our intranet where we register the books, so everyone knows what is being read at Agilior.
Agilior Meetings
And finally I have to mention that we have our monthly meetings. At the last Friday of each month we schedule a meeting with everyone. This is a technical meeting, where one or two of us are invited to give a presentation about a technical subject. This month, the subject is "Developing in Mono". After the presentation (and discussion) we make some kind of a daily scrum, and each one answer to:
- What did you do last month?
- What you will do in the next month?
After the meeting, we dine together at our preferred restaurant, with some beers, and "healthy" conversations .
I would like to have all the projects developed in-house, having the team all together, and investing in a good office space, with big monitors, great chairs, etc.. Maybe this is impossible in a consulting firm, and only possible when developing products. For now, we have to deal with the distance, and promote new ways to enrich our culture.
BFC