I’m in an interesting bind with this newsletter. My intention was to help bridge the gap between the technical and non-technical, with a focus on startup founders. The reality is that, thanks to Kent Beck kindly recommending me, much of my growing readership are engineers (or at least technically adjacent).
I still believe that there is a gap between the business side and the engineering side of software development. I believe there is frequently a misunderstanding and a misalignment between what engineers see on the ground and what founders and executives have in their heads.
I imagine many engineers will nod their head vigorously at this. All those unclear requirements, shifting priorities, and pushback over any request to focus on quality (refactoring, writing tests, improving documentation, etc). Why don’t they get it?
There is undoubtedly an education piece for executives to help them understand the true value of software to their companies, and that engineers are the cultivators of that value through optionality. Kent is the authority here, and most of my thinking draws directly from him. He’s explicitly focusing on educating these leaders now, which is fundamental and will undoubtedly aid in his stated mission of helping geeks feel safe.
But it takes two to tango. And if we’re asking non-technical folks to step into our shoes and try to understand why it’s so important to restructure our code base, it’s not only fair but essential that we begin to see beyond our narrow scope of technical prowess and begin to tune into the messier and more uncomfortable world of business.Â
It’s hard. And it kinda sucks. I know.
Why selling as an engineer sucks
As I write this, it’s been two months to the day since I left my well-paid, secure job at an exciting startup to venture into the unknown world of Fractional leadership. I have one open PR on an open-source tool that I’ve been playing around with a little bit, but other than that, I haven’t written any code.
But we need to understand a few things. Firstly, that we’re in a privileged role of being able to concretely display value. This thing1 we built? It wasn’t here yesterday. Now it is. That’s cool.
But do people want it? Is it actually solving a problem? We can’t leave this for someone else to care about. Because the truth is, coding is becoming commoditised. Ai2 tools will make the ‘writing code that (mostly) works’ stuff quicker and easier than ever. That leaves us with the messier questions around the direction, purpose and vision of the work we’re doing, and the human relationships that are fundamental to achieving them. If we’re not meeting these head on, we’re not just failing the businesses we work for and the customers they serve: we’re putting ourselves out of a job.Â
Ai tools will not replace engineers. But they will drastically alter the skillset required to be an effective engineer. The engineer of the future will require more empathy, more skill at working with human relationships, and a more holistic understanding of the business they work in and their part to play within it.Â
Are you ready for the shift?
Forget about what you thought of this post. How did it make you feel? Reply with a single emoji of your choice and make my day.
Or, to use the technical term: function, component, widget, doohickey, wotsit.
Really enjoyed this insightful piece. Thanks! Engineers still need to solve problems. But now more than ever before, engineers need to work with the business to find the right problems to solve.