(This post is about time and overwhelm. To risk paraphrasing an old Buddhist saying: if you don’t have time to read it, you should really read it).
The Bathroom Problem
When I was VP Engineering at Macromedia, I used to time my routes between meetings so I could fit in a bathroom stop. I actually planned the quickest route so there would be maybe a minute or two for a pit stop. It took me a while to realize this. It was probably on a weekend, spending another Sunday doing reviews, or Board Meeting preparation, or reading product proposals, when it dawned on me that if I didn’t have time to get to the bathroom, something might be a little off. I was not in charge of my time and attention. Which, of course, as an executive manger, was about all I had to bring to the job.
These days I coach VPs of Engineering, startup CEOs and others in the tech industry, and, guess what, the issue that shows up most frequently is overwhelm.
Usually I hear, “yes, I know I need to think about that (strategy, org planning), but there just isn’t the time”. And then I get shown a calendar: day after day of colored blocks from 8am to 6pm or later.
So I learned some things while I was still an exec, and some more things as I worked with my clients: you have to find the thinking time. It’s part of your job now think strategically, to grow your people, to develop culture, to read about other leaders, and to take care of yourself (what Ed Batista usefully calls “Deep Work”).
And you can. The solutions are at two levels: a model, and discipline around the model; and some deeper explorations of why you stay in overwhelm. Both take work, and repeated practice as you transition to really owning your time and attention — by far your most important resources. Ready?
The model is simple, and well-known. Attributed originally to Dwight Eisenhower (yes, that guy), and popularized in Steven Covey’s “Seven Habits of Highly Effective People”, it proposes two axes — importance, and urgency.
Conceptually easy. Divide your tasks into important/urgent, important/not urgent etc etc, and then do the ones that are important/urgent now, the ones that are important/not urgent later, and all is well. Something like this:
But! Everything feels important/urgent in a growing tech company. So how do we use this model to really get a grip?
Using the Model
Use the model as a lens: look at all of your time/attention decisions through the lens of the model, not just your task list at the beginning of a day or week (and anybody that can maintain a single task list for a week has my admiration). Look at emails — label them according to the areas on the model if you can.
Look at calendar invites — can you delegate attendance to that meeting? Can it be shorter? Can you attend for ten minutes instead of sixty? Look at Slack conversations: sure, that chat about code quality might be getting a little heated, but does it really need your attention now?
Be ruthless about what stays in important/urgent: Throw out everything you can. Your bias, and the bias of the company around you, will be to make everything important/urgent. Don’t fall for it. Make a conscious choice to keep something in the red bucket. If there’s not a great reason for it to be there, throw it out.
Schedule the important/not urgent time, always: if you don’t schedule important/not urgent time ahead in your calendar, you won’t get it. So schedule time for next week, and every week after that. You need at least two hours, every week (I know, seems crazy right now!). Some people need more, to let their minds wander, a few will need less.
Defend your important/urgent time: it’s inviolate (unless there’s a genuine emergency, and if there’s a “genuine emergency” every week, somebody — maybe you — is doing something wrong). Don’t allow meetings to be scheduled over it, don’t allow it to be cancelled.
Spot “Productivity Performance”, aka Noodling: noodling in the “not important/not urgent” zone can relax you, help take the stress off. But so can taking a walk, and taking a walk is good for you, noodling isn’t. So watch for “just doing some email” or “catching up on twitter” or “reading a few blogs”. If you are in full attention to those things, maybe they are productive. If you’re browsing, you’re “performing work”, not doing work. Might be better not to work at all and take the weight off for a bit.
Using Your Not Urgent/Important Time
So you got your two hours, and you frittered them away doing email. Bummer. Here’s what to do next time:
Find a different environment: get away from your desk to a different conference room, part of the building, somewhere you don’t normally go. Ideally go outside — find a coffee shop or a park. This signals to your brain that things are going to be different.
Don’t take your phone: we’re all weak, and that thing is like crack. Leave it behind.
Either limit, or don’t use, your laptop: we can think just as well with pen and paper, and they don’t interrupt us every minute or two. Leave it behind. If you need to use it, download Self Control, which lets you switch off a bunch of sites, whilst leaving the rest of the net open for research (there are other apps — I like, and use, Self Control).
Embrace the discomfort, and start: your brain is going to spend the first few minutes desperately wanting some stimulation — a twitter message, a new email, anything. Don’t feed it. Be uncomfortable and start working. Once you’re into your work, keep going for at least twenty minutes — after that, things will start to flow. And if not, do it again next week.
I Did All That — It’s Still Not Working
OK, I hear you. I said at the beginning, transitioning to owning your time and attention takes a while. Our cultures don’t appreciate it, and don’t encourage it, and they do encourage and celebrate people who can handle being continuously swamped.
Maybe it’s just that way, temporarily: there will be times when you are genuinely overwhelmed. Massive growth, a huge product push, a terrible system failure — these things happen. But they should be identifiable, and temporary. If you know what’s causing the overwhelm, and you can see an end to it, OK, well, maybe you just have to deal. If you can’t see it, and the end is many months or years away, take some action.
Maybe it’s your company culture: does your company culture celebrate overwhelm, over-nighters, “eighty hour” weeks? If so, how do you feel about that? Maybe you fit! Maybe that’s OK. Maybe not, and you’d like to start building a little bubble of sanity around yourself. You have a conscious choice here. Take it.
Maybe you’re not delegating: this comes up frequently — “I have to do all this because my team is not ready/too junior…”. Probably you’re wrong, and holding on to things out of fear of failure, the difficulty of clearly describing the tasks — something. Delegation is great: you get more time, your team gets more responsibility and growth. Find something you are afraid to delegate and do it, today. People are resilient, and grow when you least expect it. Try it.
Maybe it’s you: our business (loosely, the tech world), attracts people who get a kick out of highly detailed, massively complex challenge. I certainly do, and so did the people I hired. We tend to love the adrenaline of navigating a river of problems, endlessly dodging boulders and shooting rapids. And that can make us successful, and rewarded, and the stakes can be high (money, status, career).
So being able to live and work effectively in overwhelm is a super-power, but like many super-powers, it has a downside, and the downside is that it doesn’t work forever. Physically and emotionally, most of us are not set up to go that hard year in and year out.
So take a look at yourself. What do you enjoy about the overwhelm? How does it serve you (ego? a rush? status?). What can you let go of, just a little bit? Two hours a week of thinking time? Sunday afternoons? It may take a while to dig into this, but start — give it a shot.
Yes, It’s a Marathon, Not a Sprint
If it all works out (acquisition! IPO!), perhaps you can retire at thirty, or thirty-five,or forty. Then this won’t be an issue (although almost without exception the folks I know who did make it remain intense, focussed and, yes, overwhelmed). But probably one way or another you’ll be working for a while.
Beware of the illusion that the overwhelm is temporary. It will only be temporary if you take care of it.
Managing your time and attention will remain a critical skill, allowing you to get to the deeper work of futures, direction and growing your people. And, most crucially, taking care of yourself and the people closest to you. So you can build a long, satisfying and productive career, and remain healthy and sane throughout.
I hope this is useful to you. Let me know how it goes.
(Truth in advertising: I’m putting together a free online course to go deeper into this subject — sign up to get a ping when it’s up).
I once asked an engineer who I greatly admired, how he started building the system that he (successfully) submitted for his PhD. I’m not sure what I was expecting, but probably something about careful structural design, some deep thinking about architecture, maybe some blinding insight.
Instead, he said, “I started pulling on threads”, which really took me by surprise. It was such a casual admission that he had been finding the system rather than building from a detailed plan. But I also felt a recognition: it just sounded right. It matched how I had been building my own systems up to then, but not really admitting it. I made plans, sketched some architecture, and then started pulling on threads of ideas to begin to find out what the system wanted to be.
Writing Software Is, Well, Writing
Managing software projects is notoriously hard. The results are unpredictable, the problems are often understood in detail only by a very few, and the personalities can be strong and opinionated.
The job would be made easier, I think, if we admitted what we are really doing: managing a team of writers.
We write software: we use language to create a thing that has an existence from an idea, an abstraction.
The ideas are approximated as documents, sketches, conversations, white-board diagrams, wire-frames. We translate the ideas into a thing that has meaning, to us, and to the machine that dumbly runs it.
Anyone who’s tried writing a story will know how much goes into the translation of an idea (“a detective falls in love with a woman who he betrays in 1970’s San Francisco”), and the finished result. As we write the story, we pull on some creative source, our knowledge of language, and our skill and experience, to take the idea and build it, with all of the detail and implications that are revealed as we write.
Certainly some software is rote, in the some way that some writing is rote: the five hundredth episode of a cop show is pretty well understood before the writing takes place.
But the interesting stuff is not: it’s creative, uncertain, made up as we go along.
The Environment: It’s All Business
So we’re managing a team of writers.
Not only that, but we are usually managing in a business environment. Our creation is constrained by time and budget, and there are often competing (sometimes strongly competing) ideas about what we’re building, and, more crucially, why. The ideas we are translating into language are open to interpretation, and different groups (the CEO, Marketing, the customer) can have wildly different interpretations.
Not only that, but the stakes can be high: the survival of a company, the value of years of stock grants (sometimes measured in numbers that most of the world can only gasp at), the first (or last) shot at making it big, careers, jobs, futures.
We are managing a creative process which is by its nature unpredictable and personal, in an environment which craves certainty, predictability and consistency.
If we think of the software team as “engineers”, the uncertainty and constant variation feels like a central bug in the process, and a stressful one at that. If we think of a software team as “writers”, it’s clearer what’s going on, and our approaches make more sense.
Managing Software Creators as Writers: Some Implications
Guidance, Not Control
We tend to react to these pressures by grasping for control. If we have “good management” — firm enough deadlines, detailed enough wireframes, daily checkins, monthly project reviews — then we can keep the whole thing together.
Control is not the right paradigm. The job is guidance, sometimes tight, sometimes loose. Sometimes the “writing” is flowing, sometimes it needs to coaxed and forced. The manager (a better word is “producer”) has to understand the creative process: what is needed? what does the work want?
Own the Goals
Your writers are deep in their code. That’s where you want them, and where they want to be. They are “pulling on threads”, discovering in language what needs to be built. The writing of the code requires that they, to some extent, lose sight of the purpose of the writing. Not because they don’t care, or because they are irresponsible, but because they have to be able to be open to where the writing takes them.
Your job is to hold the purpose of the team, the goals.
You own the goals so the team can be continually course-correcting towards them. Your holding the goals (today, this week, this month, this year), constantly communicating the goals, adjusting the work so it’s directed towards the goals, is a vital service to the team.
Tight Processes, Loosely Held
Your job is to balance loose and tight process. Deadlines are good. Deadlines at the expense of a brilliant burst of creativity aren’t. Brainstorming is good. Too much brainstorming moves away from the real work. A small team working with only a notional idea of a goal may produce terrific results. A large team without a clear destination will fail.
A well-designed process allows a writer the freedom to create by limiting their boundaries. An unduly “stiff” process chafes, and rubs against the organic business of creating.
Writers are Individuals
The act of translating a concept into language is not rational, linear, open to easy analysis. Writers know that some days it comes easy, and some days it feels like it’s gone forever.
Like writers, software creators have a massively broad range of skills, approaches and personalities. What they create is a reflection of who they are. There are structure-people, speed-freaks, intuitive idea generators, generalists, specialists, language pedants, brilliant mess makers and steady, reliable builders, among many others.
How they create is equally individual: some need a complete and rigorous architecture before they can bear to start. Some just need a keyboard. Some take a week doing apparently nothing before they suddenly spit out a completed work. Some work daily, predictable hours.
Some are motivated by money and stock options. Some by the beauty of what they can create. Some by the connection that comes from working intensely side by side with other brilliant people who share their craft.
Your job is to understand these creative, highly variable human beings and get them what they need to work well.
In particular, you need to fit the job to the writer. If you want something to go fast, find a speed-freak — a writer for whom an incredibly fast solution is a thing of beauty. If you want a strong, stable, long-term architecture, find the person who loves structure, elegance and has the strength of personality to stand up for it. If you want a gorgeous UX, look for the team member with the spectacular personal website.
We are drawn to what we are drawn to — for some reason this fundamental piece of human nature is obscured, or down-played in business. Find what your writers are drawn to, and let them revel in it.
Love the Mystery
Your job is to balance the mysterious business of creativity with the hard-edged requirements of business. If you love the mystery, then the surprises, the uncertainties, the impassioned arguments about apparently tiny details — all the passionate business of creating something new in the world — will take you deeper into the work, will align you with your group.
If you are afraid of the mystery, find its unpredictability difficult, then you will be constantly wrong-footed as you try, and continually fail, to have it completely under your thumb. Control will take only you so far — a smallish (maybe ten person) group, a few years of managing. To go further, you need to love the mystery.
Why We Do It
In the software industry (which these days is almost every industry), we take abstractions, concepts, visions and turn them into something that works. And we do it inside timelines and budgets, and we do it for high stakes.
Building a great piece of software is a constant balancing act of creativity, structure, improvisation and deliberation. At the heart of it is the act of writing, an act of will, inspiration, craft and (often) sheer effort.
The job of managing software is to guide creative, brilliant, massively varied writers un writing their best work. A privilege and a joy.
I once worked for about eighteen months with a peer I couldn’t trust. It was awful. I wasted time, effort and attention on parsing his emails, protecting my team and laboriously documenting “agreements” that “clarified the situation” to my boss (which would be run over an hour after we had met to “ratify” them).
And I felt bad. All the time. There’s just something nasty about not knowing: not knowing what will happen in the next meeting; not knowing if an agreement will be kept; not knowing when another email will come in from your boss, from your team, from a peer, with another set of bruises and breakages and emotional upset. And there’s something more than that: having to be around somebody who you don’t fundamentally trust is spooky, uncomfortable, unpleasant.
|I recently highlighted this rather terrific post by Jessica Rose. It kind of off-handedly introduced a notion we might call “HR Debt” – the organizational analogue of technical debt.|
Coincidentally, a day later, I then walked into a client session where the issue was, in fact, fixing up a team that had been badly structured and poorly lead: we spent an hour sorting out the pain, cost and general difficulty of getting things set to rights. The notion of “HR Debt” was immediately helpful. Good!
We might describe technical debt as the literal cost (time, attention, real money) of avoiding doing things the right way. In the short term, the company saves money by, for example, not fixing a legacy architectural issue, by “hard-wiring” a piece of code, or just not fixing known bugs (feel free to provide your own list).
The issue that came up in the coaching session was: when to stop meeting and write some code? My client, a senior software engineer, knew in his bones that more meetings wouldn’t move the project forward, but a week of him coding a prototype would. But how to communicate that without appearing to just arrogantly blow off the team?
“Code Wins Arguments” has been around for a while. This is from the Facebook S1 filing:
“Instead of debating for days whether a new idea is possible or what the best way to build something is, hackers would rather just prototype something and see what works”.
Classic! “Hackers would rather…”. Of course they would! No more stupid meetings, we’re just going to build it and you guys can sort it out later! Cool! The implied context is an argument and the outcome is a win – which means a defeat for somebody.
So I’ve had a few clients who check their laptops and phones in meetings, to the extent that it comes up in a 360 review.
I’ve even had a couple of clients who apparently do it in one on ones.
When you pull out your phone in a meeting, or open the laptop and start typing away, you are not invisible: humans are exquisitely constructed to connect with other humans. We notice every detail in face, body posture, vocal tone, and attention. How do you feel when somebody pays close attention to you? Intense, right? Can be great, can be uncomfortable, but there’s a lot happening there. How do you feel when somebody completely ignores you, despite the fact that you’re right there? Less good, right?
This happens: you look at your calendar and see, once again, that your entire week is entirely blocked out, and you’re going to be completely overwhelmed. Again.
We all know how to manage time, right? Prioritize the tasks that are urgent and important, delegate, use a todo list. Simple! So why do we spend year after year not getting it right?
How we live our days is how we live our lives (misquoting Anne Dillard). And how we live our lives is driven by unconscious patterns of behavior that we developed very, very early, and which feel “right” – even if they cause us stress and difficulty. We gravitate to living in our patterns, however uncomfortable and stressed they make us feel. Tinkering with a todo list doesn’t move us out of our default behavior – it’s like trying to put out a fire with a water pistol – it’s the wrong tool.