It Could Be Anything and That’s Terrifying: How to Use Project Constraints

We do a semi-institutional event called a “KalaSalon,” where a few of us talk about what’s on our minds, and how things relevant to “work” are relevant to “life,” and vice-versa. It’s part of our whole west coast we’re-holistic-let’s-see-what-works deal. During our last KalaSalon, I talked with Jr. Developer Katy Pool, Sr. Developer Rob Loach, and Sr. Interaction Designer Thiago de Mello Bueno. We ended up on the subject of “constraints,” and how they’re useful in all kinds of situations. As the facilitator of this chat, I heard some themes/lessons that people outside of Kalamuna might relate to and learn from, so I’ve summed them up here.

Give Yourself Deadlines. Obviously.

Jr. Developer Katy Pool helps support our clients’ sites. As part of that work, she comes upon situations in which she sees endless opportunities to improve something for a client. During our chat, Pool said, “You can spend endless time hashing out how to do it, what the requirements are, etc., but at a certain point, you just need to get the thing out.” We talked a bit about what that’s like, and Katy shared her methods for wrangling potentially open-ended tasks: "‘We need it by Monday.’ OK, I’ll do what we can where it meets their requirements. Having a deadline limits the scope of what we can accomplish, but it also ensures that we actually have something, a fix or an improvement, to deliver.”

Easy. Simple. Give yourself boundaries.

Impose Your Own Prompts.

Katy is also a writer, and our conversation led her to talk about her creative work. “This talk of constraints reminds me of stuff I do with my writing group,” she said. “We do freewriting, where you take a prompt and write whatever comes to mind. The more you’re constrained, the more you can get out of it. Once, we got a map of a fake town, and whatever we were going to write had to take place in this fake town. The town had a bar, a river, and that was it. All our stories had to fit within these constraints.”

Designer Thiago de Mello Bueno chimed in with an example from an improv acting class on how prompts can inspire: "The teacher gives you a start: ‘hold a banana’ Now what are you going to do? It’s gotta be about the banana.” Prompts. Make 'em up if you have to.

Say No.

We talked about other ways to give focus to a project. With web projects, more often than not, we’re working in teams alongside external stakeholders who may or may not understand the time and energy it will take to accomplish something. Sometimes the way forward isn’t to negotiate, but simply to say “no." Thiago summed up a typical situation:

You have three days to do a good thing. We need limits on things we will do and things we won’t do. It’s such a giant part of the design process. Everyone wants it to look great and have it be considered and get it in time, but there’s always the question of, “OK, it needs to be done by Monday.” You’ve got to decide things like whether or not we’re going to crop artwork, touch UX, etc.

Others in the conversation agreed that depending on your discipline, you may be the only one who knows what it will take to do a good job on a certain part of a project.

At this point I added my thoughts about saying “no” in more personal situations. Myself and many people I know are more politically involved now, and we can’t go to all the protests all the time or make all the phone calls all the time. We’ll burn out. If we want to be effective, we need to be in for the long game, and that means focusing on a few tasks or projects instead of hitting All The Things rapid fire-style.

In sum, pick the things you can work on. And that usually means un-picking other things.

Impose a Retrospective Schedule.

It’s common knowledge that you can learn from your mistakes, so why not make a point of looking back and asking yourself how you did, on anything? Senior Developer Rob Loach talked about “the retrospective” applied to “life:”

One of my secrets is that I scrum my life. I scrum my relationship. Every two weeks, my partner and I sit-down and have a retrospective on what’s been going on. We talk about what’s been bad and what we can do better. Like, if I see that she has a goal of doing something in two weeks, I’ll tell her she didn’t accomplish the goal that she set for herself.

Imposing a “retrospective” might seem like a no-brainer for Internetty folks accustomed to working on “agile” projects, but not everyone institutionalizes learning reviews in their endeavors. Whether you’re creating an editorial calendar with a team or remodeling your kitchen, putting time on the calendar to look back helps you integrate what you’re learned.

I myself have integrated all of these lessons, and have thus become a higher-functioning person. Faced with the task of writing a blog post, I set up the subtasks of scheduling our KalaSalon and establishing draft deadlines. Next, I invited people to participate. Then I created a prompt for the discussion, although I don’t remember it now. In order to keep the conversation focused and intimate, I said “no,” in a way, by limiting the conversation to four. Then I “retrospected” in the form of this post. Self-improvement complete.