FocusWorks

Because focus is what matters


I'm a Product-Minded Engineer

Wednesday, 1 Jan 2020 Tags: development

All Different Types

I have had the privilege of working with a bunch of great engineers. There is no better way to learn the craft of software engineering that to practice it with – and get feedback on your work from – those with more experience. I could never have learned so much or leveled up as I have without each of them.

Those more experienced engineers also act as a measuring stick. I look at them, see what they know, what they can do, and see how far I have come and how far I have yet to go. Repeatedly, I have had to admit, I won’t get there. I used to think it was only a matter of time, but my mind is changing.

I have worked with a front-end engineer who knew the nitty-gritty details of working with this in JavaScript, kept up with the new features coming down the pike, and could wax eloquent about using Functors and Monads. of about scope in JavaScript as well as the Web APIs, I won’t get to their depth of knowledge. I have worked with a backend engineer who, when faced with a difficult problem, would go off, do some research, and come back with some new, barely known feature of Postres that he would leverage to solve the problem.

I don’t know I will be like either one of them. In some sense I am not the engineer’s engineer who loves the technical problems for their own sake. Or has a prodigious memory to recall archane details after a few moments of concentration. At times this has aggrivated my case of imposter’s syndrome. “If I can’t get to their level, then I really don’t belong in this field.” So says the insecure part of myself.

What is a Product Engineer?

So, it was something of an epiphany when I read an article by Gergely Orosz. It began with these words:

Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions.

I said, “That’s me!”

Start with the Why

While I really, reeally enjoy writing code, I want to know why the feature is being build, how it will fit into the product, and how it will benefit the user. This is what makes if feel meaningful to me. I know other engineers who just love the details of a technical problem. But I need to see the big picture.

And I am always asking, “Why?” This is chief characteristics of a product-minded engineer, according to Orosz.

Proactive in Offering Ideas

Another Characteristic of a product engineer is being proactive with product ideas/opinions. I see myself in this too.

During our company on-site, we were all encouraged to do a lightening talk to the rest of the company on any subject. The important thing was just to do one. Most coworkers talked about a hobby or interest of theirs. I chose to make a pitch about the the main screen of our mobile app. We were in the middle of a redisign and it was very clear to me that, while we were most of the way there, there was one change that would make it even better. This change would do a better job of setting the user’s expectations of for the purpose of the app. So I made a pitch with all the persuasion I could muster. I am happy to report that my specific proposal was adopted.

Being a product-minded, big-picture thinker as a specific skill that I bring to my team. It is important for success.

All About the Tradeoffs

Another item on the list is offering product/engineering tradeoffs upfront.

In working with our product managers and designers, I feel that this is one of my greatest contributions. They have a great idea for a new feature. Actually this is normally a set of features. Instead of just starting to work on the list, I often go to them and say, “We could knock the first two items out in a day, but the next item will take a week.” Then they can decide which is more important, iterating with small improvements, or waitng for all the work to be done, so the feature feels complete. It is all about the tradeoffs. There is no clear right answers. But what enables a better decision is having the relevant information.

Conclusion

I love learning and am constantly striving to become a better programmer. However, it is also freeing and empowering to understand where your core talents lie. Because if you are always trying to be like the other developers around you, then your team risks missing our on your particular set of skills. (Cue Liam Nieson here.) I hope sharing my experience here might help you to find your strengths and to be comfortable with those.

I’d love to hear your thoughts. You can hit me up on Twitter.