Work As Imagined
There are four categories to examine the work we do, or our co-workers, or even the work our users are attempting to do with the products we make; work-as-imagined, work-as-prescribed, work-as-disclosed, and work-as-done. Let me quickly lay out the concepts:
- Work-as-imagined: how you imagine doing your job in the future, or how you imagine other people do their jobs.
- Work-as-prescribed: the rules, standards, procedures, or even commands for how the organization tells you to work.
- Commonly expressed in joke form as asking a child to tell you how to make a peanut butter and jelly sandwich, and taking their instructions overly literal and making every mistake you can while still obeying their commands.
- Work-as-disclosed: how you, or others, describe the work you did.
- Work-as-done: the actual work you did, that exists in the moment, and cannot be accurately captured or recorded, because so much of it happened in your mind in the moment.
I am not surprised that my perspectives on an Engineering organization are rooted in epistemic realizations. I know myself. I have my work experiences. I know what I am good at. I know what I am bad at. I have a small realization of what I don’t know. There is a lot more that I don’t know, and I don’t even realize it. Multiply that by everyone. At every level of role experience, junior, intermediate, senior, manager. Multiply that by every good, and even more so bad work experience people have had. And then multiply it by the circumstances around their upbringing and early adulthood. It is not exaggerating to say that every day we are surrounded by people with millions of experiences and influences that we don’t, and probably can’t, ever know about.
This lack of knowledge, not having the ability to know, is a serious one. Resolving this conundrum is what all our communication needs to be about. Between peers, between you and your manager, me and mine, between our managers, between departments, and crucially between us and our users.
Beyond communication, the very best way I know how to overcome these gaps is to actually do the work together, in real time. So many of us in engineering like to be left alone to our own devices. I know I do. “Just write down what you want me to do, and leave me to do it.” It is a comforting thought that all I have to do is accomplish what is described, and I even get to choose how exactly to do it! But it opens the door for failure and misunderstanding at every opportunity.
Engineers should work together writing code. Product and Engineers should work together when defining problems and coming up with solutions. Product, Design, and Engineers should work together when making wireframes and mockups. Design and Engineers should work together when creating interfaces. It is a sliding scale of how much and how often. How well is your team functioning and communicating? How comfortable are they with each other? If you think it needs to improve, slide that scale and have them work together more often and for longer.
A very common anti-pattern that I see in organizations is each of the disciplines working alone, and then everyone coming together to discuss status for an hour a week. Every engineer will tell you that typing the code is not the slow part of the project. Every designer will tell you that clicking in Figma is not the slow part of the project. Every product manager will tell you that writing the ticket description is not the slow part of the project.
Trying to condense all your work into a shared hour of communication is an anti-pattern. Meet together to do the work, delete the status meeting from the calendar. If you’re working together, you don’t need the status meeting. And when you’re together you’ll be doing the hard parts. Once everyone comes to a shared understanding of the problem & solution it will be very clear when they are ready to split up to let their fingers do the rest of the work.
- ← Previous
The ROI of a Solved Problem - Next →
Complexity Has To Live Somewhere