I just finished writing a year-in-review blog post for the Penn Labs blog. For some context, Penn Labs is a student-run software development group that builds apps and websites to help students navigate life on campus. For the past year, I've been one of the two co-directors of Labs, managing the operations and direction of the organization.
I wrote the year-in-review post as a way to highlight the awesome work the whole team had done this year, and hopefully start a tradition of outgoing directors doing the same in the future. While I was writing it, though, I started thinking about what my personal year-in-review would look like. I've written down my thoughts here, in the form of different lessons I hope to take with me going forward.
Many clubs at Penn operate with a governing board structure. Labs currently doesn't have any sort of student board outside of the two Co-Directors. Because of this, the Co-Directors are directly responsible for everything from managing finances to grabbing supplies for group work sessions to heading up recruiting efforts. All of these are critical to the club functioning properly, but it's also a ton of extremely different things for only two people to juggle in their heads at once.
This year as director really made me realize the power of delegating responsibilities. We're lucky enough in Labs to have a ton of team leads and members who are just as committed to the organization as the directors are. Taking advantage of members' enthusiasm to spread the work around is a really good way to alleviate stress and take some work off my plate.
An example that I've caught myself with a lot is email. We get tons of messages regarding specific products that we run. The directors could worry about all of these, but it's much more time efficient for us to delegate to team leads regarding their product. It may seem trivial and obvious to do, but I find if kind of difficult to stop myself from digging into research required to answer each email we get.
One of the ways to view the director role is as a manager-of-managers. Directors are in charge of keeping up with team leads and making sure they have the resources they need to lead their teams. Something my co-director and I made standard this year was meeting with every team lead individually to get an update on how their team was working throughout the semester.
While these were certainly intended as avenues for us to get feedback, we were sometimes surprised by points that leads brought up in these on-on-ones which seemed relatively urgent, yet were not raised beforehand. It's easy to wonder exactly what we were doing wrong to not appear as open to talk to. However, I think the answer lies more in human nature. When people have issues, especially those with leadership responsibilities, it's natural to try and resolve it on your own. It's up to us as managers to keep in sync with our direct reports and expect that we'll sometimes need to "pull" information rather than get it "pushed" to us. Sometimes, the birds-eye view that Directors have in the organization can be really useful for working through an issue that a specific team is facing.
The need for communication also manifests itself during the recruitment cycle. Directors manage the recruitment process. But it's important before the process starts for us to have a good idea of what individual team needs actually are. If it turns out no team really needs backend web developers, we should think about how and if we should recruit for that role.
Final deliberations and team assignments can also get contentious if talent for a particular role is scarce. It's up to directors to mediate between leads and find a fair solution that everyone can live with.
Think Big Picture
At this point, Penn Labs runs about 10 services across six product teams. Before I was director, I was a team lead for Penn Courses, which solely manages products surrounding course registration. My largest change in thinking going from team lead to director was having to keep the priorities of all the different teams within the organization in mind whenever making a decision. This ties in well with both themes mentioned above. The only way to get the whole picture is to continuously communicate with team leads and general members about where they see their projects going. And the only way to lead a whole organization effectively is to advise leads while trusting them to make the right decisions.
It can be tempting to try and force projects in one direction or another. But I found it important to keep my eyes on the big picture and leave it up to leads to sweat the smaller things. The more minutiae directors manage and worry about, the less context individual leads have to deal with problems that inevitably come up when the directors don't have the bandwidth to handle it.
Maybe not as long as the Long Now Foundation, but thinking on a year-plus time horizon is an important responsibility for directors specifically. Not many software organizations have 100% turnover every three or four years. In industry, it's common to be able to send a Slack message or walk over to the desk of the person who wrote the code that you're now tasked with changing. As a student organization, all our members graduate and move on a very regular basis. It's extremely important that we're able to transfer knowledge effectively from older members down to younger members.
It's up to directors to remind developers and leads of this reality. Documentation is always in the back of my mind. Written docs aren't a panacea, but in my opinion, they can't hurt when the alternative is trying to decipher code written years before. We've also started asking leads in their one-on-ones to make sure they have at least one younger member in mind to mentor and ultimately to replace them.
Recruit with Intention
In my opinion, recruitment is the most important job that directors have. Considering that the 25%/year turn-over rate is a reality that we have to deal with as a student organization, it's important that we take recruitment seriously and look for prospective members who can contribute a ton to the club, both from a technical and community perspective.
Mentorship and Community
This year, we brought in somewhere around 25 new members in the Fall, doubling the size of the club to 50 members total. All these roles were filling needs that teams saw themselves having, especially with a sizeable senior class graduating in the Spring. While team leads definitely had work for all our new members to do, we didn't necessarily foresee the reality that if there was a one-to-one ratio between newbies and oldies, then every oldie would need to be a mentor to a newbie.
There are tons of articles online about the difficulty of scaling company culture. Labs is no different here. We pride ourselves on our sense of community, and our rapid growth made it easier for new members to get lost in the fray.
When thinking big, it's also important to think holistically. There's obviously the need for technical bandwidth, but it was important for us to balance that with our goal to be an amazing and welcoming community on campus.
Prove your Concept
By the nature of the projects we're working on, we meet pretty frequently with school administrators. To me, one of the most interesting parts of the job has been getting to see the inner workings of how the University makes decisions. It's not always the most exciting process, but I've learned a lot through being director about how to get your point across to key stakeholders who don't necessarily need your help as much as you need theirs.
One thing that I've found is that an MVP is a powerful tool. One of the team leads on the Penn Mobile project was able to give students the ability to book Wharton study rooms through our app by reverse-engineering the web-based API. This was super brittle: and any change to the first-party website's flow would break our integration as well. We got in contact with the IT division in charge of developing the room booking system. After we showed them the demand that students had for using our mobile app, they agreed to work with us to build an official API integration. It's not for certain, but I really believe that showing that our reverse-engineered solution was popular was a big part of us getting our foot in the door in those discussions. A cold email can certainly go a long way with the right recipient, but showing that you've already put in sweat to start solving a problem can really get your foot in the door.
Obviously, a lot of what I wrote about above is particularly relevant to leading Penn Labs, and maybe slightly more broadly, to leading a club at a university. But I think I've learned some more generally applicable things about leadership along the way.
If I could sum it up in one sentence, I've learned that a big part of being a leader is being proactive: reach out to reports to check in; take the initiative to prove out ideas before pitching them to decision makers; think ahead and anticipate challenges to confront them head-on.
I've loved being director. It's helped me give back to an organization that has been a huge part of my college experience. I've still got a year left in the club, and I'm excited to see where it all goes from here.