Term Kickoff Meetings

Drew Leske

The ARCsoft team has been an actual team (not a trivial team of one) for a year now, since we hired our first co-ops in September 2022. In that year I’ve learned some things and tried some things, some of which worked, some of which didn’t. One of the more successful initiatives is the term kickoff meeting.

The first kickoff meeting was held in May. At that point two co-ops had finished their terms, one was on her second and a fourth was just starting with us. I scheduled it for the second week, which was probably because I didn’t think of it until the first week. It was a fairly informal affair: there was a slide deck, mostly to keep me on track, I ordered in pizza, and interruptions are encouraged. I booked a small conference room for the day.

Purpose

The primary goal of this meeting is to give team members a foundation in who we are, where we fit in the organization, what we do, who our clients are, and promote engagement in all of these things.

Previously students would show up on their first day, and I’d show them around, go over the team norms and practices, talk about the basic expectations, and take them for coffee. After that I’d leave them to pick up the rest as it came up, one way or another. This–okay, it’s pretty obvious when I write it down–left some pretty large gaps in the students’ knowledge of what it is we do and why.

Engagement is critical for any team’s success and I believe this forum gives that a little boost by providing the students an early opportunity to discuss the team’s practices and values: essentially, in their second week students are asked to help define the team.

I tell my co-ops I hope they learn a lot and grow professionally, but also, I want to learn from them, and I want their comments and recommendations. These are teammates who have training and experience which is two decades fresher than mine. By engaging them in this way on such fundamentals it may shorten by weeks the length of time some student will take to be comfortable enough to say, “Hey, our Git workflow is kind of clunky.”

Structure

The first part is basically a relaxed lecture as I take them through the history of research computing at UVic (as I know it) and our place in the larger group, the department and the institution. I tell them about the formation of the team and about myself and other teams in Research Computing Services. By the end of that it’s usually time for a break–the subject matter, though important, is rather dry, and by that time so is my throat.

We then move on to the team’s purpose. An HR course I took earlier this year about building strong teams used an interesting talk on fundamental questions of purpose, and we use that as a starting point for a discussion of why we do what we do, with me scrawling our thoughts on the whiteboard.

After discussing purpose we move on to team values. This is another brainstorm with me writing things down on the whiteboard: what values we bring, and ones we need to live more fully (I don’t usually put it that way, ick). I’ll get into those later.

After this part, which for some of us, definitely me, is not completely natural and comfortable no matter how important we know it is, we move on to some team practices and norms: how we use the tools we use, our practices, down to how often we hold meetings and whether we need less or more.

Next is a description and discussion of the technologies we use within the team, hopefully that each co-op will get their hands on at some point, and we finish off with a description of the projects on our books and their status. Although I’m the only team member who touches all the projects, it’s good for the rest of the team to have context when I’m describing those projects in standup, or if it comes up otherwise. And hopefully every student will get a chance to work on a few different things, although that hasn’t always been the case.

Somewhere in there we’ll have a pizza lunch. All told it winds up being about five hours though I block off the conference room for the day (note for next time: see if I can get a conference room with windows).

Outcomes

These meetings have been successful, both times we’ve had them. The early opportunity for engagement at the team foundational level is key and I’m glad it didn’t take me even longer for it to occur to me to carry these out.

Team purpose and values

The video we watched talks about how most companies describe their purpose as what they do and how, but the real purpose is the answer to “Why?”

Our purpose is to help researchers, and to do our part to advance research.

Discussing and stating team values is important as it helps us decide as a team how we’re going to fulfill that purpose, and how we’re going to relate to others as we do.

I create a table with two headings: what we have for values, and what we need. Here’s what we came up with:

What we have

honesty
teamwork
communication and openness
accountability
kindness
respect

What we have but we need more of

engagement
reliability

I can’t stress enough that these came from the team, not just from me (well, the last two are from me because I recognize I need to be better at keeping in touch with some of our clients).

Workflow and meetings

The team’s Software Development Guildelines go some way towards establishing basic practices but here we discuss everything we do on the day-to-day, from how we handle merge requests and code reviews to whether the daily standups are working. Generally things are working fine but a couple of suggestions or requests have come up.

Code reviews need to be more timely. This was raised last term as merge requests were sitting for longer than they should have, and by the time it was handed back to the author, the code wasn’t as fresh in their mind. I now get to reviews much earlier (except blog posts, but I’m going to be better about that too) and have since also started having the other members participate, so they’ll actually review eachother’s code before it gets to me.
Design reviews would be useful. So far we’ve done this very ad-hoc and only when I had a particular idea I wanted to get across, or if a team member requested it, and apart from that, there may be hints or tendrils of design in other discussion.
Implementation of a staging branch as an intermediate step towards production. In our projects, the staging branch will be our main branch, and once code is merged from a feature or update branch it will then be deployed to the dev site where the clients can play around with it. Once everybody’s happy the changes will be merged to the production branch, and from there automatically deployed to the production site.

This is similar to what we were doing before and I’m not sure whether there is any benefit: what’s deployed to main always gets deployed to the dev site, unless it’s tagged constituting a release–that’s what gets deployed to production. It took me some time to wrap my head around it, but what’s really important here is for the clients to be able to see and play with the updates as soon as possible, so what I took away from this is, merge stuff sooner rather than later. It needs to be tested and reviewed, but we can merge to main before the client is ready to sign off on it–after all, we track acceptance in the GitLab issue, we don’t need to reflect it in the merge request. (We haven’t been, but this is sort of an internal clarification.)
We need to review the software development guidelines. I made a note to create a task for each of us to revisit them. Then it turns out I made exactly this same note last time we had this meeting, and never did it. Facepalm.
We discussed one-on-ones, maybe once every two weeks, which I’ve done a couple of times previously and am reminded to make regular. I also suggested maybe a team meeting every month for general catchup, to revisit some of the material from this meeting, and just stop and take a moment to shift our perspectives.

Interpersonal

This time around I had a slide on me as a person and the idea was to get everybody to do that, but I did it at the last minute and told the team they could do theirs later once they’d had a bit of time to think about it. This was not well executed and it was probably a mercy I forgot. I will do something like this next time with a little lead time for the others to figure out what they want to say about themselves.

On the other hand, we don’t often sit together and eat lunch–well, never. Once the pizza arrived I told Nick and Karan that they could relax, catch up on whatever needed to be caught up on their phones or whatever, but we wound up chatting, and learned a bit about eachother informally.

Final thoughts

I’m going to keep doing these, and I look forward to seeing how they’ll evolve with the team. What has worked twice might not work two years from now, but I hope these meetings continue to help us build a little team cohesion into what’s, after all, a pretty short time together.