How OSSTP built an effective developer team
OSSTP is an acronym for Olin Satellite Spectrum and Technology Policy, a research group of 20+ undergraduates at the Olin College of Engineering. I joined in January 2023 and began working on the data scrapers team and SWARM-EX.
Many people who write about team culture are wrong about how to build it. What they actually talk about is how to maintain it.
Building a culture isn’t about repeating the mission and values of a team until it becomes a habit or scoring well on culture assessments. It’s about action.
Two things specifically, the pace of upward action and the percentage of people taking action. The pace of upward action generates the question, how fast are we progressing? The percentage of people taking upward action asks, how many people of the whole contributing to our progress? Both of these are simple to measure, which makes them diagnosable too.
In technical teams like OSSTP’s data scrapers team, whose goal is to scrape every satellite filing (experimental and IBFS) since the FCC began and perform data science on their database, the number (and speed) of commits on roadmap tasks is a solid metric for the pace of upward of action. Commits can be anything from new code to bug fixes but represent movement towards a project’s end goal.
The important thing is that commits are “upward.” Some weeks will be fast, and others slow, but if there’s one thing to avoid, it’s going backward. This usually happens when previous steps must be redone because a developer’s code is too buggy or unreadable. We integrate comments and tests into the developer’s main coding workflow to prevent backwardness instead of keeping them as separate steps.
Upward action is sometimes difficult in teams who haven’t worked together. But, this wasn’t a problem for our team despite only working together for a month before the summer. We began work on day one because we had a paper submission deadline on August 1st. We didn’t talk about values or establish a culture. The culture manifested because we instantly took upward action on our summer goal: finish scraping all experimental data from the FCC’s database by August. Everything we learned about why our team works stemmed from acting.
In hindsight, skipping this step during team formation is better. Culture is a shared way of doing things, so this can only be figured out if the team has worked together. It was also better because we were searching for our identities as developers as much as we were searching for the team’s identity. Setting a culture without understanding ourselves or how we worked together felt superficial.
This is a new learning and contrasts how I set culture at Beru, a project I worked on in the summer of 2022, intended to help elementary school students master literacy with augmented reality. As soon as I recruited the four members of Beru’s team, I wrote a four-bullet point Slack message detailing the values of our team. I mistook my values for the team’s values, and the feeling that decisions about the team started and stopped with me never faded.
While there are many differences between Beru and OSSTP, even if we’d taken an alternative approach where every team member contributed a value or stated the culture they want, a problem remains: deciphering between virtues and values. An example of a virtue is “doing the right thing,” but it’s surprising how many companies have “do the right thing” as a value. This is a symptom of setting values too early without understanding the people you work with. If you knew the people on your team, apparent things like integrity wouldn’t be a core value.
To avoid this problem, I recommend setting a culture after your first project milestone. In Beru’s case, this was demo day. In OSSTP’s case, this was after submitting our TPRC conference paper. This gives teams a few weeks, at minimum, to act together (culture) and learn about what traits make their team effective (values). This is helpful because the discussion after the first major project will include examples about what made this team successful instead of reflections on a past team’s success.
With this model in mind, if I were to sit down with the two developers on this summer’s data scrapers team to brainstorm values and reflect on what made us effective this summer (culture), I’d contribute the following three traits.
Trait 1: Our dev team was three people
There were two reasons for our size. The first was preference. None of us wanted to manage; we wanted to build. The second was practical because every developer communicated with each other when making decisions about the next steps or current implementations; our communication grew quadratically. Mathematically this means that each additional member of the team increased complexity by the proportion to the square of the size. This implication is n² the questions, documentation, coding styles, and learning lag time.
Knowing that quadratic scaling was nonoptimal, there was one question we needed to address. When would we hire a new developer? And how would we know they were required?
To answer, we inverted the question. What would we not hire a new developer for? Skill deficiencies or long hours.
Our team was fortunate to have a lead developer who was technical and industrial. He’d worked with the programming languages and tools needed for our project, so if we had a question about implementing something, he was available to talk it through. If he didn’t know, we’d figure it out. PDF parsing was a trouble area for us. None of our original ideas worked, nor did the packages we tried. But, we had confidence in our decision to write a custom parser, knowing we’d tried every open-source package and cloud service on our data with little to no success. And to do this task, we brainstormed ways to do it ourselves, not thinking for one second about hiring outside help.
Long hours were built in, and we enjoyed our work, so the burden was minimal. Our condition was if multiple people were working overtime consistently, we’ll consider hiring another developer.
Trait 2: We wrote decision documentation
80% of our code includes a comment, and every package or programming paradigm decision was logged in decisions. md. We logged what decision was made and why we made it. This file was intended to reduce the number of questions another person asks and increase the time they spend developing. Returning to the quadratic communication in trait 1, every time a developer would ask another developer why they did something, it would take focus away from both people. If this was done for even 10% of a developer’s decisions in a file with 100 lines of code, it would remove at least an hour. 30 minutes in the discussion, and 30 minutes to refocus.
Trait 3: Same titles mean everyone’s incentives align
One of the traps developers at companies fall into is the promotion ladder. It causes them to move their focus from their core project to promotion-approved projects like making programming libraries.
Everyone in our lab is titled “Undergraduate Research Assistant,” except the Lab Manager, who runs the weekly meetings. Because our titles are the same, there’s nothing to fight over; everyone focuses on their work.
In practice, this is somewhat unrealistic. There are practical reasons teams have different titles and hierarchies. And attracting people who don’t care about their title but their work is also difficult. It works at Olin because the admissions process is intensive and intentionally selective. It includes flying out top prospective students on three separate “candidate weekends” filled with team games, interviews with current professors and students, and meetings with the admissions team. This helps solidify fit and prevents people with misaligned incentives, usually people with egos or status chasers, from joining the school.
In addition, the students who join OSSTP self-select because they want to learn about space technology or build a skill the lab focuses on. Their primary driver is learning, just like everyone else in the lab.
My observations from this summer treat culture and values as something to figure out instead of something to know at the beginning of team formation. Not only does this hit the elements of inclusivity and trust that culture builders write about, it stems from action instead of talking so members can share sufficient evidence for why a culture or value makes sense for their team. Our biggest favor to incoming team members of OSSTP or data scrapers is to help them contribute to upward action on their first day so our culture remains “built on action.”
Thanks to Heya Desai for reading drafts of this.
