Bridgewater had a mantra of “skills, abilities, and values” which they used to break down concepts around personal growth. The idea is that skills are easy to acquire and tend to be more constrained – something like “write queries in SQL” or “manage emails through Hubspot.” Abilities relate more to your patterns of thought, and while they can be developed over time, they can’t be directly taught. Examples include things like “thinking logically” or “multitasking effectively.” And finally, values are the things you consider important. These might change over a very long time scale, but one can rarely ever intentionally influence them in a predictable way. This tends to be something like “I value fairness”, “I am ambitious,” or “I’m just working to pay the bills.”
I found this framework extremely powerful when I first encountered it, and still step back to it fairly frequently when I’m thinking about giving feedback. But over time, I’ve found that this framework is a bit confusing and difficult to wield reliably. I have two major arguments for why this is:
A. All three of these words are “common” words. The use of ‘value’ in this framework is actually ok, because it maps pretty well to the standard meaning. (Hence why I leave it unchanged.) But ‘skill’ and ‘ability’ overlap heavily in the common vernacular, making it extremely confusing for new people trying to understand these concepts intuitively.
B. Bridgewater’s framework focuses too much on the cognitive/practical split. Some practical skills are narrow, like writing queries in SQL, but what about “thinking programmatically”, “writing clean code”, or “doing effective data science”? These are all worldly in a way that Bridgewater’s “abilities” tend not to like, but it feels very awkward to try to bunch them all together into “skills”.
When I’m giving feedback to someone, I have a few related goals:
- Make certain I actually understand what the person was trying to achieve, or explain clearly what I’m modeling as ‘success’ before telling them what they “should” do.
- Explain my understanding of how they got to their answer, to ensure I’m not typical-minding them or missing key context on points of complexity.
- Given a shared understanding of a specific goal and the whole context of the challenge, build up my mental model of how an idealized person would have approached the challenge.
- Communicate the largest differences between what I’m envisioning and the actual approach of the individual in terms of atomic primitives they understand.
Point 4 there might sound a bit abstract, but it’s really not. When trying to give someone feedback about how to play piano, you don’t just say “play it better.” That feedback would be true, of course – an ideal musician would have played better than your friend! But “play better” isn’t a primitive action for most people – their next question would simply be “how?” Less obviously, imagine a situation where you want to give feedback to a UI designer, because the design they produced feels a bit bland to you. Upon substantial reflection, you come to the realization that they bottlenecked themselves by starting with someone else’s mockup that made it hard for them to think about wider variations on the theme. How you communicate this feedback, then, depends on the individual you’re speaking to. A more junior designer might need you to lay everything out in detail; a senior designer might simply hear you say “You’re not approaching this creatively enough” and understand what you mean. The most junior folks might understand your feedback but not actually be able to follow that to the next step of changing their behavior in the future – perhaps you’ll have to guide them towards an explicit checklist to walk through, to ensure they’re not constraining themselves, which the senior designer would simply find cumbersome.
What I’m not interested in giving feedback on is “I wish this design had more blue in it.” This sort of customer feedback, or feedback on ways in which outcomes weren’t ideal, is far too impersonal, and more importantly it’s not general enough. The designer who hears this feedback learns…to add more blue in this one design. The designer who hears the earlier feedback learns a generic way to improve their overall approach.
So, after reflection, I’ve tweaked Bridgewater’s framework to create one of my own. Feedback on “Tasks” refers to those specific outcomes – things like “can you make this more blue” or “You might want to write that in Python.” This feedback is the easiest to give, as very few people get offended at comments about their outcomes alone; but that’s exactly because the feedback is so impersonal that there’s nothing to get offended by, which unfortunately also means there’s nothing to learn in a broader sense. By picking up lots of data points from feedback on Acts, you eventually start to learn more general tendencies, but it would be a lot more efficient to just receive feedback directly on your Art.
“Art” here refers not specifically to aesthetics, but to any practice which has hard-to-pin-down ways to be better or worse. One can develop their Art of chess, of sales, of drawing, of cooking, of thinking abstractly. (I know this is slightly misusing “Art” compared to common speech in the way that I critiqued Bridgewater’s use of “Skills” and “Abilities” before, but so far in my experience I find that people empirically are much less confused by this version.) When I gave my three examples of good feedback, all three of them were feedback on Arts. Just as a young child might first learn to paint-by-numbers, the most junior designer needed more guided instruction; but in all three cases, the UI designers were improving their Art of design. (Contrast with “needs more blue”, which I think most people agree isn’t feedback about the Art itself, merely the specific piece/act.)
Finally, Bridgewater’s “Values” remain intact as a description of why an individual would bother to master their chosen Arts, and can be helpful in determining which Arts it would be most useful to develop for any given individual.
I feel like this framework does a better job cleaving reality at its joints. While it’s hard to tell what a skill vs ability is or when to give feedback on one or the other, it’s much easier to identify a Task versus an Art; and what’s more, the idea of giving feedback on a Task and giving feedback on an Art are fundamentally separated by the theme of ‘is it generalizable, in the way that most people intuitively understand where “add a cloud there” is not but “you tend to get bottlenecked into a limited perspective” is.’
I could almost certainly present this idea more cleanly by throwing away the discussion of Bridgewater’s old framework and just presenting this new one ad hoc. But this blog is fundamentally about charting my path of development as I continue thinking about issues of culture, so I felt it was important to actually shed light on where this is coming from.
An Entrepreneur's Journey 