Tapping the enormous potential of rebels, and other insider tips on managing a tech business.

First off, for those who claim that management is not necessary in a technical environment – I respect your opinion. And this column is not going to interest you. You might as well go to Slashdot, or MetaFilter, or CodingHorror, or ….
(Disclaimer: The fact that I believe that management is necessary in a technical environment does not mean I do not visit the above sites – I am still a geek at 32.)

 

Best Microsoft MCTS Training – Microsoft MCITP Certification at Certkingdom.com

Managing a start-up environment is different from managing a mature software business. There are several things that work in a start-up that may not in a mature set-up, and vice versa. You’ll notice that I have emphasised the ‘may not’. There are several companies that I know of that work in start-up mode. Some of the points below may work in such firms, if it is part of the culture of the company.

1. Avoid meetings – have discussions: Though it may seem like I’ve given different names for the same thing, it really is not so. There are several significant differences, such as:

* In a discussion, there is significantly more participation from the grass roots engineers, than in a meeting.
* There is no agenda. There are points of discussion. The key here is that meetings are over when the points on the agenda are done. Discussions are over, when everyone is convinced.
* A lot of learning takes place in a discussion. People can ask for clarifications and elaborations. There is no, “Let’s take this discussion offline.” This is the discussion.
* Action points are taken up by the ‘actioners’ themselves. There is more accountability this way.

2. Avoid status meetings: Status can be covered either by discussions like the above, or by just walking over to the cubicle of the developer. I sometimes write down the action points, etc, on the white board in the cube.

3. Give more freedom to developers: They are more creative this way. They are more accountable, and they feel good about it. Developers who feel good about code they develop are just more productive.

4. Break stereotypes: Get Wi-Fi to the coffee room/pantry. Who says the pantry is only for relaxing. If the developers are most productive at night and make requests for coffee or tea, get it to them. Do they require dinner? Order in. Do not worry about what others will think- or whether it has ever been implemented before. Just do it.

5. Buffer your technical team from the management: As far as possible, you, the technical manager, should be the one who oversees the development. Try and avoid interference from higher management. They do a very important job of bringing business to the company. Let them do so in peace. If possible, prevent them giving advice, suggestions or recommendations on what should go into the product, or comment on how easy or difficult it is to develop something. You, the technical manager, should be the buffer between the developers and the upper level of management.

6. Reward rebels: There are programmers, and there are rebel programmers. These are the bearded ones, who get maximum work done between 11:00 pm and 1:00 am. If you encourage them through whatever appropriate means and align them with the higher objectives of the company, you have a winner here. Reward the rebel handsomely. One must understand that rebels do not consider money as the only reward. They can be rewarded with better machines, dual monitors, leave-with-no-questions-asked… These things are equally exciting to the maverick. Go on, encourage the rebel in your team, then sit back and watch the fun.

7. Infuse energy: Have you ever walked into a start-up office–one that is doing well, and is also managed well? Can you feel the energy? There are heated technical arguments in the hallway. There are those with headphones, listening to some loud music and bobbing their heads, even as their hands furiously program. You can see people coding with feet up in the table. You may catch someone who, having just finished coding a module, throws up his hands in accomplishment, and drags a few of his mates for a coffee. That’s the energy. Encourage it. You, the technical manager, should be part of this energy. Go and high-five the guy who just finished the module. Participate in the hallway argument. Sit back and have a cup of coffee with the so-called junior developers and share some history. You will not only be considered the cool guy, you will be the one who gets credited for all the energy (and hence the productivity).