Managing start-ups

First off, for those who claim that management is not necessary in a technical environment — I respect your opinion, but what I am going to be writing below is not going to interest you. You might as well go to slashdot, or metafilter, or coding horror, 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 <3 .)

Managing a start-up environment is different from managing a mature software business. There are several things that work in a startup but may  not work in a mature setup, and vice versa. You should notice that I have emphasized the ‘may not’. There are several companies that I know, which work in startup mode. Some of the below may work in these, if it is part of the culture of the company.

The following points are not arranged in any particular order.

1. Avoid meetings – have discussions: It may seem like I am just calling it by a different name. It is really not so. There are several significant differences. Some of the key differences are:
   1. In a discussion, there is significantly more participation from the grass roots engineers, than in a meeting.
   2. There is no agenda. There are points of discussion. The key point is here is that, meetings are over when the agenda points are done. Discussions are over, when everyone is convinced.
   3. There is a lot of learning in a discussion. People can ask for clarifications and elaborations.There is no “lets take this discussion offline“. This is the discussion.
   4. Action items are taken 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 items 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, just are more productive.
4. Break stereotypes: Get wifi to the coffee room/pantry. Who says the pantry is only for relaxing. If the developers are most productive in the nights, and request for coffee/tea in the night, get it to them. Do they require dinner ordered in – order in. Do not think about, what others will think about it — or whether it has ever been implemented before. Just do it.
5. Isolate from management: As far as possible, you the technical manager, should be the one who oversees the development. Try and avoid as much as interference from higher management. They do a very important job of bringing business to the company. Let them do it in peace. Try and avoid them giving advise/suggestions/recommendations on what should go into the product, or how easy/difficult it is to develop something. You, the technical manager, should be the conduit between the upper management.
6. Reward rebels: There are programmers, and there are rebel programmers. These are the bearded ones, which get maximum work done between 11pm and 1am. Encourage through whatever-means-appropriate-means for them to align with the high level objectives of the company, and 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, leaves-with-no-questions-asked.  These things will equally excite the rebel in your team. Go on, encourage the rebel in your team, and kick-back-and-watch-the-fun.
7. Infuse energy: Have you ever walked into a start-up office (atleast one that is doing well, and that is managed well). Can you feel the energy. There are heated technical arguments in the hallway. There are ‘rebels’ having good over-ear headphones, listening to some loud music and bobbing their heads, as their hands furiously program. You can see people coding with feet up in the table. You can see someone who has just finished coding a module, get up, and throw up his hands in accomplishment, and drag a few of his mates for a coffee. Thats the energy. Encourage it. You, the technical manager should be part of this energy. Go and hi-five the guy who just finished the module. Participate in the hallway argument. Kick back and have a cuppa 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 will be accredited for all the energy (and hence the productivity).
8. Small perks are valued more: Perks such as spending a hundred dollars on a fancy expresso machine are valued much more in a start-up. It reinforces in the workforce the confidence that management is trying to make the place as much fun and comfortable for them. Fresh cut fruits in the morning is another example. Rebel coders rarely have the time to shave, leave alone, have breakfast. They will come to work, and have fruits and coffee. Do not lay your hands on these small ticket items, when management tells you to cut discretionary spending. You can save more in economizing other things. Infact, get the dev team together, make the decision together.
9. Percolate field news to dev team ASAP: This is something that successful start-ups always do. Some of them do it partially, and get bombed for it. When I say partially, I mean, only bad news from field, in the form of bugs, and enhancement requests, trickle to the dev team. This is no good. Did sales bag another order – however small it is? Share it with the team, and celebrate. Hey the sales team celebrates it. And the dev team usually gets to know about this, and thinks – “dang! I created the feature, and I get nothing.” Percolate good news and bad news from the field down to dev team. You gain two things by doing this. You gain good-will from the team – the team thinks they are a part of the whole gig. And secondly, you get the dev team working more productively towards what the field and the customers require.
10. Celebrate every occasion: Yes, I mean every occasion. There need not be a lavish 5 course meal. Celebrate with ice-cream. Celebrate with pakoras or samosas  (in the Indian context). A feature that has been under development for 6 months, just got done. Celebrate. And call the whole team for it – not just the 3 people on the project. A new customer. Celebrate. 1000th bug fixed. Celebrate. A developer fixes his 250th bug. Celebrate. Give him a uber-debugger award certificate for it ! It is not about the food, or about the time, or about what you are celebrating. It is about, getting the whole team together, and reinforcing the thought, that the team is doing something very cool, and the management recognizes it.
11. Practise management-by-walking-around (MBWA): I just walk around and gather status. I just go and sit on the developer’s desk, while he lounges in his chair, and explains what he has in plan for the next week. He basks in the glory of fixing his 4 bugs last week. He tells me that he will be on leave on Tuesday. What did I just do ? That was my status meeting. I walk back to my office and note down important things in the conversation. You can get a lot of work done this way – and if you notice, the developer did not get off his chair, and he got back to work, right after you buzzed off. Wow, talk about productive meetings eh ?
12. Aggressive targets: Set aggressive targets, but after buy-in from the developers. Push the line. Raise the bar. Tell the developer that you are raising the bar. Make him/her raise the bar. Challenge the developer.

These are some thoughts on how managing start-ups can potentially be different from managing a normal software factory. These are not rules. That is the whole point. Take these ideas. Spin them off in your context. And watch the fun unfold.

The opinions expressed in this article are solely mine, and are not of my employer, in any way.