Playback speed
×
Share post
Share post at current time
0:00
/
0:00
Transcript

Ürgo Ringo: Product Engineering | Ep. 1

Ürgo, ex-Wise, joined Wise.com as one of the first 12 engineers or so. As former colleagues from Wise, we had a great chat about product engineering, domain-driven design, and team collaboration.

Ürgo and I had a great chat! I will give a short summary of key takeaways that I got from this valuable discussion with Ürgo.

Map For Engineers Podcast on Youtube.

Key takeaways

Work in agency is different from work in a product company

Work in agency (outsource) vs product company is different for an engineer. In agency, you get a lot of experience with different projects, but you don’t own a product or its outcomes.

In contract, in a product company, engineers should care about the end product, getting the feedback from users and customers. Responsibilities and impact are on the next level for an engineer in a product company, that you don’t get in a project-based work in an agency.

Knowledge sharing inside a team. Avoid knowledge silos

It’s important to avoid pockets of knowledge in a team, where sub-groups form, because then it’s hard to have a cohesive team. There are many tools to avoid it, for example:

  • Pair programming

  • Deliberately rotating knowledge among people

  • Working in pairs (not necessarily pair programming, but just solving some problem together) on a topic for a short time (e.g. a week or two). But then switching pairs and topics, to avoid knowledge silos.

  • I wrote in detail about some practices that I employ in Pactum to avoid knowledge silos in the team in the article Values, Principles and Practices in Engineering Team.

Product engineering begins where the comfort of the coding ends

Ürgo wrote amazing article about this topic, called Product Engineer, available in his Medium.

This diagram below is from Ürgo’s post, but it summarizes the essence of product engineering very well:

Diagram of Ürgo Ringo, from his blog post Product Engineer

Product engineers need to establish frequent feedback loops to get signal from users on the usefulness of what they delivered. This is essential for closing the feedback loop. Once you get learnings, you repeat the process: Learn → Build → Ship → Learn → …[repeat]

Domain-Driven Design: Metaphors are important

Coming up with metaphors when modelling software is very important. When you come up with a good metaphor, try to embed it into your ubiquitous language.

GenAI in Software Engineering

GenAI won’t replace product engineers for a while. In fact, product engineering becomes even more essential than just coding. Coding is just a tool, a means to an end. Product engineering skills will be ever so valuable - to understand which product to build, to iterate, to learn from your users and customers, to be creative. Product engineers will leverage GenAI tools to automate non-interesting tasks (e.g. creating this next frontend component, if it can be automated quickly).


And that’s a wrap! I will be recording new episodes soon. Feel free to subscribe if you found it valuable.

Map for Engineers Podcast is also available on Substack, Spotify, Apple Podcasts, or on any of your favourite podcast app.

See you in the next episode!

Vitalii Lakusta

Discussion about this podcast

Map for Engineers
Map for Engineers Podcast
Creating a map of knowledge and tools for software engineers.