I’ve recently switched to a new role at MobME, and here are my initial impressions and a few lessons learnt in the past few months. This is a rather free-flowing account, but I want to write this down and codify before I forget.

Rule uno: people aren’t resources. There’s a constant management-level question I hear: “How many resources can you allocate to a particular product?” or “How much time and resources do you need to solve this problem?”. I don’t answer such questions at all, or when I do, I talk about the people I have in my team and their skills and limitations. I’ve strongly felt that no organization can grow without taking care of its people, and especially for small startups, to make attrition low and happiness high, this is a concern that should be addressed from the top. Rephrase these questions this way: “Can person X solve this problem?” and “Can person X and Y be reallocated to this task?”.

Following on, every person is special: they have different skills, learning speeds and communication capabilities. Every good person can improve, and they should constantly be pushed to do that. Nobody should be idle and static.

And nobody should do make-work. It’s not necessary because there are always real problems to solve. If anybody is picking up a new language or skill, after a few tutorial-level sessions and a max of two days, he should jump into the new role and start fixing bugs and solving real problems.

Good processes make a good team. At MobME, I’m implementing a few things I learnt while working at Uzanto: Daily End-Of-Day reports for the team, SCRUM in the morning, and constant communication via a small office and approachable managers. The work atmosphere is relaxed, and people are given time to learn. There’s no fixed time for lunch or a quick smoke. There’s an attendance register and people are held accountable for their work and leave.

At the end of the day, Work is Everything™. If there’s a deadline to be met, do or die, we meet it. People remain late in the office (till 1 at night is the current MobME record) and finish work before they go.

What you do when you’re not in office is none of anybody else’s business. Although as a rule, work hard, party hard.

When you lead a technical team, if you have problems you use technology to solve them. This is obvious, but I’ve so often seen this overlooked. You can’t find a way for developers to collaborate? Find an effective source control method. Project management? Bug tracking? Time tracking? A caveat: too many tools is a mess. Find effective and simple ones. We use Beanstalk and Lighthouse along with Google Apps for documents and mail.

As a corollary to the above, not every problem is technical. Instead of inventing one, try simplifying the product or the spec or going back to the drawing board. If it’s too much of a hassle technically, it’s the product pushing back at you, resisting crappy things being done to it. Hear it out and redo things. Redoing things the right way is a good thing. Take time out, fix stuff and it won’t bite you in the ass the next time.

Another gem: keep internal mail to a minimum. When everybody is in the same office, shout out to him (or take him outside) instead of firing off a mail thread. It’ll solve problems so much more efficiently. Having the management & technical wing in nearby offices means that for us, most problems are solved in a week. No network cabling in office? A quick discussion with my operations lead and I get work done. No firing off complaint mails.

Communication is key. Let everybody know your worries. Everybody includes the people under you. A lot of the time, they’ll end up finding a better solution.

The primary role of a technical lead as I understand it is to get work done. It’s not to go off to conferences evangelizing the product (although it’s a good thing to do). Meet the deadlines your boss sets for you. Make sure your people work hard and they learn lots of stuff in the process. Keep an eye out for new technology. Document your processes. When you find problems, fix it and ensure it doesn’t happen again. Get good infrastructure. Communicate problems with the management.

Everybody in sales, marketing, etc. should know more than a little bit of tech. Increase technical awareness and make the process transparent so anybody can ask questions no matter how stupid it is. Often a completely new way of thinking about a problem brings in new technical insights too.

When there’s a problem, criticize. This is hard to do initially, but good people realize that your criticism is for the work and not the person. If they still have issues after you talk it out, ask them politely to leave or toe the line. When you find people improving and processes becoming smoother after you’ve talked it out with the team, it’s a real nice feeling.

And at the end of the day, make people happy and be happy yourself. Which of the lot, is the hardest.