How a real-life software/product engineering team works

I was honoured to be invited to talk by the Zakey initiative to a group of fresh graduates, most of them with few or no professional experience, so my goal was to have a high-level introduction to the overall end-to-end process of software development (mostly focused on a product). Some of the topics covered were:
- Software development process from a 10.000 foot view (big picture)
- How a team decides what to work on: things like OKR, KPI, priorization, product management, etc. (in a very basic and superficial way)
- How the team got organized and our ownership end to end, our day by day
- Everything that happened from the moment we made a change in the code until that change arrived to the hands of our users
- A little bit of my vision about software development and the profession
- Some resources to further learn or deepen into some of the topics mentioned

Transcript

1. How a real-life software/product engineering team works Isidro López 29th October 2025
5. A little bit about my background… Hemos venido a jugar... Product developer (and Product Engineering Coach and…) <curious> Telecommunications Engineering, Psychology, Social and Cultural Anthropology, Executive MBA, etc. </curious> 5 <industries> Telecom, fintech, music, social networks, water management, consultancy, trainer, public companies, etc. </industries> <roles_in_sw_development> Software Engineer, Backend, Frontend, Infrastructure, Engineering Management, Technical Coach, etc. </roles_in_sw_development> @islomar islomar@gmail.com
6. Agenda • Brief context about the companies • Software development process from a 10.000 foot view (big picture) • Team’s composition • How a team decides what to work on • How we develop and deliver/deploy the code • Our day by day • My vision about SW and Product development (overview) • Final recap and key takeaways • Recommended people and resources • Q&A and discussions 6
7. Some context and types of companies
8. • Product companies build and sell their own software. You join their team to improve that specific product over time. ◦ A product is never done ◦ For example: Spotify, Netflix, Duolingo, Notion, GitHub, etc. • Consultancy/services companies build software for other clients. You work on different projects for different organizations, adapting to each client’s needs and deadlines. ◦ A project usually has a specific start and end dates. ◦ For example: ThoughtWorks, Accenture, Deloitte, etc. My experiences: • Both. • Mostly product companies during the last years (the base for the examples in this talk)
9. Software development process from a 10.000 foot view (big picture)
10. Highly iterative and incremental process Decide what to work on (problem space) Develop and deliver (solution space) Get feedback from your users, customers, business and systems (measure) 🕵 󰠁 💰 ⚙
11. https://es.pinterest.com/pin/863283822295358286/
12. Team’s composition
13. http://venngage.com/blog/free-people-icons/ Product Manager An autonomous cross-functional team QA/Tester Engineering Manager / Team Lead / Tech Lead Product Designer / UX Researcher Software developers/engineers (backend, frontend, infrastructure, etc.)
14. The team • Software developers/engineers or Product Engineers ◦ The ideal skills depend on the context ◦ Ideally: more generalists than specialists ◦ Backend, Frontend, Infrastructure knowledge ◦ In my last teams ▪ We all had a deeper knowledge about one thing (e.g. with backend with Python) but managed to work with anything else (e.g. frontend with React and Infrastructure with AWS) • Product Manager / Product Owner ◦ IMPORTANT: they should work in strong collaboration with the rest of the team ▪ Involved other people in conversations and decisions ◦ Define the product’s vision, strategy and roadmap ▪ Product discovery: understanding user and customers’ needs and business context ▪ Define Business Analytics (measure the impact) ◦ Maximize product value generated by the team • Engineering Manager or Team Lead or Tech Lead ◦ Depending on the specific responsibilities: people, processes and technology. ◦ Guide and support the team to work together on shared goals in order to provide a sustainable positive impact
15. The team: some roles not always present • Product Designer / UX expert ◦ Per team or shared ◦ A product designer job involves creating user-centric designs by combining user research, prototyping, and visual design to solve user needs and meet business goals • QA / tester ◦ Person collaborating with the rest of the team members in order to raise the quality of the software delivered ▪ External quality: how much it fulfills our users/customers’ needs ▪ Internal quality: how easy is the code to evolve, to maintain ◦ It should not be a bottleneck but an enabler ◦ My personal opinion: better not a specific person, quality should be built-in, every developer/engineer should take care of that ▪ There are exceptions in some contexts
16. How a team decides what to work on
17. Decide what to work on (problem space) Develop and deliver (solution space) Get feedback from your users, customers, business and systems (measure) 🕵 󰠁 💰 ⚙
18. Do the right thing (Product discovery) Do the things right (Product delivery) Do the right things right
19. 2. Define team goals • Aligned with company-wide goals • For example, every 3 months • Done by Product Manager in collaboration with the rest of the team • There should be periodic check-ins: how are we going? 1. Define company-wide goals • OKRs (Objective and Key Results → 1-3 Objectives and 3-5 Key Results) • For example ◦ O: Design a UX so intuitive that there are no customer service inquiries. ◦ KR1: Fewer than 1 UX-related customer service inquiries per week. • The frequency depends on the company: e.g. every 3/6 months or every year. There should be periodic check-ins: how are we going? • Many other alternatives, like KPI (Key Performance Indicator) https://www.whatmatters.com/get-examples
20. Plan the work: product refinement and planning • Split the high-level “team goals” into specific actions, tasks… ◦ User Story ▪ It describes a problem (not the solution). It’s a brief, simple description of a software feature from the end-user's perspective, explaining what they want to achieve and why. ◦ Vertical slicing ▪ It’s a technique that breaks down a large feature into smaller, end-to-end functional pieces, delivering a complete, usable increment of the product with each slice. • We use different collaborative tools to document and write down the user stories, for example Jira, or Linear. ◦ They are online tools used for planning and building products, tracking all the tasks to be done, issues, who works on what, etc.
21. https://www.visual-paradigm.com/scrum/user-story-splitting-vertical-slice-vs-horizontal-slice/
22. https://www.gianty.com/vertical-slice-game-development/ https://www.visual-paradigm.com/scrum/user-story-splitting-vertical-slice-vs-horizontal-slice/
23. User Story: enable pay for purchases in an online store Possible vertical slices (they could be independent user stories): • Enable payment with a credit card • Enable payment with Paypal • Enable payment from a web browser • Enable payment from a mobile phone • Enable payment from the native mobile in iOS (Apple) • Enable payment from the native mobile in Android
24. Prioritize! 📃 • You can not work on everything at once: you need to prioritize • What is the most important thing to work on right now? • Done by the Product Manager in collaboration with the rest of the team • Recommendation: limit the work in progress (WIP)! • Many different techniques and heuristics ◦ Some questions we can ask ourselves: ▪ How many people would benefit from this change? ▪ What is the criticality of the issue to solve? ◦ Pareto’s rule ▪ Get 80% of the value with 20% of the effort ◦ Eisenhower matrix: urgency vs importance ◦ CD3: Cost of Delay Divided by Duration ◦ Urgency profiles
25. How we develop and deliver/deploy to Production
26. Decide what to work on (problem space) Develop and deliver (solution space) Get feedback from your users, customers, business and systems (measure) 🕵 󰠁 💰 ⚙
27. Example 1: Continuous Deployment pipeline https://martinfowler.com/bliki/StranglerFigApplication.html 27
28. Example 2: Continuous Deployment pipeline (DevEx team) 28 Drama-free experience: you even forget you’re continuously deploying to Production!! 🥳
29. Measure and decide next step Decide what to work on (problem space) Develop and deliver (solution space) Get feedback from your users, customers, business and systems (measure) 🕵 󰠁 💰 ⚙
30. Get feedback ASAP! • From our users and customers ◦ Find out how users are using our product, detect frictions in a process (e.g. user registration), etc. ◦ Tools (some examples): ▪ Amplitude ▪ Mixpanel ▪ PostHog • From our systems (mostly production servers) ◦ Monitoring, logging, tracing and o11y (observability) ◦ Detect something going wrong in the server (reacting) or something with a “bad trend” (preventing) ◦ Tools (some examples): ▪ DataDog ▪ Sentry ▪ New Relic ▪ Honeycomb ▪ ELK (ElasticSearch + Logstash + Kibana) ▪ Grafana + Prometheus ▪ PagerDuty (alerting)
31. Example of the day by day of a team
32. Everyday’s actions… • Daily meeting in the morning (~ 15 min. long) ◦ Goal: align about the current status of work in progress, detect blockers, plan the day, etc. • Code (and deploy)! ◦ Many options with more or less collaboration: ▪ Pair programming, ensemble programming, individual programming ( +code review), etc. ◦ Most teams work more isolated, in Git branches, only talking when they have issues. ◦ Ask the Product Manager or stakeholders to clarify anything needed ◦ My last teams: we deployed automatically to production servers several times per day ▪ In most places, they deploy every few days (hopefully not weeks) • Collaborative sessions ◦ E.g. need to discuss something with people from other teams for synchronizing initiatives • Product refinement ◦ Continuous discovery of the work to be done ◦ Conversations with stakeholders, people from other teams, product manager
33. Actions or “rituals” with lower frequency • Team’s retrospectives ◦ Every 2-3 weeks ◦ Goal: reflect all together in a safe place about what is going well and what should be improved • Some teams work in cycles of fixed-length, usually called “sprints” ◦ Usually 2-3 weeks length ◦ Sprint demo: sharing in public or to the stakeholders what it has been done for getting feedback ◦ Sprint planning: team’s meeting to decide what to work on during the next sprint, efforts, etc. • My personal preference: everything so continuous as possible ◦ Continuous planning and prioritization: ad-hoc, when needed ◦ Continuous demo: each time a new change is done, not accumulating them ◦ Continuous delivery/deployment: deploy to Production servers and your users every improvement as it happens, not every few days/weeks but several times per day.
34. Tools used • Communication ◦ Company’s chat with different rooms ▪ Slack, Discord, etc. (Slack is the most popular one) ◦ Work visualization and management: Jira, Linear, Trello, Asana, etc. ◦ Videoconference tools: e.g. Google Meet, Teams, Zoom, Jitsi, Slack/Discord, etc. • Diagraming, ideation and group’s sessions ◦ For example: Miro, Excalidraw, diagrams.net ◦ Documentation: Miro, Markdown files, Notion, Confluence, etc. • Software development ◦ IDEs: JetBrains (e.g. IntelliJ, PyCharm, WebStorm), Visual Studio Code, Vim, Cursor, etc. ◦ VCS: GitHub, GitLab… https://survey.stackoverflow.co/2025/technology
35. Example board in Jira
36. My vision about SW and Product development (overview)
37. My humble vision and a couple of advices (I) 🧭🔭 • Technology (software included) is a means to an end ◦ Our goal is to solve problems and achieve an impact, not to write code: outcome over output ◦ The more simple the solution, the better • Try to understand “why”, “what for”, what are the root needs (from our users, customers and business people) → Product mindset! • Focus: limit the work in progress, “Stop starting, start finishing!” • Don’t get attached to a specific technology: get so many tools in your toolbox as possible (in baby steps, with time) • Optimize for fast feedback loops: quickly getting to know if we are going in the right direction, if your code works as expected, if the user gets satisfied, etc. ◦ Small batches/”pieces” continuously put in the hands of our users/customers
38. My humble vision and a couple of advices (II) 🧭🔭 • There is no trade-off between quality and speed: ◦ The way to go fast in a continuous and sustainable way is to maintain good quality • Go beyond the surface: learn the software development subjacent principles. ◦ Not only a language syntax, but common principles which apply to many different languages ◦ How to write code easy to evolve: easy to understand, to maintain, to change, to test, etc. • Grow a continuous improvement and learning mindset (but no pressure) ◦ Also connected with growing an “experimentation mindset” → scientific method • Collaboration over competition: be kind, work as a team, join communities… ◦ SW development is a social activity. ◦ Empathy, respect, trust, transparency, fun! • Find a mentor. • Share: even if you think that it’s obvious, it always brings value to someone
39. Final recap and key takeaways
40. • There are MANY different realities out there: among companies and among teams inside the same company. • Software development is a social/team activity ◦ Empathy, respect, trust, transparency… • Technology is a means to an end. ◦ Master the software engineering principles, they are traversal to any technology! ◦ Get curious about the business, try to understand your users: differentiate yourself! • Collaborate, join communities, find a mentor 🤗 • Never stop learning and improving… but in baby steps 🐜
41. Recommended people and resources 41
42. People to follow • Eduardo Ferro ◦ https://www.eferro.net/ ◦ https://bsky.app/profile/eferro.net • Jessica Kerr ◦ https://jessitron.com/ ◦ https://bsky.app/profile/jessitron.bsky.social • Dave Farley ◦ https://bsky.app/profile/davefarley77.bsky.social ◦ https://www.youtube.com/c/ContinuousDelivery • Charity Majors ◦ https://charity.wtf/ ◦ https://bsky.app/profile/charity.wtf • Jez Humble ◦ https://bsky.app/profile/jezhumble.net ◦ https://continuousdelivery.com/ • Geepaw Hill ◦ https://mastodon.social/@GeePawHill ◦ https://www.geepawhill.org/ • Clare Sudbery ◦ https://insimpleterms.blog/ ◦ https://bsky.app/profile/claresudbery.bsky.social • Kent Beck ◦ https://www.kentbeck.com/ ◦ https://bsky.app/profile/kentbeck.com • Emily Bache ◦ https://bsky.app/profile/emilybache.com ◦ https://www.youtube.com/@EmilyBache-tech-coach • Martin Fowler ◦ https://bsky.app/profile/martinfowler.com ◦ https://martinfowler.com/ 42
43. Articles and videos • The power of an agile mindset (talk by Linda Rising) • Lean Software Development: Amplify Learning • Kent Beck on why software development is an exercise in human relationships (video) • Lean + XP + Product Thinking – Three Pillars for Sustainable Software Development • Iterative and Incremental Development: we need both • Vertical slicing listicle • Martin Fowler’s blog