When it comes to matters of policy, our goal at Atomic has always been to provide “just enough” to avoid unexpected conflicts or confusion. We rely strongly on personal responsibility, transparency, and our self-organizing nature to bring order and direction to our projects and internal company workings.
Atoms enjoy the freedom this brings—we share the burden of learning and making things work the way they should without being bound by miles of policy red tape. We have to live out our “Own It” value mantra.
However, there is a potential cost for this freedom: decision fatigue.
In decision making and psychology, decision fatigue refers to the deteriorating quality of decisions made by an individual, after a long session of decision making.
We make a lot of decisions every day. How should I implement this feature? What test cases do I need to cover? Should I spend time refactoring this area of code? What should the behavior of this button look like?
Policies in the right places can help reduce time spent making decisions that don’t have to be difficult and instead allow us to focus on more important decisions.
I can hear you griping, “But policies are rigid; we need to preserve personal freedom!” That’s true to some degree—when we make a new policy, I expect everyone to give it an honest try for a reasonable amount of time. There is some rigidity there. However, policies exist to be useful, and our teams frequently revise or remove policies that haven’t proven themselves useful in the ways we hoped. They’re almost always open for discussion.
Following are a few examples where I have seen policies help simplify the decision making process in a positive way.
Development Lead Role
I’m working on a team of eight developers plus a product owner/designer. We operated for several months without formally declaring any developer as “lead”. Relying on the open work environment and our tendency to draw others into conversations worked relatively well, but there were a few cases where spreading the responsibility around caused some decision fatigue (at the least):
- Who should the product owner include in customer meetings? All eight would be out of the question for most discussions—too costly.
- Who do I, as a developer, need to run an idea by to make sure the team is good with the direction we settle on?
- Who has the big picture in mind, in terms of system architecture, deployment, automation, etc.?
Declaring one person to serve as lead has been useful by providing an easy answer to many “Who should I talk to about this?” questions. All of us work to keep the big picture in mind, but now we have one person officially “on the hook.”
SCRUM Practices
In the past, projects I’ve worked on have run a relatively simple agile process. We have a meeting each week to review progress, look at the upcoming week’s planned work, and discuss the budget. Other meetings to work through design discussions were scheduled as needed. Things like SCRUM sounded cumbersome in comparison.
However, with a team of eight developers and a big backlog to work through, it seemed appropriate to bring more process on board to focus our efforts. We adopted a 2-week sprint schedule, specifically scheduled design review and planning meetings separate from our sprint reviews, and more specific cues for keeping sufficient work actionable in the backlog. What once sounded cumbersome now simply helps answer questions that could otherwise get in the way:
- When should I schedule the next design meeting?
- Do we have enough work queued up for the team?
- Should we continue this conversation about an upcoming feature now in this sprint review meeting, or push it off to the next meeting? (answer: push it to the design review & planning meeting)
I highly recommend reading Micah’s post about product management at Atomic for more information about the SCRUM processes we’ve been applying to more projects at Atomic.
Building Our API to Suit Ember Data
Introducing Ember Data to our project was a controversial matter in the beginning. We’ve built projects using Ember.js before, and some of my coworkers had tried Ember Data but weren’t very satisfied with the results (most discarded it eventually).
We decided to make it our policy for this project to build an API the way that Ember Data would want it, even in cases where our preferences and biases steered us in another direction. Our Ember app is the sole existing client for our API, so it made sense to optimize for that use case. While there was some time spent on learning exactly what it was that Ember Data wanted, I’ll argue that it was quite a bit less than working up some other agreeable structure and building the client-side code to support it. Several months into it now, we’re quite happy with not having to focus much energy on getting data to flow between the client and server—for most cases, anyway. We’re able to focus more of our time on design decisions that provide more value to our customer.
Git Flow
This is another great example of choosing to abide by a standardized opinion that others have documented and built tooling around rather than spending time developing and repeatedly tweaking our own. Is it perfect? Probably not. But it is “good enough” policy and we’ve found it useful. It has reduced the amount of time we spend making decisions about git branches when starting a feature, publishing a release, or fixing a bug.