We are all guilty

Dear fellow software engineers: We’re all guilty!

I came across this short post from John Cutler titled “They just want to code all day”, and as an engineer, it resonated with me.

I’ve worked with all kinds of tech companies in the past 11 years but until I started my own company, I never had real context around the products I was building. Sure, I took part in planning sprints, worked on features, shipped them, and sometimes I helped customers with their issues. However, at the same time, many teams I was part of would be very handwavy about the requirements and problems of users. You can call it the ”they’re holding it wrong” or ”why don’t they just…” attitude. Many engineers are passionate about building things but seldom think deeply about why they’re building something. The assumption is that if it comes from the PM or the founders, it must be right so let’s use the latest cool piece of tech to build whatever they need.

In my experience, at worst most engineers out there don’t know how their code will affect users, or in most cases, they focus on the tech and their view of the product and how it should work. This happens either because they don’t ask or because their PM — if they are lucky to have one — doesn’t share enough context or data on outcomes. I don’t blame founders or product managers for not sharing enough information with the engineering team. We (engineers) are all guilty of assuming too much and not asking questions when we should.

I’m personally trying to change that as a CTO, and I understand why it’s hard. We are constantly pressured to deliver quality within timelines we can’t commit to. At the same time, we have to keep on learning so we can discover better ways to solve the technical problems we are tasked with. None of those should be an excuse, but if you never ask about your users, you will never get answers. The worst thing you can do as an engineer is to make assumptions that aren’t validated at all.

In the past, I would get annoyed when I’d hear an engineer in our team say something like, ”I have no idea how people use this feature”. I was not annoyed because they said it, but because I could clearly see I had failed to offer enough context. I had failed to help the team grow empathy for our customers, and therefore I had made it even harder for them to build the right solutions. This is especially painful when you’re creating a product that is all about cultivating that empathy.

I think that the willingness to understand customers has to come from both the engineering team and the PMs. We all have to find better and easier ways to embed context about our customers into conversations and to share it as often as possible.