Welcome!
Hi!
MDX was a pain to deal with, so I just got rid of it. I don't think I needed it anyway.
This will be a much simpler alternative. I really admire how simple MDBook keeps it.
I'll try porting some of my old blogs maybe to this?
And yeah this blog will be largely stagnant, unless I really feel like talking about something.
That's very rare. I rarely talk anyway.
MDBook should be an easier dependency to both host and deal with in general.
Welp, there's not much here for now, so I'll end here instead of filling this with fluff like I tend to do.
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".
or
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.
Week 9 of being cruX Secretary
13 July, 2023 - 19 July, 2023
What is this?; What's cruX? What are these blogposts?
Read the last week's blog posts for a bit more context
This week
- Week 9: finish judgement on designers, reach out to designers about interview, and schedule a date, make sure that 22 batch members were in the loop to some extent, and ensure that they understand how inductions are done, finalize the format of the design interview, take the design inductions, and assign the final task for the designers, finalize course of action with respect to PS it's easy, reach out to inactive members once more, talk to DoTA about contributing to atmos website, decide loosely about an infra sprint, and register for ACC and RAF events
This week I made a lot of progress on the book. I am now on Page 82 and read the chapter on Hiring in advance to prepare for the interview. The Hiring chapter didn't prove to be very useful, because it was primarily oriented towards corporate, but it did stress to me how important inductions are, and just how important the HR round is.
The book, and the interviews were the only fun thing this week. Everything else was pressure from external bodies, dealing with inactive members, and deadlines for our work.
Your transition into your role
Here's the first thing that I felt. You will also feel it: the awkward air around you. Hopefully, when you signed up for wanting to be Sec, you've had peers who you think deserve the role more than, or as much as you. However, due to however things turn out, you ended up as the secretary. It will feel awkward. You have probably worked with the other person, and likely know them well too, making it even worse. You will feel pressure to bend your own goals for the other people you deem capable. Then, once you do realize you are bending your own goals, you will think about whether you're just a puppet for the other guy. It will happen. It's okay. I don't have tips for dealing with it. It goes away with time, that's it. Don't think about it much, and just do your job. You'll get used to it.
Behind the scenes
You will realize just how much work the previous sec was doing behind the scenes. You had no idea. HOWEVER, try your best not to express it to the rest of the people. The behind-the-scenes work is thankless, and that's just the reality. If you tell people about the behind-the-scenes work, you will either divulge information that they shouldn't know yet, or you'll censor yourself and they'll feel like you're saying nothing. Imagine you walk into a meet after a month, and the manager says "You guys have no idea whats happening behind the scenes, my days have been occupied non-stop. You'll be excited to see what's coming."
Nobody's excited. Why would they be? You've said nothing of meaning.
Imagine an advertisment that says "You guys have no idea what we're about to sell you." Nobody's drawn to that. Nobody cares. There is no information to think about. Who are you talking to? What is this for? Why should I be excited?
Same way, never say you're "working on stuff behind the scenes." Nobody likes it, and nobody has opinions on it. It just looks like you're making excuses to slack off, even if you aren't. It is thankless work. Accept it, and move on. The grim reality is that even if your day was occupied by behind-the-scenes work, you have to work overtime to do visible work, otherwise your team simply won't accept you. You will lack that critical sense of leadership.
Legacy
You will feel immense pressure to do things the way the sec before you did. "We must work on forum!" Why? "I need to satisfy the seniors!" For some reason the seniors suddenly feel like shareholders that you are accountable to. Every day you'll feel like asking the previous guy if you're doing a good job. To an extent, you need to detach yourself from that.
Obviously, if your ways are wildly different from that of the guy before you, your team will feel the shock. Change that fast will just demotivate them, and make them feel like you're not a fit successor. You need to slowly transition the team into your ways.
But that legacy pressure is good. It helps in smoothening the transition to your ways, it maybe even gives you some kind of hint for the best ways to manage your team, especially if the guy before you was good at what he did.
You need to strike a delicate balance between preserving legacy and moving towards what you think is correct.
Agency
Give people agency. I have done a terrible job at this so far. This part will be a little long-winded, but I think it will help explain every move I make for the next 3 weeks.
On the night of 18th July, my roomie was telling me about how his reading speed has plumetted. He told me how he read only some 50 pages in the span of a week, and how he used to read entire books in a day before this. I told him about the book I was reading, and how I read 35 pages a week, but I read 70 pages the following week, and how slowly the speed increases.
Eventually the conversation rolled around to software development, the club, management, differences between SDE1s and SDE2s, etc.
But the most important and influential part of this conversation was the part where he told me I'm a manager at heart. I obviously disagreed, and still disagree, but he said it, and he justified it pretty well. He said that the way I look at leadership or management is the way Jon Snow from Game of Thrones views it: Leadership is a burden. I mostly agree, that is the way I look at it. It's the same way Plato looks at leadership. If you don't step up and steer the ship, the chaos of the drunken sailors will surely drown you all. Thus, you need to step up for your own good and the good of the rest of the people.
I agreed because this was exactly what went through my head when I signed up for Sec. Nobody else wanted to do it then, so I set my mind to it. I decided I was going to sign up for it. Eventually, people around me did sign up for it as well, but when I set my mind to it, that was not the case.
But here's the part where I disagreed that I'm a manager at heart: the situation is unique. I argued that in a corporate environment, people around you are competent, and even if they aren't, I certainly would not care about the outcome or the goal. Some code in production is buggy? I don't care. Some service went down? It will be dealt with on Monday morning.
He, being blackpilled on the state of software engineering disagreed with the first point, but he told me that I will somehow brainwash myself into caring. I again gave him the example: I genuinely do not care if some service goes down. He told me that managers will generally make you the sole person responsible for some product or service or some unit of code, and hold you accountable to it. I said "that's how they get you."
That's how they get you
I'll be honest - I did think about this before. I considered making team leads in the club, and holding them accountable for their team. The only reason I held off from this, was because I saw it fail in clubs. One club that I was part of, the Journal Club (the one for writing, kinda like a Press club) had team leads. In fact, I was one of these team leads. But I never cared, and nor did they.
Somehow, this team-lead situation seems to work in the industry, but it didn't work for Journal Club; Why?
The what-s over the why-s
Funny. Look at that, the words are inverted now. But why? I don't know why. This seems to be the answer.
Managers make team leads in charge of the whats, never the whys. A team lead is a what, while a manager is a why.
Amazon makes team leads in charge of their team's work. If a team is working on EC2, or S3, the managers at Amazon will make the team leads in charge of making sure that EC2 work gets done, or S3 work gets done. You will never see a manager tell a team lead "Hey listen, you are now in charge of making sure Amazon delivers the best cloud compute services in the industry" or "You are now in charge of making sure Amazon contributes to the field of scalable filesystems."
Journal club made people in charge of the whys — their biggest flaw. I was the team lead for tech. My responsibility was to "make sure people write articles that enrich people's tech knowledge and interest on campus."
It's hilarious - you can see this contrast in Journal Club itself, you don't even need to step out of the club. Their most active part of the club is probably the Gazette - the monthly newspaper for the campus. This is because the person that manages the Gazette's job isn't to "ensure they deliver the best monthly newspaper experience to campus that they can"; it is to "make sure people write articles for the gazette."
You can argue that the Gazette lead's job is technically in the whys, but it never gets there functionally. You will never see a gazette lead make a decision that completely changes the format of the gazette or changes up what kind of articles show up. That's because that's the job of the secretary.
On the other side, you can argue that the tech team's lead job is to make sure people write tech articles, and remains in the whats, but there was no clear metric that was given to us; A gazette is a tangible item that you can produce once you have a bunch of articles, there is a set goal. For the tech team's lead? We don't know. Write an article, or don't. Maybe make an instagram post instead. Maybe write a blog post, or a gazette article. Maybe collab, or don't. Somehow someway, make sure people enrich the tech culture of the campus. How many articles per month, or which articles, or what format was never enforced. This fundamental lack of structure is what forced us to think about the whys. If we had a set job, we would have done work.
Conclusion: Agency
I need to get people. What I mean by that is the same as when I say, "That's how they get you." I need to make people in charge of projects. When I initially thought of the team lead idea, I thought maybe I could make a "web dev head." It was probably a bad idea in hindsight. I need to assign people to projects and ensure that someone keeps the rest in check.
This gives members agency over what they do, and makes them think a little bit. It makes them work. I can't always expect people to step up, they need to be nudged a little sometimes.
It makes them more capable; it makes me trust them more. It is fundamental to how a team would work. If I can trust my members and delegate stuff, I can have that multiplicative effect instead of doing things myself.
Feedback
One thing that ended up being true due to the nature of my friend group was that I interacted with few people a lot more than others in the club. I feel like it was hindering the club's activity in a way.
The book gave me this idea, and I liked it a bit; 1 on 1 meets. Think about it. If you have a friend or someone you talk to outside of the club, you often talk about the club outside of the club setting. This doesn't happen for the rest. If I can bridge that gap by catching up with the others every month or so, it could be a strategy that works. It will get them to build a closer relationship to me, maybe make them work more, and add a slightly personal touch to the whole thing. I'm not "the sec" anymore; it humanizes me. They can chat about their goals and stuff unrelated to the club.
It will be awkward at first, but I'm willing to put the time into it if it goes as I think it will.
One big challenge with this will be that I will have to make it informal. If I call it a "monthly one-on-one" it will feel too corporate, and they'll have their guard up the entire time. If possible, I need to invoke this in an informal setting and somehow have control over it.
I need to talk about this idea with a bunch of people and give it a try. If I try it on inactive people, it will be pretty effective; If it works, I can expand it, and if it doesn't, I can just kick them because they remained inactive. Easy!
All I need to do is figure out how I would implement this.
Inductions
HR Round is essential. It is not where you figure out someone's favorite ice cream; it's the critical part of the round to determine if you and your teammates can work with the guy.
The way we did the design inductions was pretty satisfying in my opinion. We had 2 rounds. The two rounds were:
- Whether you can make a good-looking design (technical)
- Interview
The interview had 4 parts to it, which was the part I was happiest about.
- Introduction: Who are you? Why do you do whatever you do? (save the more philosophical or practical stuff for HR)
- Technical Write: Given a problem statement, can you come up with a solution? If maybe you can't come up with the entire solution on the spot, can you come up with something that starts looking like a solution? Maybe given some days you can come up with one? One important part of this, is that you test a different aspect of their work than round 1. For the designers, if round 1 was making fancy UI, round 2 should be making boring, functional UI that is intuitive.
- Technical Read: Given a solution, can you decode the problem statement that the person that wrote the solution was trying to solve? So for example maybe you give a guy some codebase and ask them to understand what it does, or you give a designer two finished designs, and ask about how the original designers' intentions differed on various levels (like Product Manager case studies). This tests their ability to quickly understand existing work in their domain.
- HR Round: Can you dedicate time to this club? Do you understand what we do and why we do it? Do you understand your own motivations for wanting to join the club? What makes you different? What is your idea of skill? Are you someone we can work with?
One thing that we decided to do for part 2 of the interview round was that we added them to the Discord channel for one of our projects after the interview for a week, and we expected them to call meets, chat, collaborate with the rest of the club essentially to come up with the wireframe UI of the project. This tested something that wasn't listed in the above 4 points: Can you open your mouth? Can you have opinions of your own, and voice them? Can you communicate with the rest of your team and discuss your beliefs? Essentially, can you work with us, and fit in? This was one of the best things we've tested in this interview round, and I'm really proud of it.
During the entire interview, we maintained an air of directness, of having no filter, and not being afraid to criticize. If needed, we gave them feedback, but we didn't want to spoonfeed them, so we just insulted them sometimes. This made them open up and be vulnerable easily, making it easier to do the HR round. They couldn't fake anything or maintain a facade.
I'm very happy with how these interviews went, and I want to try and experiment with this format and bring elements of it to dev interviews.
Conclusion
This week was pretty interesting, though towards the end of the week I ended up being busy because of work related to my PS-1 internship. Next week will probably be busier, but I can devote more time per day next week I think.
Basically, I need to give more agency to people. I will be doing this, by making Pal the team lead for Rideshare and the Auth service. I don't want to change stuff around too much because it'll take them time to get acclimated. Instead, my plan is that for snap sorter, Aruna is already doing a good job as team lead. For game dev I think I need to make either Pritam or Varun take charge, for Rideshare web, it'll be Pal, and for the flutter part I can make Shubham the team lead. In the future into Year 3, this team will be less inclined to write code, so I'll probably tell them that they can balance code and PR reviews as they see fit.
And well, for feedback, I need to be a bit more open, slide into conversations a bit more with slightly less active members, and I think this will end up working out.
Week 10 of being cruX Secretary
20 July, 2023 - 26 July, 2023
What is this?; What's cruX? What are these blogposts?
Read the last week's blog posts for a bit more context
This week
- Week 10: induct the designers formally, assign them tasks inside the club, start hosting a minecraft server on the oracle instance, plan and hold an infra sprint, write and setup a sample staging deploy pipeline for the infra sprint, assign unit tests to people on chrono, follow up on unit tests, come up with an action plan we'll use for the next few weeks, as we go into the new semester
Feedback
Feedback is interesting. I don't know if I have a good or bad experience of it, but back during cruXipher last year, I complimented Saurabh Atreya about how he handled his Python stuff. There were no hiccups in how he made his question, implemented it, and sent it over. After that, I made him a member, and since then he hasn't worked much, which I largely suspect is because he's busy doing ML project stuff.
But if you take me, I have a good history with feedback. On 25th July, I asked the previous dev sec and prez about how I was doing and received neutral to good reviews. Last year, Srikant told me I handled web dev inductions well. Both these things pushed me to work more.
Praise Motivates more than Criticism
It's very hard to pull off the Gordon Ramsey kinda way of doing feedback. It's fun, an ego kick and whatnot, but it's very hard. Motivating people to do better while also criticizing their work is hard. Rarely you'll see people that don't put in effort into their work. In cruX, it backfires a little. Either people will write good code, or they won't write it at all. Giving people the lightest criticism can be very hard to get them to work again.
I saw this with Anurav first. Anytime I asked him to change something in his PR, he would say things like "maaaan" or "fuck" or "I won't" or "3-5 business days". He gets demotivated fast, because to him, the work is boring. He's more suited for work where he has to be creative, look for funny jokes to write, UI effects that change the page, etc.
It's very simple: say nice things.
Nitpicking a PR we all can hopefully do, but say nice things.
The Echo
In sound, the word feedback means "a screeching or humming sound resulting from the return of a fraction of the output signal from an amplifier, microphone, or other device to the input of the same device."
But often, the feedback we give is not even close to being coupled to the input. What I mean by that is that we give feedback once it's too late. Feedback happens at monthly review meets, and it happens when you're selecting for a new PoR. Outside of this, you have PRs where it's always "fix this."
Feedback needs to be more realtime. I need to consciously make an effort to analyze and comment on every activity that someone does. There is a lot that can happen in a feedback loop.
The feedback sandwich
A funny anecdote I heard somewhere was about how nobody likes Accountants. Have you ever looked at an accountant and thought "man I love that guy?" No. Here's why: They always talk about how you need to fix something. When you have a broken sink at home, you don't want to think about it. You just want to ignore it, go to work, sleep, watch a movie, or whatever. It's some menial work you need to put in to fix it. Same with accounting. Nobody wants to think about fixing these problems.
When you go to a PR, and ask people to fix shit, they hate it, and you will hate the ensuing process. You know why? Because it feels like getting a sink fixed.
You go in, call some plumber, and tell them the problem. Then after spending a few hours or days without a sink, the plumber shows up at an inconvenient time, and then you have to deal with them. They then talk about how they have 2 or 3 options, which you really don't care about, and how they need to get some replacement sink from some hardware store. Then leave, possibly leaving the bathroom in a more dysfunctional state than before, and then come back hours or days later again at an inconvenient time, and finally fix it. Even after all this, the sink looks out of place. The plumber agrees. But, since there's no other option, and this is just the way things played out, this is the solution we move forward with. Nobody's happy, but it needed to be done.
If I haven't painted the picture well enough, let me try that again.
You go to the PR, review it, and tell them that something's broken. Then after spending a few hours or days without a reply, they ping you at an inconvenient time, and then you have to deal with them. They then talk about how they have 2 or 3 options, which you really don't care about, and how they can install some dependency or something, or maybe they ask you to hop on a call. All the ideas discussed in this call are useless, and are all bad implementations. After a few minutes or hours, they leave, possibly leaving the PR, or atleast the idea of what the PR will do in a more dysfunctional state than before. They then come back hours or days later again at an inconvenient time and finally have some kind of solution that isn't utter trash like the one they came up with on the spot on the call. Even after all this, the code feels out of place. The other guy agrees. But, since there's no other option, and this is just the way things played out, this is the solution we move forward with. Nobody's happy, but it needed to be done.
I've seen this situation a lot: especially when working on chrono. We all tried to develop better ways to store warnings, check clashes, or duplicate data correctly so we don't have to make as many DB calls, but in the end, we had something. Everyone did not want that something, but it had to be done.
This is all a long-winded way of saying: not all PR comments need to be: fix this.
I think I have done a terrible job at this and haven't fostered the culture for it.
One diagram that I really like is below:
When I look back at my Open Souce contributions, I realized that a lot of the PR reviews, and Issues and Discussions that I was on, had a lot of praise on them, even if it wasn't warranted. The people being so nice made me want to work more. I need to do this at cruX more. Instead of just "LGTM, merging" maybe I could take some time out and give my thoughts on the code quality. Maybe I could comment on how stuff progressed on this PR. I can do a lot, just using those PR comments.
Teaching
I love teaching. Obviously, I get burnt out and I lose all faith in humanity every time I hold a workshop, but I keep coming back. I feel like it's still worth it. Even if the workshop helps one or two people, it's worth it to me. Think about it. When you're managing a club and need others to know stuff so you can take work off your back, you can teach them. How many of them do you need to replace you? One. The rest are just bonuses. If one person can walk out of an infra sprint being able to write a deploy pipeline, then gg it's done. Now someone that is not you can do that work. You can now delegate work.
I know it sounds dumb, and it sounds like cope, but really, what is your goal when you want to teach someone to replace you? One is enough. At best, you only need two. If you need three people to replace you, maybe you need an ego check.
I held an infra sprint during this week, and it went well. I got to teach people how to write really good infra in the span of 3 hours. 3 hours was excessive, and it went on for about double of the average attention span in that meet, but I did end up getting one person to the point he can write a deploy pipeline, and a bunch others that took atleast something from the meet. This was probably by far the most successful workshop I have taken. I believe it was because of how short it was, how aligned I was to everyone's learning speed, and how useful it was in the moment.
Obviously, these things aren't possible in a normal workshop setting, and are very hard to pull off. I was thinking about holding a web dev workshop for 23 batch once they're here, but someone gave me some nice-sounding advice about how I approach workshops recently. I want to try taking that advice first and then moving on and seeing if I can make it work. Once I do, I will write about it. This can take around an year to get done with though.
Are you on fire?
I think so. I think now that we don't have a working design for ChronoFactorem, even though the backend is nicely finished, I think we're on fire. I don't like how nobody wants to acknowledge it. People here would rather give up than speedrun work on ChronoFactorem so we get it done before registration. I don't like it, but it's the harsh reality.
I don't know what to do to motivate a team to work in conditions like this. I feel like at the end of the day the onus to write the frontend for ChronoFactorem will fall on me, and I should do it. After all, if nobody else will, then who will? Somoene needs to move the club ahead. I don't like it though. It isn't satisfying as an answer. I don't like the "you can't." There has to be a way. Do I have to give speeches like Napoleon or some shit? How do I get these people to move, and be as committed to this goal as me? I don't know. Maybe I'll find out. Once I hit that stage though, I think I will have unlocked the full potential of cruX. It would be a club of people working towards making the campus a better place, and getting juniors interested with unwavering commitment.
Conclusion
Well that was all I had to say for this week. I didn't read much, since I got busy with putting the fire out, more on that next week probably.
Updates from last week: The agency gambit seems to be working, and work on rideshare slowly seems to be going independent of me pushing them. I need to keep doing this with other projects as well.
Things are going well as usual, and I think they can be even better. End goal is a state where everyone will work night and day to get a good fucking release out on time, so other people are wowed by it, and it sparks something in them to start learning more about software development.
Week 11 of being cruX Secretary
27 July, 2023 - 3 August, 2023
What is this?; What's cruX? What are these blogposts?
Read the last week's blog posts for a bit more context
This week
- Week 11: i decided we are on fire, disappeared for 5 days, and finished writing a temporary frontend for ChronoFactorem, held the weekly review meet, had another meet with people that stayed after the weekly review meet about cruXipher ideas, worked with designers to decide on a better style of working for them, got an update from Mudit about the chinese super app, talked to ansh about club updates in terms of what we need to submit to tech senate, and discussed potential judges for the hackathon
Being on fire
I don't know if I convinced myself that we were on fire, or if I just really wanted to write code for once. I am starting to think it's the latter, because even now after the rewrite I have a strong urge to write more code.
This week, since i spent 5 of the 7 days on writing the rewrite, I don't really have much to say.
I wrote garbage code. I feel slightly bad, because turns out the final timetable will take some time to come out.
BUT, in that time, I can work on integrating CMS or other things into the existing chrono API.
I didn't make any progress on the book.
Going forward, I think I'll be heavily focusing on integrations between our projects, and integrations with whatever already exists. I feel like it's a huge boost to usage of your stuff, and once you get usage on your stuff, getting funding for doing fun shit is never a problem, since the SU knows the value you bring to campus.
I've realized its increasingly important to prove the value your club brings to the SU, and we've seen time after time the need for it. I can't elaborate too much, but based on how some things go next week, I'll try and maybe talk about it.
Conclusion
This week didn't have much. I apologize. But again, I need to remember that my goal isn't to write nice flashy blog posts that are fun to read, it's to document my journey as I learn about this shit. I need to read the book more going into the next week, since I'll have a lot of free time away from projects, since I won't be involved in much except coordinating and reviewing PRs, while we decide what our work for Atmos looks like.
Week 22 of being cruX Secretary
18 October, 2023 - 18 October, 2023
What is this?; What's cruX? What are these blogposts?
Read the last week's blog posts for a bit more context
Last 11 weeks
I know the last 11 weeks basically just went undocumented, because I basically stopped writing blogposts. I have a new system to keep myself a bit more accountable, lets see if it works. I'll try it for like a month and if it works I've struck gold.
I haven't continued reading the original book I was reading, the "The Making of a Manager" one, but I realized I can just listen to audiobooks when I'm doing mindless work like washing clothes or walking to some place or something like that, so I started listening to this audiobook for the book titled "How to Win Friends and Influence People" by Dale Carnegie. I know, the title sounds extremely fucking cringe, but the sheer amount of people that have told me to read this book is staggering. I think of all people I have discussed books with, 50% or more have mentioned this book. Now this is downright insane, because first, I don't read much at all, and second, I expect the distribution to be more like 10% of all people recommend book X, then the next most recommended one would be recommended by like 6%, then the next one like 3 or 4%, and so on. This book is an outler in terms of how many people have told me to read it, so I decided to give it a try.
Surprisingly, in two sessions of listening to this book, I have already reached page 69, while I've only reached like page 89 in the "The Making of a Manager" book, so I think this strategy is working. I don't want to get too hooked to audiobooks though, because I'd like to have the ability to read a normal pdf that might not have an audiobook. I don't want the audiobook thing to become a problem.
But, I won't let the last 11 weeks go undocumented just like that. I'm writing this quite early into week 22, so I'm hoping if I set aside like 30-45 mins each day, I can eventually go over the last 11 weeks, and analyze some of the stuff I might have done right or wrong. The last 11 weeks were very important for the club, due to the fact that huge mistakes were made in terms of planning, inductions took place, and we had to square with our planning and management issues to decide our plan for ATMoS, the yearly technical fest of the college. In a sense, I am lucky, because like 7 days between Week 21 and Week 22 were midsems, and no club activity really happened. I tried to make sure background tasks happened while midsems happened, and looks like it worked mostly.
I will try my best to do it over the next few days, but I will limit the time I give it, because I don't want to sit one day and finish it all, I want to make it a habit to do this everyday. Accrual is a really cool concept.
This week
- Week 22: contacted the CTFTime team to get cruXipher approved to be hosted on their platform, talked to the App Dev guys to try and see if they could gather resources that we can dump in a post so people learn app dev after midsems, nudged the guys that weren't done writing Round 3 tasks a little bit, got a server provisioned from the CS & IS department for ATMoS and as a server for hosting in general,
Making people feel important
One really cool thing I want to try out from the "How to Win Friends and Influence People" book, is the part where he explains how you can make someone do something.
According to him, the number 1 easiest way to get someone to do something, is to make them want to do it. Very simple. Now, how can you make someone want to do something? The easiest way to do that is to make them feel important. Everybody wants to feel important. Everyone wants to be up on stage being the performer for the audience. Everyone wants to have that confidence and that level of importance. I didn't buy it at first either, but I think I do buy the claim that you can make someone want to do something in more than just one way, this is just one approach that tends to work more.
Additionally, I don't know where I heard this, but I think it was in Bo Burnham's INSIDE. Bo claims that social media blew up because of two things: one is that all your friends are on it, so now you feel the pressure to be on it, the network effect. But, the yellow pages can have the numbers of all your friends, doesn't mean you will then want to be on it, no. The other reason social media blew up so much is because it makes you the celebrity.
Think about it; Pick up all the baby boomers and a good chunk of the millenials too. Most of the people they recognize are Hollywood stars, people in bands, and performers. If you take Gen Z however, I think you'd see a way bigger slide towards recognizing people popular on social media. Now, I'm not saying they only recognize people from social media, or majority of their "stars" are people from social media. All I'm saying is, people today recognize people popular on social media, because social media is popular; everyone uses it.
But, how do you get from point A to point B? How do you become a "star"? In the case of hollywood stars and bands, well, get into the industry somehow, make it your day job, go at it day and night and hope to have the right connections and also be some of the best in the industry, that's how. In the case of social media though, it's a lot more convenient. Maybe it's really not that convenient, and you need to do all the same laundry list of items to get big, but you can gain an easy following of random people just by posting an image every now and then, maybe just a video of something funny, or a cat you see everyday, or fuck it maybe you can pretend to have some kind of political beliefs and you'll find people that way. You don't need to quit your day job, you don't need to be the best in the industry, you just need something. Very easily, will you start feeling important. It'll keep you hooked to the app.
This phenomenon, along with all the examples Dale Carnegie enumerates in the book, is why I now buy that everyone wants to feel important. I feel this need too, I'd be lying if I said it didn't play a conscious or subconscious role in me wanting to become Secretary of this club in the first place.
So, to test this out, I have finally done it. I have imagined someone else doing work instead of me. I sat down and thought of the horrors of me not being the one that does every single thing in the club, and I decided that for the sheer thrill of it, I will do it. I will delegate work, and try and see if I can make people feel important.
I pinged the flutter app devs last night, one active guy, one mediocrely active guy, and 2 inactive guys. I asked them to send resources in the same channel for learning flutter, so we can draft a basic post to encourage people to learn app dev especially right after midsems, and once they're done sending links, I'll get one of them to make a post on Free Expression Group. I know making a post on Free Expression Group isn't much, but I will tell you, it felt nice to make a post about ChronoFactorem in the town square of the campus, despite the state of that fucking project last year. I hope they get DMs and shit, and juniors look at them and think "ooh it's the crux guys." I hope that motivates them a little bit, and makes them do more club work because they get recognized.
I will try and compliment people a bit more during this week, like consciously think about it, and see of that works out, and it makes them want to do more.
Update: So the whole thing happened, and they responded pretty well to it. The inactive guy has started attending meets again, and even asked me stuff after the meet, and has been responsive to an alright degree, I hope that continues. I realize that this won't yield results in the short term, and maybe it's a long term thing.
Recently we got a server at some point, and in every mail I wrote the guys, I've been very nice and considerate of their time (partially because I know how much time and effort one needs to put in to just maintain a server). I've opened with things like "We thank you for your prompt response" or "your cooperation with us", and prefaced emails saying he can choose to respond once it's a working day again, and instantly even though Saturday night the working day had ended, this man resolved my issues at 12:00AM in the night, even though it was a long weekend where Monday was a holiday as well.
It seems to have worked so far, and I'll keep doing it more.
Open with what they're interested in
This is another trick that Dale Carnegie talks about in the book. People's attention spans are small, and if you open with what they want instead of what you want, you can work wonders. If the result is not something they want and it's only something you want, chances are, you are wasting your time by talking to them in the first place.
I did this with last meet. The people that didn't attend the meet got an interesting message that I had never imagined I'd send an year ago.
It started with:
Overall approach
- My overall approach for ATMoS is that I know you aren't too hyped for organizing the event, and I don't want to make you do more work than you want to. You want to have fun during ATMoS and not have to organize a 48-hour event. Based on this, I've come up with a flow to make your experience as smooth as possible, while getting the event done well.
- You don't want to do extra work. This is why, you need to come up with only the idea for questions now, and after quality checking the questions, we'll decide which ones will make it and which ones won't. Only after that, we'll implement whatever code is needed for the questions. You don't want to have your work wasted, and we don't want our time wasted.
- You want to chill in ATMoS and win shit instead of slaving. This is why, let's get whatever little work we have done in advance. I expect everyone to come up with atleast 2 ideas by 22nd October. This way, we can have everything ready for the event by 29th, after which you can basically chill.
- Around 29th, we'll go through the questions with their implementations again, and see if these questions are of good quality. If they are, they will make it to the final event.
- After this, since our only job is to quality check stuff, and make sure all our ducks are in order, most of the work is mine, and you can basically chill for ATMoS.
- We will be collaborating with BITS-SOS as well, so their members will contribute some questions as well.
- We can have our cake and eat it. We can have a fun and free ATMoS, while still having a better quality event than last time, so let's do this.
and then some other details about the work itself.
I was surprised to see, that even people that didn't attend the meet were doing work. In fact, of the 9 people that didn't attend, 7 responded and added something to the sheet. Whether or not these 7 people will contribute good questions is a thing we'll have to see.
Delegating
I think I probably talked about this before, but you have to let go. I talk a lot about it, but I haven't done it at all.
This time I finally did it. It took club members and a senior yelling at me to finally delegate work that I like. I delegated infra to Karthik Prakash, and gave him full range. I think the exmaples that I've set up before for chrono and the infra sprint are sufficient for him to setup a staging pipeline of his own.
I think it'll get done, but it has made my life significantly better. The weeks leading upto ATMoS don't feel like hell and instead it feels like I'm a member.
Though I don't think I'll credit my sanity to that alone. I reduced my expectations for ATMoS significantly and also stopped caring about it as much. If we have the leverage to do things that are fun, then we should use it and focus it to have fun instead of forcing people to work for an event they don't care about, and were never told during inductions that they'd have to do.
Conclusion
I think this week was pretty interesting, since I got a few new ideas and got to try them out. I think next week will be significantly less interesting because the results won't be as ideal as I thought, and it'll make me significantly less optimistic with respect to this. Hopefully I get to read a bit more too.
One day I think I'll just sit and read through old posts and see if I've made progress on any of those, and seen any expected results. I realize it's more of an experiment than roleplay, and I'm still excited for it.