Leading a team

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.

5 responses

  1. This is an interesting post. You should submit it at yearblook.com/submit.php. Yearblook is a competition to find each day’s best blog posts. At the end of the year, the 365 best posts (1 from each day) will be published in a book (a real, printed book, you will find it on Amazon).

  2. Swaminathan kaushik Avatar
    Swaminathan kaushik

    Yeah its the simple stuff that people miss out often…good one..

  3. confess that i didnt read it fully.. but what I read was great 🙂 have always wondered why managers just try to do software like the old time -unit-work math problems.. if 10 persons takes 5 hours to construct a house blah blah.. wierd! programming doesnt work that way does it, but people still follow it even in a 250,000 strong 50 billion dollar profit company 😀

    .. will be back when i have more time

  4. Nice post. One doubt –
    > And nobody should do make-work.
    What do you mean my ‘make-work’?

Leave a Reply

Create a website or blog at WordPress.com