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.