One Hundred
This is my one-hundredth posting to this weblog (aka blog). I started this adventure about 10 years ago with the publication of the first edition of An Engineer’s Guide to Solving Problems. The second edition was published about a year later.
We rarely know all of the places a project will take us when we start. We also don’t know who we will meet in the course of the work. Although I had a notion of the importance of problem-solving when I started, I had no idea how much simply writing about problem-solving would change my thinking about the world around me. Interesting ideas are like that: they act as a tool, perhaps like a magnifying lens or a microscope or a telescope that let you see and do things you could not imagine before.
There are many examples we could discuss of problems that companies (organizations of humans) attempt to solve. What problem do you think Amazon solves? (Spoiler alert: I would say that Amazon mostly tries to reduce friction in the online buying experience.) What problem does your local water company solve? What problem does your sewage system solve? The list goes on and on.
My conclusion and key message is this: Businesses exist to solve one or more problems for their customers. Governments, non-government-organizations, charities, community groups, and pretty much any organization of humans exist to solve one or more problems for their customers. Except that in this latter case, we don’t call those users “customers.” Maybe we call them members or constituents, or beneficiaries. But the idea is the same. The organization exists to solve problems for their customers. If the organization forgets this and starts trying to do too many other things, they often disappear—and well they should. (For simplicity, I will only talk about “companies” for the rest of this essay, but I am confident you can apply the same idea to other organizations of humans.)
Here is an odd observation about perspective. Many company leaders will tell you that a company was founded to “make money” but they can eventually be led to the conclusion that they really get that income by solving some kind of problem for the customer. It doesn’t matter if the company does this by selling a product or a service to the customer.
When you are trying to get hired by a company, the first thing you should ask yourself is “what problem does this company solve?” Then you can dive into who their customers are and why those customers might be attracted to that company’s solution(s).
The next step is for you to figure out what kinds of problems you have skills and experience to solve. How could your unique collection of skills and experience make you valuable to the company? If you cannot answer this question—at least in a vague and reasonable way—then that hiring manager will probably struggle to answer that question. You won’t get the job.
Not every job is directly solving problems for the customer. Sometimes your job is to solve a problem for your manager or coworkers, so that their time is available to solve problems for the customer. But the highest incomes are usually received by those who are closest to the customer. (Not always, but I think you can understand why this is mostly true.)
There are many lists we can make of skills that make you more employable. I generally try to write about skills that are not specific to my experience (electronics design and debug) and instead try to abstract those into broader skills which could apply to any job.
The one skill I have spent the most time writing about is getting people to just write stuff down. A related skill is having a strong habit of reading. You should be voraciously reading what other people write about skills and experience within your chosen profession. But you need to spread your curiosity to broader topics, including those things which are your greatest weaknesses.
Personally, I really enjoy learning by absorbing the stories that other folks tell about the problems they have solved. I try to share some of these stories, both in the book and in these blog essays. The lessons of these stories seem to stick in memory a little better. Perhaps it is because of humor or pain that is shared in the story. We don’t feel so stupid when we find that other folks have made similar mistakes.
For the engineers reading this, I will include something that I often put at the end of presentations.
Engineers should be able to express ideas about success and problem-solving as an equation: 
But that simple equation does not take into account the dimensions of the problems. Some problems are big and complex and some are small and simple.
Problems can be tall or they can be wide or sometimes a problem can be both tall and wide. That is why the integral helps us understand the total size of a problem. We are dealing with the area under the curve of the problem. Sometimes life throws us knuckle balls, and sometimes it throws us a curve.
This should lead us to an equation that looks like this:
Unfortunately, other people often see it like this:
Otherwise known as “What have you done for me lately?”
In An Engineer’s Guide to Solving Problems I make a point of saying that design, repair, and fixing stuff are really just different ways of expressing “solving problems.” Your skills and experience in solving problems should always be growing and improving. So please, get back out there, and go fix something.