Week 8 of being cruX Secretary

6 July, 2023 - 12 July, 2023

What is this?

Hi. I decided I don't write much, and it would help if I did. So, I'm going to be documenting the things I learn here. I really didn't want to make this a public thing, but I think it keeps me in check in a way. For Google Code-in, I made my posts public from the get go, but I didn't really do that for GSoC. That was the big difference. I never ended up following through with my promise of making blogposts for GSoC.

This is the first week, and I need to lay a lot of groundwork for what exactly I want these blogposts to be. Which is why this blogpost will be much longer than the rest, so bear with me for this one.

What's cruX? What are these blogposts?

cruX is the programming and computing club of BITS Pilani, Hyderabad Campus. I was initially made the Secretary of the club on May 18 2023. Since then, I've tried my level best to push this club to its maximum potential. The last 2 months flew by in the blink of an eye. But, I've come to terms with two thing in the previous 2 months: first, that I am a terrible manager, and second, that I've surrounded myself with yes-men.

The yes-men thing is pretty simple: Every time I ask my friends in the club if I'm a terrible manager, they all instantly go "oh nooo you're not nooo", and tell me about how I've managed to pull outcomes out of this thing for the past 8 weeks, and all the work I've done. But again, for the reasons I'm going to lay out now, I'm not entirely convinced.

These two things are genuinely saddening, and are honestly making me reconsider a fuck-ton of my choices in the past 2 years. I hope the blog posts that follow explain why I think this.

I am a terrible manager

Some more context

I am now in Year 3 of my 5 Year dual degree program. There are 26 members in the club that I am responsible for, including myself. 6 of these are in Year 2, and the rest 20 are in Year 3.

I'll be honest, I've done a lot in the last 8 weeks.

Week 1: 18 May, 2023 - 24 May, 2023: set up account logins and permissions, decide some goals for things to get from the Student Union, estimate server costs, assessing current cloud hosting situation, reallot work for the semester across projects, make decisions with respect to projects to discontinue, discuss timeline for all projects, discuss designs and ideas for new cruX website with the rest of the club
Week 2: 25 May, 2023 - 31 May, 2023: decide on Atmos events for the year, discuss this with club members, discuss timeline of the semester ahead, decide on action plan to revive CTF team in cruX, receive and assess the designs members submitted for cruX website figma pages, decide the new approach to cruX forum going forward, greenlight rideshare as the first service in forum, decide on stack and primary features for chronofactorem
Week 3: 1 June, 2023 - 7 June, 2023: approach BITS-SOS about the future plan with regards to CTFs, finalize event details and strategies for events (collabs, contributors, etc,), assess current financial status of the club, and ensure that all financial transactions and assets now have a paper trail or atleast a log of some sort, discuss project status with game dev
Week 4: 8 June, 2023 - 14 June, 2023: get access to a free Oracle Cloud account, Dockerize and host the old version of ChronoFactorem on Oracle server, hop on multiple meets to try and finalize the website color scheme, finalize and announce decision to screen Design/UI candidates for inductions, formulate first draft of design screening task, start primary negotiations about Atmos event prize money, event logistics, and collabs
Week 5: 15 June, 2023 - 21 June, 2023: send design screening tasks to all designers, finalize collab with CSA, submit primary Atmos event details to Student Union, finalize new domain provider due to the unexpected sunsetting of Google Domains, create teams and Discord server for cruXipher 2023, have another review meet with game dev on project, discuss initial structure of rideshare backend and app, finalize schema for ChronoFactorem, finalize the endpoints we need for ChronoFactorem, made sample PR for ChronoFactorem, ironed out build issues with ChronoFactorem
Week 6: 22 June, 2023 - 28 June, 2023: follow up with designers about design tasks, provide updates and primary feedback, draft problem statements for cruXipher, finalize the finer details of cruXipher, draft publicity posts for Atmos for DePP, fix bugs with ChronoFactorem development, make PRs for ChronoFactorem endpoints, review, and get people to review PRs on ChronoFactorem
Week 7: 29 June, 2023 - 5 July, 2023: merge the last few endpoint PRs on ChronoFactorem, hold activity review meet for the month of June, discuss a way to hold interviews for design inductees, revamp build system for ChronoFactorem, make a test timetable for ChronoFactorem, start writing unit tests for ChronoFactorem, finalize and submit event problem statements to Student Union
Week 8: 6 July, 2023 - 12 July, 2023: review the designers' submissions, get feedback from other designers on the submissions, finish writing sample unit tests for ChronoFactorem, reach out to inactive members in the club, put forward out first draft of budget for prize money and inventory for Atmos to Student Union

Now all this is a lot, but there's a critical flaw I've seen myself fall into in the last few weeks. Is it really my job to be doing a lot of that? Am I supposed to be making PRs for API endpoints, or rewrite build systems, or write unit tests? It's not horrible for me to do all that as long as I'm also managing the rest of my "managerial" duties, yes, but the bigger issue is that it prevents others from learning. There are maybe 1 or 2 people in the club that I can trust with rewriting the build systems, or writing the unit tests with no reference point. What I am preventing is the long term growth of the club and its members.

I feel like I have a fundamental misunderstanding of my work. I'm not supposed to be a dev that can also make decisions now, I'm supposed to be a "mentor" of sorts, coordinating club activity, making sure people learn what they need to do, how they need to do it well, and giving them the environment to do it all. I'm supposed to become the road the people drive on, not the fastest driver, or the driver that's leading the parade.

Is it that bad though?

So I threw my weekly log of work into ChatGPT, and asked it to guess the role of the person that wrote this log. It replied with:

Based on the provided log, it appears that the job or role being described is related to managing a student club or organization. Here are some possible job titles that could match the activities mentioned:

Student Club President/Chairperson: This role involves setting up account logins and permissions, making decisions about goals and projects, discussing designs and ideas for a club website, deciding on events and strategies, assessing financial status, and interacting with the Student Union.

Club Coordinator/Manager: This position involves overseeing various aspects of the club, including project management, event planning, financial management, member coordination, and communication with external organizations such as the Student Union.

IT/Technology Coordinator: This role focuses on managing the club's IT infrastructure, including server setup, assessing cloud hosting options, making decisions about technology stacks, managing website development, and collaborating with game developers.

Please note that these are just educated guesses based on the provided log. The actual job title and responsibilities may vary depending on the specific context and organization.

Now this is a pretty spot on answer.

But when I think about my priorities, I always think of the third point. It's always "I need to get my unit test samples out, so that the others can follow the same format", or "I need to review these PRs fast so that others can get back to writing code quickly", never "How do I make sure the Flutter people want to work on their projects?". It makes me feel unfit for the job in a way. I am not a manager. My priorities seem to point to a "tech lead" sort of role. But then I sat with this thought for a while; You won't find anyone in the club that is a manager. You won't find an insanely talented developer on a college campus that says "Oh and I also really like management". This is not a thing that I've seen.

I am unfit for this job

As I write this now, one book title comes to mind: "The Making of a Manager" by Julie Zhuo. The intro to the book argues that managers are made, not born. This makes sense. You rarely see companies "hiring" a manager. Why hire some person that doesn't know your team, your company, your culture, your internals? You always want to turn a designer or developer into your manager, someone that knows how the club runs, who's familiar with the people and the system.

This is another thing I realized from reading the first few parts of the book: I'm behaving like the club is on life support. It really isn't. I'm in there writing code and writing unit tests and shit, as if I don't do that, tomorrow the whole thing will fall apart. I need to let go. I'm having an additive effect, by participating, by being a member of the team, just like the rest. What I should be doing instead, is having a multiplicative effect, by getting the rest of the web dev guys to understand build systems, by getting them to a point where I can have them review code stress-free. It might not help now immediately to get this project done in the next month, but there's month after month after that, where I can't go focus on other teams because I need to be in web dev reviewing PRs.

This is what makes me think: I am not fit for this job. I find writing those build systems, figuring out how to bring readability and beauty to a large, complex system (which is why I fucking love playing Factorio), writing large chunks of the codebase quickly, to beat deadlines. I am a rat.

At the same time, I don't think that prevents me from doing this job. I believe people are way more malleable than they think. Throw a developer into a sales job for a year or two, and initially they'll hate their life, but eventually they'll learn the ropes, understand how the system works and what they need to do to excel at their job. I think I can learn how to do this job well, even if I'm trash at it now.

Conclusion: I am a terrible manager

So far, I think I've pretty much proven that I'm a terrible manager, and an okay team lead. From here, my goal is to become a good manager. The last 8 weeks have taught me that I pretty much hate management, and I never want to do it for a career, but I want to try it as an experiment. I feel like it will test my hypothesis of people being malleable. More importantly, it could teach me that I'm malleable.

All this reminds me of an experience that is now a core memory: So in Year 2 Semester 2, since I am an Econ student, we had a course on Management. It was called "Principles of Management". The first few weeks of classes, I was just speechless. The amount of pointless diagrams, the sheer number of management buzzwords per minute, it was everything I imagined it to be, and more. My dad is a manager, so I've heard all these book names, all these words, and seen all these shenanigans in real life. I thought it was an interesting coincidence, and didn't think much of it. But, one fine evening in that same semester, I found myself at this burger place on campus, with 2 of my friends. Some discussion about management came up, and the 3 of us realized that all our dads are basically carbon copies of each other. They've read the same books, they say similar things, they do similar things, etc. They're all managers. It made me think, there is a real steretype of managers, and this stereotype really exists.

It's like all these managers are being manufactured in a factory. A factory. Huh.

If I want to become a good manager because I care for this club, what its goals are, and I want to try this experiment of trying to beocme a good manager, I have to put myself through this factory. Sounds funny, right?

It's roleplay.

I have a pretty embarrassing story: I've walked into a grocery store on campus in a cockroach costume with a couple of my friends, because I thought it would be a pretty funny practical joke.

I liked it. I had fun doing it.

Another thing I could connect to this: The Eric Andre Show. In Season 2 Episode 3 of The Eric Andre Show, Eric dresses up as a typical stockbroker finance-bro, and goes on the streets, talking into his earpiece loudly. The main objective is to say weird things loudly, and capture the reactions of people around him. The people around him don't have much of a reaction compared to his other skits, but I found the skit particularly funny just because of the idea of it.

Another skit from the Eric Andre Show you could connect to this: In the same episode - Season 2 Episode 3 - Eric dresses up in a large trench-coat, along with another man, and goes out to buy a car. Again, the car salesman's reaction is not that interesting in my opinion, but just the idea of actually dressing up as 2 people in a trench coat tickles my brain.

It's all roleplay.

I think it would be slightly funny to essentially dress up as this stereotype of a manager, and do managerial things. I could be doing a real job, and having an impact on the working of the club, but that's a side effect. I could have fun being a manager because I'm only pretending, and it's all a play/joke to me.

I'll read books, try tricks in real life, try following advice, and try seeing how far I can push the satirization of a work meet. Can I show up with a powerpoint next time? Maybe sprinkle in a word like "synergy" or two? Ask about status updates, meetings, deadlines and action items? How far can I push this exactly, until people realize the bit?

This is the experiment I want to try. I want to put myself in a job I feel like I don't belong in while I play pretend, roleplay as the stereotype, and see what I come out the other end. I believe it will have positive effects on the club, and I'll get to learn a lot all while having fun.

These blogposts are essentially a log of this experiment.

This week

This week wasn't really that eventful.

As I said, I started reading this book called "The Making of a Manager" by Julie Zhuo. My friend sent this book to me, and I've really enjoyed reading it so far. This book is what made me feel like writing these blogposts and doing this experiment, essentially.

I thought I was an okay manager before I started reading the book, but the more I read, the more I'm convinced I'm not. This is why I wanted to do this experiment. Can I become a good manager by dressing up and roleplaying, and can I document this process?

Now since this is all I really did, and all this happened on 12th of July, I'll be sharing specific parts of the book that I found interesting, and trying to contextualize them in interesting incidents from my life so far.

Now I do feel like I've convinced myself that I'm a bad manager after reading parts of this book, but I feel like I need to cater my words a bit more towards a future secretary who's in the same situation as me. I feel the need to explain what I mean when I say that I am a bad manager a little further.

A manager's job is outcome oriented

Now I thought I was outcome oriented. Oh boy was I wrong. I thought because I wanted to get a project done, or because I wanted to get people to finish X amount of work, I was outcome oriented. A manager's job is outcome oriented in the "Why"s and not the "What"s. What I just listed out, projects and work is the what. The why, is a multitude of reasons. Why do I want to get projects done? Well, so that members learn programming practices, so they learn how to work in a team, collaborate, learn the tools we use in such situations, and so that people not only use these projects but look at them, and think "Wow I want to build something cool like that."

This is a manager's job. To reach outcomes in the whys. I was completely operating in the whats.

Even in Finance, something you learn is that profitability of a company is much more important than the activity of the company when talking about investing. Of course, one could make the argument that Amazon actually made losses for years on end, while focusing on activity over profitability. But look at that neat semantic trick: They leveraged their activity later in their life, to create profitability. It was all for profitability. The outcome is once again what matters.

Being outcome oriented is... tricky

I feel cringe every time I bring this up, but an exceptional example of just how tricky it is to be outcome oriented is presented perfectly in the show Better Call Saul. Saul's entire character arc hinges on this moral dilemma.

The field of Economics is pretty infamous for its use of assumptions. "Assume that the market is perfect", "Assume that the competition between two firms is perfect", "Assume every person can see infinitely into the future and past, and has all information possible", and so on. Whether or not these assumptions are justified, or whether they're too much for the field of Economics is a whole different can of worms, but the biggest criticism by far, even from Economists of a lot of Economic theories is: "Can you really assume that every person is a perfectly rational, moral, and informed agent?"

The same applies here. Being outcome oriented is so tricky, exactly because we are human and not some kind of perfect spherical frictionless agents. We are bad at predictions as humans. Approximately 98% of day traders end up making a loss on average.

Do you tie all your club members down and electrocute them until they finish the project? Do you ask them for status reports twice a year? Or do you participate in every activity with them, to show them that you all are a team? Do you maybe maintain a strict distance between your members, and maintain hard deadlines, and develop tough, work-oriented culture?

Hey maybe the field of management will have something to say about this? Well, what does management say? "Do what you need to do, to get to your goal." Yeah. Not very helpful.

It's very easy to be disillusioned about management, and to believe that it's all make believe, and stupid jargon and meetings to make managers feel more important. It feels hand-wavey, and bullshit-y. I think that it's because of the subjectivity of the matter at hand. One size doesn't fit all. Heck, even your team might not fit each other, how will you manage to make one solution fit between teams?

If all that wasn't complicated enough, there's something called "Simpson's Paradox." Basically, what applies for a set might not apply to all subsets. For example, maybe you need to make someone in your team worse off to make the rest of your team better off. Sometimes you need to move people away from projects, or force people onto more projects than they want, or even kick people. It might not always make them better off, but if you believe that it is the right thing to do so you can make the entire team better off, so be it.

Giving up control

Even when parenting, you need to let go. You need to let people fall flat on their face, and make mistakes, so they can learn from them. If you always put your kid on training wheels, they're never going to be able to cycle without them. It's okay if you know how to do all the infra right, and you know how to structure the code right, but you need to give them a chance. If they don't try it on their own, when will they learn?

I did do this at some point, where I allowed some members to review Pull Requests and merge them, but eventually that did lead to pretty big mistakes being made. I eventually just stepped in and corrected everything, but what I realize now is that nobody learnt anything from it. Sure, less time was wasted, but in a way we ended up in a worst of all worlds.

Say a bad PR gets merged. Now, this is a pretty big PR and you need to revert significant changes to the code before you can even begin looking at the other PRs. Imagine two scenarios: In the first one, you inform your members about the issue, and watch as they scramble to correct their mistakes, and see them revert the PR, make a new one, correct the mistakes, review it, and then merge it once again. A lot of time and effort is wasted, but a lot of learning happens. Now you have 2 more potential members that can review PRs. That's a 200% boost from when you had just you.

Now imagine a second scenario, where you step in, revert the mistakes, ask the members to correct their code, you review it, and then merge it. Time is again wasted, although lesser. But the fundamental issue is that not only did you waste time, you got no return from that waste of time. You didn't leverage your failure to be helpful in the long run. No growth has happened, and everything that has happened has only pushed back deadlines.

I ended up in scenario 2 for ChronoFactorem, and I now regret it.

Don't walk on eggshells

The entire time I was working on ChronoFactorem, I was walking on eggshells. Everyone was finishing work faster than I'd ever seen them, and the entire backend was written in around 6 days. I was terrified that they will all get burnt out, and would never come back.

I shouldn't have done this. I should have made them take up responsibility for their own actions, which would make them think twice or thrice before submitting a PR. It would have slowed down work, but PRs would then be easier to review, there would be lesser time lag, and the code would be more correct.

Don't let the emotions of your members hold you hostage. They will cry and moan about having more work, but remind them that they caused it, not you. Of course, don't take this to the extent where you blame them for your mistakes. If you can't take responsibility, they will never learn to. Take their emotions into account, hear them out, but when it's their mistake, remind them gently.

Have a multiplicative effect, not an additive one

When we say "infra" in the programming world, we mean infra. Infra is not just the thing that keeps buildings intact, it is the roads, the bridges. It is not just the buildings, but also all the glue in between. Infra is not just a server that hosts nginx on port 443, it also encompasses how the dev environment looks, how it compares to the production environment, the testing to make sure the code is correct, the way a developer can seamlessly push their changes to a staging instance to verify if everything is working before they push to production.

As a manager, the closest thing you can do that still remains technical, or code-related in a way is Infra. A good manager can create these environments for their devs to excel, or atleast has someone like this at their fingertips.

These changes reduce time lag, and speed up the team. If a developer has to put in less effort to ensure their code is correct, then more often than not, they'll end up pushing correct code. If a developer can quickly make a PR, then they are more likely to do that more. These actions reduce the mental cost of these things, and oil your system up to work faster.

One article that comes to mind when I talk about this is: https://jsomers.net/blog/speed-matters

Even as a dev, these things matter. As you move up the chain, you need to make sure that every interaction you have with others minimizes the cost of doing work for others. Seeing this in real life is what convinced me on the reality of this.

At my PS-1 internship, we had this guy called Ajit Trivedi. Ajit would answer to pings at lightning speed, he would review PRs first thing he gets time, he would answer all your questions, move things around on a server or on staging instances all so you could get out of his hair and into work. Even if I wanted to take it a little slow, and figure out the specifics of Spring before diving into the work, I would be forced to do work, because Ajit would make it so easy, so cost-less to get started on that work.

The activation energy for a reaction being that low basically guarantees that the reaction is spontaneous. If you can do that, you have won. You have pulled work out of people that don't even know it.

In my opinion, this is the one thing I've done well during the last 8 weeks. Every day of those 6 days we spent on the ChronoFactorem backend, I constantly tested how fast I can respond, and how quick I can review and move ahead and no longer be the blocking task in their task queue. It worked magic. I have never seen a backend done in 6 days, and guess what, we did an entire rewrite of a project in those 6 days.

This multiplicative effect is what matters. You can be at your laptop for days on end typing code at 100s of WPM, but it will never come close to the situation where all your team members are atleast some fraction of that.

I notice this in Bangalore as well. The number 1 reason Bangalore traffic is so bad compared to Hyderabad traffic, is not because they lack public transport or because the city isn't walkable. These two reasons will certainly reduce the traffic significantly, but I'm comparing it to Hyderabad. Hyderabad isn't insanely walkable, and isn't close to god tier public transport either. It is because of the footpaths. Bangalore cares about its pedestrians too much. In Hyderabad-land, they are merely a speed bump between you and your destination. In Bangalore, they are first class citizens, with "rights".

For a city that big, this is catastrophic. Your roads aren't as wide, meaning that you can fit fewer cars beside each other. This means, more cars are behind each other. Already, you end up with lower area because of the loss of width to the footpaths, but something else has happened, which is the main culprit: The reaction time is now a factor.

This reaction time is catastrophic. If you have even slight variances in these reaction times, you will end up with horrible traffic. This is precisely why Bangalore traffic sucks that much. The cars are behind each other instead of being beside each other.

Here's a CGP Grey video to make it even clearer:

This multiplicative effect of reducing the friction inside your team is what you need to do. You need to become the road. You can no longer remain the rat. If you try to be both, you can end up the rat that's flattened on the road by some car. You don't want that.

Are you on fire?

No, seriously. Are you on fire? If not, take a deep breath, and a step back, and chill. You should be working in an additive manner only when you are on fire. cruXipher in a week, and the event platform is not ready? Get on that shit, go write the code yourself. You are on fire. If you're not, continue working multiplicatively.

Conclusion

That's... all I've read. Surprisingly, I'm only some 35 pages into the book, and this thing has made me realize insane amounts of shit about myself. I've learnt a lot, and I want to continue. Surely I will take time out every week to write a blog like this.

In all seriousness, I miss writing, and I miss the ability to sneak in examples of me being a rat, and being able to casually write sentences like:

Bangalore cares about its pedestrians too much. In Hyderabad-land, they are merely a speed bump between you and your destination. In Bangalore, they are first class citizens, with "rights".

You need to become the road. You can no longer remain the rat. If you try to be both, you can end up the rat that's flattened on the road by some car. You don't want that.

This was fun. Fuck I've already hit the end of July 13th before finishing writing this I need to go back to my roleplay session, goodbye.

Soumitra's Blog