How We Work

Learning Cycles

We work in 6-8 week learning cycles at ARMA Courses. Typically six cycles per year - two 8-week summer cycles, four 6-week regular cycles. This cadence provides urgency, scopes project size, and gives regular intervals to evaluate what we're working on.

The idea isn't that everything must fit in 6-8 weeks. But we think about breaking big projects into smaller chunks that do fit. We bundle smaller efforts into presentable 6-8 week units for discussion.

This matters most for course development. We designate efforts as 1-week small features or 6-week big ones, avoiding scope creep. Work has a budget, focusing discussion on what's reasonable. If a project slips its budget, we scope hammer first rather than just working more hours. Most work fits in a normal or summer cycle.

Cooldown

Between cycles, we spend two weeks cooling down - dealing with bugs, writing up work, and deciding what's next. It's tempting to extend cycles into cooldown, but we try to resist. Think of a cycle's end as "pencils down" - winding down, prepping launches, etc. By week 4, we should prepare for launch.

Communication

It's hard to keep up with everyone's work just reading the activity stream. Instead, we have four main ways to stay in sync:

First, daily "What did you work on today?" updates. Great for starting conversations about things you want to learn more about. Answer at least twice a week.

Second, weekly "What will you work on this week?" previews. Everyone except OMG answers when not out.

Check-ins are divided by team so you only get your team's posts, but can subscribe to others.

Third, team heartbeats - "What did your team work on this cycle?" summaries written 1 week after a cycle ends.

Fourth, kickoffs - "What's your team working on next cycle?" plans before a new cycle starts.

This approach allows individuals and teams confidence to operate independently most of the time, coming together at set intervals to decide larger directions. With clear communication expectations, it's easier to build trust.

Posts go in the What Works project for that year.

Pitches

Even if you're not on course development, your observations can shape what we work on. Pitch feature ideas, changes, or anything you think we should consider in a detailed post (the more specific the better). This allows full consideration and discussion, with a reference-able artifact.

There will always be more pitches than time, so manage expectations after posting. The default is that the product team will read and consider your pitch - already a win. Even if not fully implemented, it can illuminate weaknesses.

While some pitches may be instantly compelling, most will wait as there are always more ideas than time. Don't be discouraged if something sits for cycles before happening. Many pitches wait years before coming together.

Asynchronously

With people working varied hours from varied places, we can't rely on constant contact throughout the day. Most work at ARMA shouldn't require immediate back-and-forth all day.

It's better for focus if we collaborate as if things will get answered eventually, not necessarily right away. Post messages, to-dos, and docs explaining needs instead of interrupting people's flow. Read and respond when natural lulls allow it.

This isn't absolute - sometimes extended real-time collaboration is needed, via screenshares, hangouts, or even in-person. But most of the time it's not. Still, ensure ample overlap with your close collaborators. Most roadblocks can be cleared in 15-60 minutes, but not if it's a one-day turnaround each time.

Some departments like Support rely more on available, interrupt-driven work. What applies broadly may apply less there.

In Self-Sufficient Teams

We aim to be more project-driven than functional. Product teams should go from idea to deployment independently.

The fewer departments to pass through, the better. We should remove natural roadblocks between strong departments like product, engineering, QA, etc.

A course feature team should be able to integrate and test native app work without Mobile team involvement unless needed. Mobile shouldn't require special heads up or feel guilty about lack of participation.

An API change should be handled directly by the native team needing it.

Staging environments should be self-service, not requiring Ops. Have scripts anyone can run to restore databases instead of waiting.

This isn't avoiding asking colleagues for advice. It just shouldn't be a required step to improve ARMA. Bottlenecks like features waiting for "mobile integration" lead to detailed scheduling and dependencies. That's a poor fit for us.

As Managers of One

We rely on self-management. Those exhibiting this fully are managers of one - setting their own direction versus waiting to be told. A manager of one spends time well independently, always finding more work to do and improvement to make.

Balanced

We limit to a 40 hour (32 summer) work week, forcing prioritization of truly important work. Healthy sleep and rewarding life shouldn't be sacrificed for a few extra work hours.

Sometimes off-hours work is required for on-call, maintenance, or emergencies. This shouldn't be additional to normal hours - use discretion to take off time elsewhere in the week to make up for it.