When I started my undergraduate education, I began in a Master’s of Architecture program. And although I didn’t end up graduating with that degree, I’ve recently drawn parallels to some of my recent work, and the challenges I was assigned as a part of my classwork in that program.
I’ve been told that you go to college to learn how to think; to put it more simply, if I were to start at point A, and I need to get to point B, what would I need to do to make that happen? Luckily A to B usually isn’t a big “jump”. Progress is clear, objectives are defined, and tasks materially contribute to completion.
For example, any math class might teach you a series of “steps” you need to take to arrive at a solution. How about in an architectural studio? How does one simply “arrive” at a design? What questions do you need to ask that will influence your design? How much trial and error is necessary to move forward?
In this case, sometimes it’s unclear how, if at all, the work you’re doing at a task level is contributing to a final product. One’s productivity might as well be zero, until you find the correct (or reasonable) route forward. If you were to graph the completion of a product/ solution/ feature/ etc over time, I would venture it is far from linear.
Do the “flat lines” influence the slope of the future? Are flat lines unproductive? Can you bill your time for being unproductive? Is it productive to be unproductive?
I’m reminded of an The Office episode wherein Michael hosts a “Movie Monday” in the office, effectively putting his employee's productivity to a temporary zero. When Jan, corporate leadership, appears, Michael insists that all of his employees will be more productive since they’ll now need to make up for the time they lost during their screening of “Varsity Blues”. Perhaps the accounting department and their rigid, predictable work may struggle to catch up, but how about others in more dynamic positions?
….
In my free time, I enjoy hobby programming. I’m far from an expert, but I consider myself a mildly talented front-end designer. I find that when I’m designing pages, I can “spin my wheels” for days and days, sometimes weeks, trying to find a starting point for my work. It’s simply not realistic to just sit down and “code” without an idea of what you’re trying to design.
Once I settle comfortably on a shell of a design, my productivity skyrockets - I can design the page and pivot as needed throughout the entire process. If I had been tasked by a client to design a page, with daily status reports, I fear 80% of those status reports would report no progress. Not because I wasn’t making any, but the repetitive cycle of initial “trial and error” does not consistently contribute to a final product.
Isn’t it interesting for design services, there is typically a limitation of revisions? In these cases, each revision, each trial, is the equivalent of checking another box. In that, they’re making tangible progress, regardless of how lackluster each design might be.
…
Recently in my work, I’ve taken on the managerial responsibility of a deeply technical team. Our end goal is clear - implement a highly configured, and customized enterprise software package. Our timeline is huge - over a year. To relate it back to my point example, it feels like we’re trying to go from A to Z, with each milestone between ill-defined and lacking specificity. I find one of the more difficult tasks I deal with each week is developing achievable tasks that will help get to the next milestone.
Some teams find success with exceptionally detailed project plans that can be tracked continuously, however, the prerequisite of this approach is a deep and complete knowledge of everything involved from start to finish. This is difficult in a setting where the work you’re doing isn’t necessarily repeatable.
Other teams simply rely on the expertise of the team itself to take initiative at an individual level and recognize the next challenge they might tackle to contribute to the whole. You find this usually works well in an agile implementation where teams usually self-organize and build towards requirements that are clear.
As a segway into my final point, it would seem that there's an increased emphasis on having a tangible and visible goal as it relates to work you or your team are trying to accomplish. How can you build a path forward if the end is unclear? I've heard this related to someone simply getting in their car and hitting the open road. It's irrelevant how fast you're going if you don't know where you're going, right? It would seem that the driver that took the time to plot a course, if even vague, would end up in the right direction and would mitigate a situation requiring them to backtrack. Maybe this is why goal setting is so critical?
