Bob was a solution-space engineer. Henry was a problem-space engineer. Bob worked at the world's first shovel company, and coincidentally he engineered shovels. They were beautiful shovels, and worked really well. Henry worked at the world's second shovel company, but they never really thought of themselves as a shovel company. They thought of themselves as a company that helped people dig holes. While Bob was perfecting the shovel, Henry engineered an excavator. Henry was a problem-space engineer.
This article is an attempt to describe how the JTBD methodology can be applied as a software engineer. It will help you create more value for your organization (and more value for your pocketbook). To fully understand how these principles can be applied, a brief overview of JTBD is required. Customers buy products and services that help them get jobs done. That's it. If you would like a much more detailed explanation of these concepts, you can check out outcome-driven innovation and jobs-to-be-done.
It doesn't make an ounce of difference whether you are a soloprenuer, an owner of a large software development organization, or a software engineer employed at an organization of any size. You provide a service or product that helps somebody get a job done (if that's not the case, then you probably shouldn't be employed). However, many software engineers have yet to come to this realization.
They think they provide the most value by knowing Ruby, Java, Angular, C++, or WhizBangFrameworkX, etc. They are continually looking to improve their technical skills (a good idea, actually). They constantly seek to implement new technologies, and will find any excuses to use them within an existing software platform. They know and understand the ins-and-outs of a diverse set of technologies. They can implement solutions to many different types of problems. They are certainly valuable in their own way, and there is a significant demand for this type of talent. However, many of them are missing significant opportunity, primarily due to their reluctance to move from the solution space to the problem space.
The solution space is the place where solutions are implemented. The following points are indicators that a software engineer is living in the solution space.
What's the problem with this? Nothing really, for those software engineers who don't mind being a commoditized resource. Unfortunately, even for those developers who can crank out features at an incredible pace, they will always be viewed as an easily replaceable warm body.
The problem space is the place where solutions are formulated. The following points are indicators that a software engineer is living in the problem space.
So what's the key difference between the solution-space engineer and the problem-space engineer? Outside of their department, the solution-space engineer is just known as 'that developer.' For a solution-space engineer who has managed to endure a period of longevity, some of the business folks may even recognize their first name, and call out greetings as they pass in the hallway.
However, the problem-space engineer is in a whole different realm. Their opinions are sought out by both the technical and business people. They are included in key meetings, and their absence from these meetings is noticed. They have the ability to think like the customer, and fully understand what job the customer is trying to accomplish.
I've had numerous recurring conversations over a period of years that have followed a similar theme. Bob, the solution-space engineer (and Bob isn't always a software engineer - but Bob always lives in the solution space), laments to me that the organization doesn't seem to put much value in just 'doing your job.' Or that good annual performance evaluations require developers to work on a number of 'special projects' that weren't part of their daily job. Or that somebody got a promotion who didn't deserve one.
There's been time when I've been Bob, the solution-space engineer, and was initiating these conversations. However, I eventually came to the realization that these conversations stem from one of two reason.
If you happen to be a software developer who lives in the solution space, and would like to move into the problem space, all is not lost. Making the transition is not that difficult. It just takes a bit of effort and initiative to make it happen, along with a systematic application of the JTBD methodology.
You have to start looking beyond just the tasks that you've been instructed to do. Each task you complete is part of a more meaningful job that is being done within your organization. You need to start thinking about what those big picture jobs are, and then start creating ways to do that job better. Additionally, you need to continually be injecting yourself into those conversations in meaningful ways.
If you want to get the most leverage out of your problem-solving abilities, you'll have to work on problems that matter. This means solving problems that have significant business impact. Issues with insignicant business impact (even if they create significant annoyance when encountered) will garner very little recognition. However, solving big problems will create wide organizational recognition, and you will gain instant credibility as a problem-space engineer.
By understanding what jobs your customers (internal and external) are trying to accomplish, you can move from the solution space into the problem space. When you start taking part in the conversation, and adding value beyond just cranking out features, you will no longer be just another operational expenditure on the income statement. You will become a real person who adds real value to real business conversations about real business problems. Coincidentally, when you achieve this status, your pay will no longer need to be determined by the going commodity rate on the market (think big pay raise).