I wrote this an year back, just after finishing my Bachelor’s degree. Then I changed laptops, and lost the file somewhere. I found it today while I was fooling around with a new laptop I got for a ridiculously low price. WARNING: My successors were probably more efficient than me- they might have better advice to offer. NOTE: In the hindsight, the advice in this post might seem obvious. But it was not obvious to me when I started out. WARNING: I’m pretty sure I’m somewhat affected by Confirmation bias.

This was my last year of undergraduation, and my seniors, grossly overestimating my capablities saw it fit to place me in positions of responsility. One in a student organisation that creates our college’s annual magazine, and the other as a subsystem lead in an undergraduate research project. As a grunt, (aka a worker / programmer / writer), I had been just above average. As a leader, I was sure that I wouldn’t succeed. But I’d learned a lot during my time as a grunt, and didn’t feel like turning down the responsibility.

My tenure as a “leader” came to an end recently, and I’ve been thinking about how I fared. I did make a lot of mistakes, but I also tried to follow a small set of rules, and I came out on top. It was only towards the end that I began to realize what exactly I was supposed to do, and which actions from my side would make my colleagues productive.

I wasn’t able to make any radical improvements to the way the teams that I led functioned. The teams, therefore, did not gain much from my leadership. I, on the other hand learned a lot. More importantly, I had the privelege of interacting with a lot of friendly, talented, enthusiastic, ambitious people. As Richard Little would say, I’ll watch their careers with considerable interest. And I’ll look forward to the times when they turn to me for advice and experience, the way I’d turned to my seniors (perhaps more than I should have). And I’ll say this- other than the working my ass off on some project that I loved, or learning something which I find exciting (things that I find myself unable to do today), the most valuable thing I have done in college is talking to people who I found interesting. In fact, it was this third thing that led me to do the first two. As a leader, the degree of interaction became 3x- my work involved more of talking to interesting people and less of doing interesting work.

I’m now going to write down what I learned from my experience, and offer advice to others who would be walking this path. Perhaps I should title this post “On leading student organizations”. Perhaps the advice that I shall now pompously disburse applies only to leading student organisations, or maybe is completely wrong. In any case, I shall proceed to do so.

Things that do not work

Trying to lead from the front

Both my positions were not “managerial”. In one, I was supposed to guide people in their technical tasks. In the other, I was supposed to help people write well, and offer suggestions. As a result, when I started out, my model of doing well was “leading from the front”. As a leader in a technical team, this meant understand every technicality in every task, read the research papers that individuals were referring to, and have deep discussions with them. As an editor, it meant reading everyone’s work and offering concrete suggestions about what excatly they should change in their article to make it better. I tried to follow this model. It didn’t work, for two reasons. One, these two responsibilites were not the only ones I had during my senior year. And two, there were too many tasks and too many articles.

Towards the end, I realized what it was that I should have done. It was my duty to understand things people were doing well enough to stop them from doing something wrong, and to think of how it would fit into the system as a whole. But it wasn’t my duty to try to specify what exactly they should do. By doing so, I was weakening their technical abilities, and worse, I was making them think that I was the solution to their problems, while I neither had the time nor ability to solve technical issues that each of them encountered. I did something similar with the magazine- when I thought something was wrong with someone’s article, I tried to suggest exactly what they should change in it. This does not work, because I am not the author! I can tell them what I liked and what I did not like. The takeaway here is don’t get too involved in low-level details. Offer feedback when things go wrong, or when they seem out of place. Offer encouragement when they go right. But don’t try to fix everyone’s problems, you will fail.

Trying to do actual work

This is similar to the previous point. A problem I faced was that I used to commit myself to work items, and used to end up delaying them. Here’s the problem- suppose I say that I will contribute to task X along with 3 other people A, B, C. A and B are done with their portions before I am. Now even if they want the task to get done early, they generally won’t call me out for the delay I am causing, out of politeness. And C will look at the delay I have caused and will himself procrastinate. Now you’d say- this is plain laziness- you are just being lazy. In part, I am. Being lazy was one of my mistakes. But here’s the deal. There were 5 such tasks, each having a different set of people working on it, and I was supposed to be involved in all of them. As much as I hate it, worrying about whether everyone is doing what they are supposed to is a task big enough by itself. By dividing each task among 4 people instead of 3, I was not actually reducing work per person by a significant amount. I’d imagined that me contributing would raise morale, and people would feel more invested in their work when I showed that I wasn’t just someone who was assigning work, but also doing it. The truth is, people don’t care. If everyone does not respect you for the work that you have already done, then you probably don’t deserve a leadership position. And if they already do, you don’t have to prove your capability over and over again.

The other situation when this backfired was when I used to imagine myself in their position, and think “If I am not able to get this done, how will they? Then how can I assign this work to them?” As a result, I ended up delaying work allocation. The harsh reality was, the work item had to get done eventually. It wasn’t as if I was going to do it for them. By delaying its allocation- I was taking away the freedom of those who were going to work on it. They now have a smaller window for working on the task- and the window could have been larger simply if I’d assigned the work item early.

TL;DR; When a work item pops up, assign it to someone immediately. That’ll give them more time to work on it. As long as you are not assigning all the work to one person, it will be fine.

Not setting deadlines

I hate deadlines. A deadline is an infringement on my freedom. Deadlines have an implied (but actually empty) “or else” component. So initially, I refused to set them. But here’s the thing. Deadlines can be extended. The purpose of deadlines is to not cut people off if they fail to meet them, but to encourage people to get work done fast. The effort required in completing a task does decrease if I offer people more time (or in case of no deadlines, infinite time). In fact, according to Parkingson’s law, work expands to fill the time alloted. Set short deadlines, and people would probably end up working less. And if the time alloted proves to be insufficient, extend the deadline.

One nice way to set deadlines is to ask the person doing the task to tell them to estimate the amount of time they’d need to do it.

Things that work

Following up

This is the single most important thing that you should do. Keep following up on tasks that you have assigned. Don’t be shy about it. When people join an organisation, they join with the knowledge that they are going to have to work. There’s nothing wrong with asking people about progress, especially when you are the one responsible for ensuring that things get done. Some of my best work happened when my lead kept on asking me about my progress, and pushed me to work harder. People (atleast the ones that I have encountered) do not procrastinate by choice. They forget. They delay. And they are tormented by it. This makes timely reminders surprisingly effecitve in increasing productivity. “All they need”, as the Joker would say, “is one little push”.

Practically, I did this by conducting sync-up meetings twice a week where everyone would report their task progress, issues that they were facing. Initially, I had emphasized on the fact that everyone’s time was valuable, and that we’d try to keep the meetings short. Eventually, these meetings degenerated into long meetings where we would have technical discussions. But I realized that these discussions were useful, and we continued with the long meetings throughout the year.

DIFN

Do it f****ing NOW

As lead, I faced a number of chores- sharing resources, connecting people with others outside the organization, replying to emails, reviewing short reports, and replying to emails. Together, these things become overwhelming. But as short tasks, they don’t actually take as much time as you think.

If someone tells you to read something they have written, or reply to an email, do it right then. It’ll take you about 5 minutes, and you’ll feel better for having done something useful. More importantly, you are freeing up your team member to continue with their work.

Taking Calls

This is something that I am proud of doing. I failed a few times. But otherwise, I took all calls from my team members, and tried to resolve the issue immediately. This was the perfect way to implement DIFN.

I’d suggest that you take all calls, and except in extreme cases, discuss whatever issue your team member is having immediately, even if takes a long time.