Constraining Yourself Into Success
I was an undergraduate researcher in a graphics and animation lab. It was mid summer and one day around noon my supervisor stopped by to tell me it would be good if I could keep core hours and actually like, you know, show up between 10–4 each day.
Apparently me dropping by twice a week and half the time sleeping on the couch all afternoon wasn’t the type of behavior he was hoping for when he generously offered a position to an 18 year old who could barely navigate the Windows start menu let alone code up graphics experiments.
I wanted so badly to be great, I knew I’d be amazing — after all, my grandmother had promised I was uniquely intelligent. In reality though, I couldn’t figure out how to do anything other than a lonely all nighter each week fueled by the 24hr coffee shop before the meeting where I showed the bare minimum progress to go back to my afternoon naps. I told myself it was because I had just gone through a breakup, because I should know how to do this without help, that I’m just 3 hours of focus away from catching up (surely those other people working every day just didn’t have my crazy all-nighter productivity), that tomorrow I’d actually focus, but tonight the sitcoms won’t watch themselves until 6am.
It took me years to realize what I actually needed — I needed constraints.
I wish I’d figured that out long before. I might have been able to avoid the conversation informing me that next summer I should kindly find things to do other than not showing up to my research position. My colleagues now balk when I claim that I’m still the same kid in search of constraints. I’m productive in their eyes (hooray!), but they don’t see all the things I do to achieve that outcome.
I operate best under constraints. So do most people. It goes way beyond procrastination. A lot of the work I do now as an engineering leader is offering ways to constrain things for both myself and others so we make progress. Learning to do so is a skill I find myself teaching others these days to level up their work.
Alright, let’s get into it.
Tales from a procrastinator
I’m pretty intentional about how I structure work so that I make progress. In the same way hoping you’ll have self control and stop after only 2 minutes of phone scrolling ends yet again with numb legs on the toilet if you don’t intentionally delete the app, overcoming procrastination is about taking the actions to set up the right constraints for future success, not praying that tomorrow will magically be different.
Sometimes I fall off the wagon and come to weeks later not having made progress on much of anything and strap myself back into the habits where I’m most productive. Here are some of the things I do:
1. Set public accountability: Whenever I set out on a task, I’ll estimate the work and then I’ll tell others publicly when I’ll have it done by (eg in a very public slack channel). I usually aim to beat that by a few days because otherwise I wait until the last minute and invariably blow my deadline.
This applies even more so for tasks where I’m not directly building features, where success is more ambiguous — which constitutes most of my work right now. I take steps to set public accountability regularly. Right now I do my best to keep a habit of sending out my priorities for the week to my stakeholders, and I follow up with which I accomplished.
I intentionally put my reputation on the line by doing this, which personally improves my odds of success by about a factor of 10.
2. Write it down: There’s a lot of stuff to do, and it turns out I’m quite bad at doing 2 things at once. I often catch myself running through the list of things I need to do over and over in my head and realize just holding that list in my brain is eating up like 50% of my thinking power. I quickly endeavor to write everything down. It’s the equivalent of closing a pile of browser tabs to get the rest to speed up.
I live in lists, and I’ve experimented with many, but the ones that remain most productive for me are analog.
My best purchase last year was a huge whiteboard for my office. Get the stuff out of your brain. Write down the list of stuff to do to go from here to your objective. I similarly aggressively use slack reminders for anything that’s a “not now” problem, but I know I need to followup anywhere between 20 minutes and 2 quarters from now on.
I use digital lists for things I need to share (eg a project breakdown for a colleague), and I use analog lists for my own use. I’ve tried slack DMs to myself or documents but invariably having to tab about my computer to access the list means I get distracted and lose focus. So physical lists it is for me.
3. Break things down: Whenever I notice I’m struggling to start something, I’ll go break it down further from whatever I’d already written down. This gets into the mundane level for anything I’m not starting on properly. You can see in the list above I’ll get into as simple tasks as “create feature flag” or sometimes “make folder for code”. Anything to turn it into a series of super simple things I can execute against. It takes a lot of thinking (often repeatedly) to execute on “make progress in graphics research”, and I failed at that task every week. I fail a lot less often at “create a folder”.
This exercise also forces me to be a lot more realistic in my goals. “I’ll run a marathon in 6 months” lets me procrastinate until the last month where I’ll just jam in my training because that’s only one item on my todo list. Surely I can do one thing in a whole month. It’s quite different psychologically for me to plan out the 2% increments to get to marathon shape only to realize I actually need to start pretty soon. There’s no way I’ll get 100 sessions done in one month.
4. Commit to not working: One of the key things I do is commit to not being productive. If I don’t do this, 2 hours from now is where all my work conveniently gets slotted in. Sleep? I can catch up on that on the weekend. Date night? Surely my partner will understand, I have work to do. I often tell my colleagues now — work when you work, don’t when you don’t. That separation helps keep me on track when I’m actually working, not to mention being more creative at work after stepping away from work.
5. The best way to start is to start: This is probably the phrase I’ll put on a plaque on my wall someday. Whenever I’m struggling to start on a task, I find the easiest 5 minute (or shorter) thing to do. That might be jotting down an outline for a blog post, or just creating the doc for those performance reviews I need to write, or finding the file I need to edit for a new feature. Most often, after I’ve started for 5 minutes, I find myself 2 (or 6) hours later, still productive. It gets me into the zone. I repeat this to myself about 10 times a day — just go start. The best way to start, is to start.
All 5 of the above tactics in one way or another are intentionally designed to constrain my options. A lot of them constrain which task I should be doing next and bring clarity there, but many of them in fact constrain the amount of cognitive complexity I face at any given moment.
Thinking Less is Easier
A huge component of engineering is structuring work such that we can think about fewer things at once. This is true not just in our processes and project management, but it’s the philosophy behind most software infrastructure too. The whole point of infrastructure of almost any kind is to offer an abstraction where you can use a concept without needing to keep the details of it in your head.
It’s the same concept behind the classic experiment offering more jam options. When customers in a supermarket were offered more options, they sampled way more, and purchased way less. As humans, when we’re faced with many options we clam up worrying we’ll make a sub-optimal decision and end up struggling to make any decision (gasp!).
Even the underlying principle behind code quality is to enable you to parse through code and reason about each piece separately. We set up our code and infrastructure such that you have fewer options and a clear path to achieving most of your day to day goals when building features.
The Jolt Effect has similar ideas in the sales domain. A constrained space is one in which we can clearly choose between the options to actually make progress. High performing sales people have a knack for identifying when a customer is overwhelmed and offer one or two good paths forward.
I often find myself advising colleagues stuck in the space a project could be, and help them structure those projects. I leverage experience to add guardrails that are likely to be correct and allow somebody to think about less things at once.
Those guardrails come in different forms. Sometimes they’re crisp problem statements, sometimes they’re relatively constrained specs to explore within open ended domains, and sometimes they’re clear timeline expectations so an engineer can easily know what to work on next or what type of solutions they should consider. Communicating ”this is probably a 2 week thing and not a 2 month one” will already narrow the options a lot as somebody approaches a problem.
Thank You Management 🫡
I had a friend and colleague a number of years ago who was struggling to be productive at work. The culture of the company where we worked was pretty laissez-faire. 1–1s most weeks consisted of discussing cool ideas while getting a company funded Blue Bottle coffee as you fretted about being a dime a dozen pair of nerds prancing around with clear evidence you might not be as unique as your grandmother promised.
Notably there wasn’t much in terms of daily structure. We kindly inquired in uncertain terms each week whether progress was made with ever growing internal disappointment over the lack of any results, much the same as my undergraduate supervisor must have felt. My colleague was much smarter and more technically competent than I was — and he ended up fired.
As the story goes in Silicon Valley, he failed upwards and quickly got another job doubling his salary (I’ve obviously been trying hard to get fired at every job since). Early at the new job, his manager and him aligned on a list of tasks, and then the following week his manager very simply asked why they hadn’t all been done. As obvious as this seems, it was eye opening for my friend. You should do the things you said you’d do. Clear constraints. What a refreshing thing compared to the prior job’s ambiguous hope that he’d produce something of note in the indefinite future.
Most software engineering teams invest heavily in processes that default to having accountability in place. We have stand-ups multiple times a week where you’re expected to show output, your team lead or manager will stop by regularly to ask if you’re blocked and ensure you’re making progress, you have project status updates where you’ve publicly announced when you’ll have something done by, etc. Even for more research oriented tasks, we endeavor hard to make the next deliverable crisp and accountable.
It really only struck me years later just how different this was than the undergraduate research lab I was in. As your career grows into leadership roles, there’s less structure out of the box and you’re expected to have learned to constrain your own work by then, but it’s really quite impressive how much machinery is in place so that as you walk onto most jobs, there are very clear constraints. You know, management stuff.
We operate best under constraints, and it turned out for me personally, I struggled to be productive under the structure of a single 30 minute meeting once a week with my supervisor. I think back now to my lab mate who was the most productive of the group. He had worked in industry for a number of years and had clearly learned to constrain his work properly (not to mention he knew how to do more than open the Windows start menu).
The Best Way to Start, is to Start
It often takes a lot of life experience to internalize things dead obvious in hindsight. After deep reflection, I’ve concluded the thing most correlated with my producing work, is actually working. The key has been figuring out how to constrain myself into, you know, working.
At the start of my career, I needed somebody else to give me the constraints to operate under, and the journey to leading larger and more ambiguous problems is learning to find the right constraints for any problem at hand. I give problems structure so that myself and others can flow through them with forward momentum. We all operate best under constraints.
I unexpectedly bumped into my undergraduate supervisor in the airport some months ago. With the same charming affect as ever, he insisted he didn’t recall firing me, simply having nudged me towards finding something I was passionate about. I guess that’s why it took me years to conclude I’d been let go. A great manager knows when you’re not in the right role for you and helps you find the one you’re meant for.
I’m incredibly grateful for that now and still have fond memories of my time making slightly blurry images zoom towards bored research subjects as they wondered why they weren’t getting paid.
I love what I do now, and I’m good at what I do. To all my fellow colleagues who also struggle to get going — remember — the best way to start, is to start.
