“If you are only using engineers to code, you are only getting half of the value.”
— Marty Cagan, Silicon Valley Product Group, Inspired
What Is Engineering?
Engineering is a scientific field and job that involve taking our scientific understanding of the natural world and using it to invent, design and build things to solve problems and achieve practical goals.
10,000 Hours and Doing It Right
Malcolm Gladwell makes a claim in his book Outliers that if you spend 10,000 hours practicing a skill—the right way—you become an expert in that skill. An entire talk could be given on this subject, and if you want to dive deeper, go read Outliers and the studies it references. If you call yourself an engineer, and you’ve been working in the field for at least five to 10 years, you should have the those 10,000 hours—making you an expert at what you do. You should also have the confidence to embrace the concepts of engineering and push them within your organization. However, you have to practice the engineering discipline correctly. Let’s take another look at our definition of engineering to figure out if we’ve been practicing our skills correctly.
Engineering is a scientific field and job that involve taking our scientific understanding of the natural world and using it to invent, design, and build things to solve problems and achieve practical goals.
That means we should be using the scientific method, well known by all of us who took any science in school:
- Formulate a question (usually from an observation).
- Generate a hypothesis based on your observations.
- Predict logical outcomes from your hypothesis.
- Experiment and conduct measurement-based testing of your hypothesis.
- Analyze the results of your testing (generating new questions and observations).
I’m curious, which part of that is writing code?
Ahh, that comes in the second part of the definition:
Engineering is a scientific field and job that involve taking our scientific understanding of the natural world and using it to invent, design and build things to solve problems and achieve practical goals.
That’s where we, as engineers, apply the results of our analysis to the craft of writing clean code. But that only applies to one of the three outputs we have as engineers: build.
Finally, you have the ability to put your hands on a keyboard and get some code written!
Well, sort of. You have to take all the parts of the discipline, from observing and understanding the problem to designing and building a solution, and bake them into a cohesive rhythm where you can solve problems effectively. It’s a good thing there’s already a rhythm we’ve been using here at Ramsey.
Discovery and Delivery Flows
Marty Cagan, author of Inspired: How to Create Tech Products Customers Love, teaches companies how to build the best tech products possible. His model applies the concepts of the scientific method to customer problems. He challenges the old notions of waterfall style delivery methods and works to create the case for empowered product teams through a discovery-and-delivery model. He believes that high-performing teams should work together to come up with the best solution for the actual problem facing their customers. And then that same team delivers the solution that solves that problem.
This process creates an overall culture of critical problem solving—not just delivering software.
But what does that mean for the Engineering Team?
Part of your role as an engineer is actually to step away from your keyboard and leverage all parts of the engineering discipline in order to get the best result. Let’s again take a look at the definition of what it means to be an engineer.
Engineering is a scientific field and job that involve taking our scientific understanding of the natural world and using it to invent, design and build things to solve problems and achieve practical goals.
As engineers, we have a tendency to jump straight to the solution phase of the process. And truth be told, even Cagan admits that when it comes to generating solutions, engineers often come up with the best solutions. This surprises a lot of teams.
But it’s not because engineers are the most creative or the smartest people on your team (even if some of us might think so). It’s because we know what’s possible with our technology. Let that sink in. We’re smart for sure, but context gives everything. The only reason we can propose good solutions is because we build and work in the technology that will likely be a part of solution.
However, without the rest of the process, the observation, question generation, hypothesis or measurement-based testing, our solutions are likely to fall flat when put to the task of solving a customer problem.
Get Into the Why
In order to use the full force of our expertise in our engineering discipline, we need to understand why our work matters.
We must do the following:
- Acquire business context
- Connect with customer pain
- Understand constraints (and throw out requirements)
- Take time away from the factory floor and spend time in discovery
- Measure our success in the outcomes from our ideas, not that we released them
Let me say it again: All of your knowledge of our technical systems means nothing without deep knowledge of your customer and the constraints of your business. While you’re not required to be the best at knowing these two things (that’s the product manager’s responsibility), you must commit yourself to getting this context. You must do more than write code. To do anything less is robbing our users of the HOPE they deserve.
It’s up to you and your product team to make sure you understand why the work is being requested. We have to be a catalyst for a new culture—a culture of critical problem solving. Let me repeat that. It’s important. We need to evolve our culture to focus on the critical problems facing our customers and our business.
We have to get It. We have to want it. We have to exercise our capacity for it.
We shouldn’t be satisfied with receiving ideas from the powers that be and pushing them out the door without understanding the why behind the work. To truly be empowered, we must connect our practically engineered solutions to actual problems preventing our customers from winning.
Pushback
Over the years, I’ve heard engineers say a few different things when presented with this concept. It’s likely different and counter to how their organization has been working in the past. I hear things like: “I don’t feel valuable if I’m not coding” or “I don’t feel comfortable talking to customers” or “businesspeople have all the ideas.”
If any of these resonate with you, know that it’s okay if you feel this way. But also, realize that you must move beyond this state to truly unlock the potential for your customer, your team, and yourself. Talk to your leadership team about it. It’s important that you work through the underlying feelings of self-doubt, apathy and fear that the above statements represent.
Homework and Next Steps
In the next 30 days, you should:
- Get connected with a customer (internal or external) and be able to answer what they think their biggest problem is.
- Be able to define one or two constraints your business places on how you solve problems.
- Be able to clearly articulate what problem the work you’re doing directly ties to.
- Find a company you trust where you’ve seen them do follow a discovery-and-delivery process successfully and reach out to discuss how they’ve brought it into their teams.
Are you looking for work that matters? Our Technology Teams are growing, and you can view open positions here. Not ready to apply, but interested in chatting with a team member informally to learn more? Request a virtual meeting here.
