Yesterday I wrote about assets and capabilities and while I gave some examples I left off the one capability which has allowed me to consistently level-up over time: figuring out what people want.
Often this is as easy as just asking. Other times it requires some deeper thought to analyze the available info, the options, and extrapolate potential outcomes. This is the skill portion, but that’s not enough – you need to put it into action for it to turn into value. That’s really what this post is about and where the “simple” part comes in.
Make a list of everyone you affect – direct reports, managers, peers, clients, even personal relationships if you like. Next, put down what each of those people want – specifically from you, but feel free to think more generally for extra credit. For example, your direct reports usually want things like a clear definition of success, feedback on what they’re doing, interesting work, money, and any number of other things like training, software, hardware, and dozens more. Your manager wants to know how things are going and that the next milestone will be hit successfully – perhaps another thing or two. Once you have the basics, you can drill into detail for the particular projects you’re working on.
This list is dynamic and needs to be updated frequently. For people you manage, this might be daily as you look at specific tasks. For your manager, weekly should do it. As you get further out to clients, then monthly may be enough.
This should be a simple exercise – given a person you affect, write down what you know about what they want. If you are unsure, then the next step is fill it in.
Once you know what people want, you have your playbook and it’s time to start providing it.
For a direct report, maybe they want to work with a new technology and you find budget to provide training.
For a manager, maybe it’s time to update the project plan or to start looking at the next release – before being asked.
For a client, are they struggling with something which keeps them from using what you typically offer them? If so, that’s a prime opportunity to provide assistance above and beyond your typical offering.
While this entire process really is simple, it’s not easy – especially in the beginning. You’ll feel like you don’t know what people want or you may even doubt your analysis. That’s natural and don’t focus on it too much and instead work to validate your assumptions. Also, the more you practice this the easier it is to identify opportunities to give people what they want as you’re talking to them. You’ll start to make mental updates to your list (which can be turned into actual updates once the discussion is complete) and you can adjust what you provide accordingly.
Lastly, what do you want? How can you make it easy for those who affect you to know that and provide it? It works both ways, but it starts with you.
Several years ago I developed a personal career strategy that I call The Assets and Capabilities Model. For the purposes of this model, an asset is something which you control and a capability is something which you can get done. Notice that this is different than “things you own” and “skills” – that’s intentional and to clarify, here are some examples before moving on:
Some of my assets:
My AWS account
My company’s reputation on Upwork
My computers (note that some assets are, actually, “things you own”)
Software I’ve purchased
My blog
My Zoom account (previously my WebEx account)
My relationship with my kick-ass designer in Ukraine
etc.
Some of my capabilities:
I can design large-scale distributed systems
I can implement a business or development process, train people on it, and monitor it instantly
I can perform code analysis and technical due diligence (in part because of experience and in part because of some of the software I own)
I can build remote teams quickly
I can schedule an online meeting at the drop of a hat
etc.
Take notice of some of the overlap – I can build remote teams quickly in part due to my experience and my company’s reputation on Upwork. I can schedule an online meeting at the drop of a hat because of my Zoom account and because I’ve done it many times before. I have long lists of assets and capabilities which took years of conscious effort to develop and several times a year I ask myself a few questions:
What assets aren’t being fully capitalized upon? (I’m looking at you, list of domain names)
What capabilities aren’t being used frequently enough?
What are some assets I can acquire/develop?
What are some assets I can divest? (domain names, old computer gear, and books are common)
What are some capabilities I’m missing?
What are some capabilities which need to be improved or refreshed?
I recommend the exercise to anyone who is interested in actively managing their value – pretty much anyone who isn’t retired. The exercise starts simply enough: grab your note-taking tool of choice (I have a thing for Canson Sketch Pads) and start listing things you have/control which can be used to solve problems and things that you can get done, either yourself or via your network of strong relationships. I find it’s helpful to link things together to find self-reinforcing constellations of value – things like AWS, Upwork, large-scale system design, building remote teams, and development process implementation all fit together to form a higher-level capability of “I can start a software company in an hour with nothing but an idea, a credit card, and an internet connection”. As you perform your asset and capability cataloging exercise, you’ll naturally identify some of these higher-level capabilities yourself. After you do, then you can follow on with questions about how to make that capability stronger, how to capitalize on it, etc.
What’s the point of doing all of this? Right now you’re probably sitting on a gold mine of value, but it’s not being actively managed. Once you have your catalog, you’ll see what you need to read, what kind of training you should seek out, which things you need to practice, and gaps which need to be filled – this is internal management. Next, your eyes will be opened to opportunities. You’ll find yourself coming across people who need something that you can can do or a chance to deploy an asset – this is external management.
As a final example, I remember some time around the end of 2009 I decided that I lacked public speaking experience. I had no problem speaking to groups in meetings, but I had very little experience presenting to an audience who was there specifically to listen to me. I developed an idea for a talk about the future of work and how it affected recruiter, contacted a few recruiters, and said, “I have this talk and I’m trying to get better at speaking – may I present to your team sometime in the next month?” Not everyone responded, but a couple did and I got to practice. Public speaking is now on my list of capabilities because I’ve actually done it and so I know I can do it again.
What’s on your list? What are you missing? How are you going to capitalize on the unique collection of assets and capabilities that you possess?
I love to read and have a rule that whenever someone recommends a book, I buy it ASAP. Lately I’ve also been getting books I see referenced in other books. There’s a ton of research and anecdotal evidence which correlates reading to success and I’m pretty convinced that there’s causality, not just correlation working there. As such, here are some recommendations for things to read to contribute to your success.
Tools of Titans is one of the most interesting and diverse sets of interviews, pull quotes, and anecdotes I’ve ever read. Does anyone else feel like Tim Ferriss is the next Shep Gordon? Read this book if you’re an interesting person, or want to be an interesting person, or want to find other great stuff to read.
Extreme Ownership is referenced in Tools of Titans since Jocko Willink (one of the authors) was interviewed by Tim Ferriss. Read this book if you lead people, want to lead people, or to find out how to become a better team member. Each chapter starts with a (literal) war story from Iraq, but if you’re not into military stuff you can actually skip to the Practice and Application to Business sections which follow.
Rands in Repose is tied with Seth’s Blog for my favorite blog. Michael Lopp is a brilliant manager with enviable writing skills. Read this blog if you manage technical people or you are a technical person. His book Managing Humans is also excellent, but the blog is not to be missed.
Safari Books Online is my secret weapon. Yes, it’s $399 per year and that’s not cheap but combined with their Queue app it’s a bargain if you’re a technical person who likes to learn. In the last year I’ve read through dozens of O’Reilly books and watched a couple of their training videos. The books alone would have cost me triple or more. If you are a developer and like to learn from books, this one is a no brainer. If I were running a company with employees, buying the team version would probably be on my list for recruiting top talent.
Okay, one more just for fun: Living with a SEAL is one of my favorite books to give to people. My friend read the entire thing on a red eye from Seattle to Miami one night after I convinced him to “give it 4 pages and see what you think”.
In knowledge work, there is value in reducing uncertainty.
Certainty is comfort. Certainty is ease. Certainty is the product.
I’m pretty sure it was Steve McConnell in Rapid Development (which Amazon remembers me purchasing 17 years ago) who introduced me to the concept of the Cone of uncertainty. In the book, he explains how as requirements are gathered, code is built, and testing is performed that we progressively improve our ability to estimate since unknowns are being removed. I think this concept has a broader application to any type of knowledge work, be it software development, consulting, financial valuation, or other types of “figuring things out”. Here’s a sketch to illustrate my mental model:
It is useful to keep in mind that you can never remove all of the uncertainty – you can only get as close to Truth as is practical with an acceptable amount of uncertainty remaining.
Look at the Cone of Uncertainty as a model, not as actual measurement, and consider the path from initiation (Complete Unknown) to delivery – such as working software which has been tested, documented, formatted, commented, etc. Let’s slice the cone into 9 steps and pull out the total uncertainty (i.e. add the left and right distances from Truth centerline) to represent what someone needs to overcome to move to the next step:
At step 1 (Creation/Initiation) there is a huge reduction in the amount of uncertainty. Accordingly, there is huge value. People who create companies, people who create products, and salespeople are all good examples of working in that area. The ability to go from a nearly complete unknown to something that has structure is incredibly valuable – and can offer corresponding financial rewards.
The next few steps chip away at uncertainty until we get to the first working version. It’s not just that it takes skills to gather requirements, determine an appropriate architecture, and design a system – it’s that at every step along that path there is a non-trivial amount of uncertainty which must be dealt with. The people working in those domains need to understand that uncertainty and press forward to reduce it. It’s uncomfortable to be unsure. The feeling of sticking your neck out and running the risk of being wrong can be crippling to some – think of everyone who says that they could never be a salesperson or start a company. Those who overcome that feeling and work through it, however, are some of the highest paid people in any industry.
Note also that between step 5 (First working version) and step 9 (which is, essentially, a very specific form of documentation) there is very little reduction in uncertainty. This makes sense if you think about it – you could hand software from step 8 to anyone with basic development skills to have step 9 completed. While this is still an important step, there is substantially less value in it compared to building the first version since it is commodity work. This is also one of the reasons why developers are so hesitant to comment their code, write documentation, etc. – it doesn’t have the same level of satisfaction that comes from building something and going from concept to functioning code.
This idea has been on my mind for a few weeks now since I work with team members in a wide spectrum of capabilities and price points. I started wondering, “Why do we pay Igor the designer more than Ivan the tester?” and “Why is this guy paid like a team lead while that guy is paid like an intern?” In each case it wasn’t the individual’s skill level, but the amount of uncertainty they managed to both deal with and reduce for us. A designer who can take fuzzy direction like, “Make it look modern and attractive” and create a great user interface is worth more to us than a tester who takes a piece of software and reports back “Here are the things I tried and here are the results”. This is particularly interesting to me since testing is hard and requires more skill to do well than most people realize.
I’ve focused a lot on how this applies to software, but I’m pretty sure you can apply it to any knowledge-work based position. This leads to a couple of important conclusions. The first is that you need to accept, acknowledge, and overcome uncertainty. Part of your job is to explain, contain, and remove that uncertainty. This is usually accomplished by writing something which explains what you found, what you decided, and why. Someone with more (or different) experience may disagree with you, but if you’ve provided what you know and what you think it will be easy for others to improve or correct what you’ve done. Lastly, if you’re looking for a way to become more valuable then work your way up the cone to deal with increasing levels of uncertainty. The ultimate is to create a completely new product or company and go from the terrifying unknown to millions of people understanding you.
