Improving iOS Intangibles with Tactical
In the days of lore and legend that precede my employment, Medium operated under the decentralized organizational philosophy of holocracy. Though leadership has long since shifted to a more hierarchical structure, vestiges of holocracy lurk in unexpected places.
One such remnant is iOS tactical, a (bi)weekly gathering of iOS engineers (for more details, jump to “What’s in a tactical?”). Despite its arcane origins, tactical is by no means obsolete: it remains instrumental to building and maintaining a high-quality app, codebase, and developer experience. I believe that any organization — even one without holocratic origins—would reap the same benefits from investing in regular role-specific tacticals.
Why round up all of the iOS engineers to chat? Since we’re so few in number at most companies, we tend to get fractured across multiple product teams. Team fissures foment communication fissures, which cause important intangibles — a cohesive user experience, a newcomer-friendly codebase, et cetera — to fall through the cracks. Tacticals shield products and interpersonal connections from atrophy.
I aim to demonstrate how engineering organizations can harness iOS (or other role-specific) tacticals in order to advocate for and actualize improvements to their app and day-to-day work. To start, I’ll outline the format of the tactical I run at Medium. I’ll then share three anecdotes that showcase how tactical effected real change. I’ll also expound upon how tactical helps distributed teams foster the greatest intangible of all: community.
What’s in a tactical?
The tactical explainer on the holocracy website raises more questions than it answers, so I’ll start to explain the iOS tactical I run at Medium with what the iOS engineers actually do during it:
- We share high-level details about our work.
- We ask questions and seek help.
- We make others aware of pain points.
- We announce cool things that we’d like the team to know about.
- We propose ideas and solicit advocates and collaborators.
- We commit to taking action before the next tactical.
Addressing these needs in an ad hoc manner may seem good enough, but regular tactical-prompted reflection bands iOS engineers together with the intention/attention needed to foster and sustain a better user, developer, and iOS community experience.
How does a typical tactical play out? I facilitate them using the following meeting template:
I kick things off with a two-part check-in, equal parts “what’s up?” and “what are you working on?” We use check-ins to better orient our team-and-pandemic-siloed selves in the Medium iOS universe, proactively identifying areas of potential conflict or collaboration. I ensure that every iOS engineer speaks during the check-in in the hopes that, once they’ve broken the verbal ice, they’ll feel more comfortable voicing their ideas throughout the meeting.
We continue to set context by taking a look at our latest crash reports, backlog of iOS-specific technical stories, and relevant company dashboards. I file the top crash as a bug in Jira so that product managers can prioritize and assign it accordingly.
We review the action items — tasks that one or more iOS engineer(s) said they’d like to work on — recorded during the last tactical. Were they all completed, and, if not, are they still relevant? We whittle down the list and copy outstanding actions over to the current tactical’s notes.
I then segue the meeting into a discussion-oriented phase.
I gather my teammates’ tensions, short phrasal representations of things that they wish to talk about with the greater group. Tensions tend to tie into one of the bullet points that I listed earlier: Is some class in dire need of a refactor? Did someone learn a cool new functional programming trick? Should we drop support for an old iOS version? Each of these questions merits a tension.
Tensions can be compiled by verbally cycling through participants and asking whether they’d like to share a tension or pass, or by setting aside time for us all to type our own tensions in a shared document. In either tension-collecting process, I aim to mitigate the potential fear of being the first or only person to voice opinions.
We talk through tensions one at a time. I cede the (cyber)floor to the tension’s author and try to shepherd the ensuing discourse so that it culminates in an action item. Not all tensions lead to action items and that’s fine! But the action items that do arise via group discussion give us all a greater stake in the stewardship of Medium iOS.
We conclude the meeting with a check-out. Like check-ins, check-outs grant everyone the opportunity to speak up, but with a different focal question: “how’d this meeting go?” Sometimes check-outs devolve into unrelated chatter, which is perfectly okay: tacticals are as much about team-building as the user-facing product.
Now that I’ve synopsized the tactical’s raison d’être and sketched out its format, I’ll share a few positive outcomes from the iOS tacticals I’ve led at Medium.
The Swift shift
A new iOS engineer at Medium rolled into their first tactical with fresh-eyed perspective: it’s 2019 — why weren’t we writing more Swift? This gave us Medium veterans pause — why weren’t we writing more Swift? — and pushed us to plan for a more Swift-forward developer experience. We committed as a collective to write all new classes, protocols, structs, and other types in Swift.
A few weeks later, another engineer suggested that we use Swiftify, a service that converts Objective-C code into Swift code, to speed up the migration. Despite initial hesitation, we moved forward with Swiftify with the caveat that, since Objective-C patterns do not always align with Swift idioms, we’d have to audit our Swiftified changes individually and through the pull request review process. We all volunteered for another shared action item: convert one or more short (around or less than 150 lines of code) Objective-C files to Swift using Swiftify.
We also updated tactical itself to better suit the needs of our Swift migration period. We tacked on an additional question to the check-in: “have you rewritten any noteworthy files in Swift?” One engineer wrote a script that compared the number of lines of Objective-C and Swift code in our codebase, and generated a new line graph to share at the beginning of each tactical.We were delighted to see the lines inch ever closer to convergence.
Tactical provided that new iOS engineer with a receptive forum in which to express their concerns that, in the era of Swift, Medium’s codebase languished in the land of Objective-C. Without tactical and at another organization, their early feedback might’ve been stymied. What’s more, our shared commitment to Swift engendered opportunities for us work and learn together across team and project boundaries. Synergy and shared knowledge were the stuff of our iOS solidarity.
It’s high time to unify UI/UX
A recurring tension at iOS tactical derives from how we work with designers to turn their mock-ups into in-app realities. Several different tensions have arisen and been quashed with one-off action items. We’ve improved our app users’ experience with a service that ensures developer conformance to the design system via easy-to-use Swift methods; view test coverage for key screens like the sign in/up flow; and a semi-annual accessibility knowledge-sharing session. We also self-organized an internal book club for Thinking in SwiftUI and, after some reflection, started to incorporate SwiftUI into new screens.
However, I must admit that, in its current state, iOS tactical is no match for the massive undertaking that would be unifying UI/UX. It’d take more time and resources than us iOS engineers have available for side projects. When and whether tactical-driven action items get slated into sprints is an ongoing tension (heh) I have with tactical itself. I invite those who try out tacticals after reading this blog post to mull over this challenge with me in the comments.
Meta-tensions aside, tactical gives Medium’s iOS engineers a dedicated time to synchronize on how we build and test new features, which cultivates a more consistent user experience.
What to expect when you’re expecting (a new engineer)
Tactical helps level the playing field for new engineers, seeking their input as soon as they’re comfortable sharing it. I already mentioned that a new iOS engineer propelled us to Swift-first development at one of their first tacticals, but even smaller contributions from newcomers have made their mark.
Last summer, we asked new engineers to help compile a list of confusing classes and components in our codebase. This gave me the fodder to codify an iOS onboarding curriculum, which I then sought feedback on at a future tactical. Six new iOS engineers have since been onboarded with this curriculum, and some of them have even enhanced it after encountering issues.
A few more fledgling changes deserve a mention. Our current move towards a more modular codebase has been spearheaded by new iOS engineers. Some have also used tactical time to clarify our processes: just last month, a recent hire sparked a lively discussion on how we select pull request reviewers. Yet another checked off a long-lived action item by documenting how to manually upload dSYMs files to Firebase when our automatic CircleCI job fails.
New iOS engineers make waves at Medium. While they were all thoughtful and diligent engineers coming in, I’d wager that getting asked to contribute as soon as their first tactical fired them up and quickly turned their proposals into actions. Their early participation also facilitates (if not accelerates!) our team’s transition from forming to storming to norming to actually performing. Tactical makes space for novel takes.
Trust in us
I’ve exemplified how tactical has made meaningful refinements to Medium’s iOS user and developer experience. I’ve also hinted at another intangible that tactical has nurtured: an iOS community.
Tactical empowers engineers to care about things beyond the scope of a single sprint or project, galvanizing them to adopt a custodial mindset towards the workplace (as well as the codebase and the user base). We reach out for help when stuck and make ourselves available when others falter. We notice and celebrate each others’ successes. We assume good intentions when reviewing pull requests. In short, we hold our fellow iOS engineers in high regard. Regularly collaborating in tactical underpins our trust in one another.
Try tactical!
Though no meeting is a panacea for an organization’s needs, I wholeheartedly maintain that engineering groups akin to the Medium iOS engineers — small in number and often divided across product teams — stand to benefit from regular tacticals. As I have illustrated, a well-run tactical enriches both the end user’s experience of a team’s product and that team’s quotidian work. Give tactical a go and follow up with me in the comments to let me know how you like it!
