JustAnswer’s Post

Values-to-costs is the universal language in ambitious product development everyone should speak. We love to use the word 'value', for good reason. Problem is it is often very vague. At best, handicapped to monetary things like revenue. At worst, empty words. Value is much, MUCH more. It is fundamental. We are much more in tune when it comes to costs. It comes naturally to us. Challenge here is forgetting to address different kinds and different time horizons of costs. Simultaneously. Need to make intelligent decisions? Deal with risks? Maximise the likelihood of success? Make the absolute maximum out of your finite resources? Mastering the language of values-to-costs is the shortcut to consistently successful software engineering and product development. Do you speak it? ----- P.S. Did you know this sort of product engineering management excellence doesn't require massive investments in silly transformation projects? If not - DM and let's talk more. #productdevelopment #engineeringmanagement #productengineering

Stop wasting time writing code - optimize your efforts strategically! As engineers, it's tempting to dive into every project headfirst, but strategic coding and planning involves knowing what to prioritize and what to skip. Here are some questions to guide your decisions: ✅ Strategic Alignment: Does this project align with your long-term strategy and core values? Will it significantly enhance your unique offerings? ✅ Control: Do you need complete and full control over this feature/capability, or can you leverage other solutions or partnerships? ✅ Investment: What resources are needed to deliver and maintain the initiative?  What’s the potential return on that investment? Rather than saying yes to everything, pause and assess. Invest your engineering resources wisely, focusing on projects that reinforce your strategic advantages. Remember, knowing what not to build is just as crucial as knowing what to build. Choose wisely to maximize your impact. #ProductEngineering #SoftwareEngineering #CTO #CPO #ProductStrategy #TechStrategy #EngineeringLeadership

"I am wrong" These are often the hardest words to say, especially in senior positions. In software engineering, people's reluctance to admit mistakes can quickly become a roadblock to deliver quality in product development. As part of the software development process, teams often discuss multiple approaches to solution design. These discussions can become difficult if any of the engineers refuse to accept flaws in their approach. The best engineers I've worked with all embraced admitting mistakes with a positive attitude. Once, a senior engineer's review comment on my pull request sparked a two-day debate. Finally, I pulled him in a meeting, explained my reasoning, and he simply said, "Guess we're always learning," admitting his mistake and openness to learning. Another time, the team discussed a complex architecture proposed by a senior that would waste resources. We knew it would be difficult, but the team presented their solution and explained the drawbacks. The senior engineer, after a pause, conceded, "I actually prefer this design now," focusing on the product's benefit, not his ego. A growth mindset, where we aim to learn and create a better product, makes admitting mistakes easier. Have you faced a similar situation? How do you handle a leader unwilling to admit mistakes? #Engineering #leadership #growthmindset #softwaredevelopment

➗ Let's practice some 𝘍𝘦𝘳𝘮𝘪 𝘌𝘴𝘵𝘪𝘮𝘢𝘵𝘦𝘴 to the work of Engineering Managers! 📉 What are the economics of an Engineering Manager spending part of their working hours contributing code? 👥 Let's assume you're the Engineering Manager of a team of 5 software engineers. 👨🏼💻 Let's assume you decide you can dedicate 20% of your time to coding with the team. 📅 That's 1 day a week. 📈 Now your team's capacity suddenly went from 5 x 5 = 25 “developer days” a week to the impressive amount of 26 developer days a week. 🎉 Congratulations: you're now spending 20% of your time every week to increase the team's capacity by a staggering 4%. 😑 With a team of 8 people, that number goes down to 2,5%. That's assuming your contributions are in line with the average developer in your team. If you have a lot more senior people in your team, those results will be even lower. Do you believe that would be the most impactful usage of your time as an EM, besides the occasional spike or urgency? #EngineeringManagement #EngineeringLeadership #SoftwareEngineering #FermiEstimate --- 🔔 Enjoy my content? Follow me for daily content on Engineering Leadership 🗞️ Do you like long-form content? Subscribe to my weekly newsletter “Sudo Make Me a CTO” (link in bio)

Software Engineers: masters of spotting edge cases 🕵️♀️🔍. One of the most fascinating things about working with software engineers as a product manager is how quickly and easily they spot edge cases you didn’t even think of. I had a recent meeting for a product I'm working on, and during the meeting, we presented what I thought was a comprehensive set of scenarios to Engineering. I thought I had covered everything—until the engineers started chiming in: ❌ “What if a user does this?” 🧐 “What about this scenario?” 💡 “What about this case?” I was amazed, thinking, "𝘏𝘰𝘸 𝘥𝘪𝘥 𝘵𝘩𝘦𝘺 𝘵𝘩𝘪𝘯𝘬 𝘰𝘧 𝘵𝘩𝘢𝘵 (𝘢𝘯𝘥 𝘴𝘰 𝘲𝘶𝘪𝘤𝘬𝘭𝘺)?" So, I had to go back to the drawing board to think a bit more deeply. 🤔 It got me reflecting on why engineers are so good at identifying edge cases. 𝗛𝗲𝗿𝗲’𝘀 𝗺𝘆 𝗵𝘆𝗽𝗼𝘁𝗵𝗲𝘀𝗶𝘀: I remember back in my university programming courses, professors would dock points if your code didn't account for edge cases. Maybe that constant practice for engineers builds this muscle for spotting edge cases? (𝗖𝗮𝗹𝗹𝗶𝗻𝗴 𝗮𝗹𝗹 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝘀, 𝘄𝗵𝗮𝘁’𝘀 𝘆𝗼𝘂𝗿 𝘁𝗮𝗸𝗲 𝗼𝗻 𝘁𝗵𝗶𝘀? 𝗗𝗼𝗲𝘀 𝘁𝗵𝗮𝘁 𝗿𝗲𝘀𝗼𝗻𝗮𝘁𝗲?) 🤝 This experience also reinforced a powerful product management lesson that I recently read in a book: 𝗗𝗼𝗻’𝘁 𝘄𝗮𝗶𝘁 𝗳𝗼𝗿 𝘁𝗵𝗶𝗻𝗴𝘀 𝘁𝗼 𝗯𝗲 𝗽𝗲𝗿𝗳𝗲𝗰𝘁 𝗯𝗲𝗳𝗼𝗿𝗲 𝗴𝗲𝘁𝘁𝗶𝗻𝗴 𝗳𝗲𝗲𝗱𝗯𝗮𝗰𝗸. Involve stakeholders—like engineers—early and often. Their input will save you from blind spots and costly rework. Do you use this approach in your projects? How do you ensure different perspectives are baked in early? I'd love to hear your thoughts in the comments 💬. #ProductManagement #SoftwareEngineering #Collaboration #ProductDevelopment #DareToDO #TeamWork

Moving fast in software-intensive product development doesn't mean what you think it means. Velocity Lead time Cycle time Throughput These are all potentially good things. Sometimes they cause more harm than benefit. Problem is - they are used in the context of software *production*. Once you realise what the purpose of development is, the meaning of going fast changes completely. The speed of learning and knowledge acquisition are the true, defining qualities of being fast at development. Question is - How fast are you going and at what cost? Ready to break free from the constraints of conventional development methodologies and truly embrace rapid innovation? Let's explore how to shift your focus from velocity to learning and accelerate your product development journey. For real. ------ 🔔 How about drop me a follow if you found this interesting? I'd appreciate it a lot! I write mostly about product development and serious software engineering management. 🙌 Happy to continue the chat in the DMs if you want to know more. #softwareengineering #engineeringmanagement #productdevelopment

Staying in control of software-intensive product development can't be done by conventional means. Imposing order and "control" by conventional management means is diametrically opposed to the nature of development. The more control is imposed, the more it will resist. Most issues stem from this one single source. Paradoxically - being on the driver's seat means letting go of old habits. Let me suggest a different way. Radically more effective development builds on completely different ideas. On far more robust theories of reality. On far more robust principles and practices that are in harmony with the work. I'm making 2024 the year when my clients will graduate into serious value management. Software Engineering Management for adults. Leaving silly growing pains, Silicon Valley fads and agile transformations behind. Just engineering excellent results. Value Engineering. No mass transformations. Just some smart, powerful injections here and there. Being in control of your development spend. Being in control of your long-term spend. Being in control of the results. Are you with me? #softwareengineering #productdevelopment #engineeringmanagement

🔍 Mastering the Art of Problem-Solving in Software Engineering In the dynamic world of software engineering, each day brings its unique set of challenges. I've honed a systematic approach that helps me on the process of problems solving. Here's a breakdown of the steps I follow: 1. Learn from History - Often, the problems we face have been encountered before. I start by exploring how these were addressed in the past, saving time and leveraging existing insights. 2. Zoom Out - It’s essential to grasp the broader system context. This helps in framing the problem correctly. I expand my knowledge base and develop multiple hypotheses regarding potential causes. 3. Zoom In - With various hypotheses ready, I design targeted tests to systematically invalidate each one, which helps in narrowing down the most plausible causes. 4. Check Bias - Our biases can skew our hypotheses. Constant vigilance about personal biases is crucial to remain objective. 5. Question Everything - We don't know what we don't know. I approach every piece of 'known' information with a healthy dose of skepticism. 6. Communicate Constantly - I ensure to keep the team updated at every step, which not only ensures collective responsibility but also enriches the solution with diverse perspectives. 7. Write to Think - Writing is not just documentation—it’s a critical tool for clarity and organizing thoughts. 8. Document Thoroughly - After resolving an issue, I meticulously document the problem-solving process by a pipeline of cause to after, describing each step as a hypothesis rather than a confirmed fact. 9. Anticipate Problems - Every time you solve a problem you create another one. Recognizing and documenting these anticipations prepares us for future issues. 🤝 Let’s Connect & Discuss! What strategies do you employ in your problem-solving? Do you have a different approach or tips to share? Comment below—we can all learn from each other’s experiences! #SoftwareEngineering #ProblemSolving #TechLeadership

Ever wondered why some software projects end up taking longer and costing more than initially expected? 🤔 A common culprit is the planning fallacy – underestimating the time and resources required for a task. This cognitive bias, identified by Nobel laureates Kahneman and Tversky 🏆, affects project planning, leading to missed deadlines and unrealistic expectations. So, how do we overcome this challenge in the world of software development? Let's explore! 🚀 #SoftwareDevelopment #ProjectManagement #TechLeadership

Recently, thanks to an amazing process coach I was fortunate to meet at an organization I am working with, I came to know about Donald Reinertsen's book "The Principles of Product Development Flow: Second Generation Lean Product Development". The reference to lean product development in the title piqued my interest from the outset since I had been introduced years ago to the work by Mary and Tom Poppendieck on Lean Software Development and at that time I got very excited about it for the insights they provided about how the principles that had been well established in industrial production could be applied to software development to improve its practices and outcomes. But Reinertsen's writings have already been transformative of my understanding of how software product development could be further improved to make it more economically sound. It also has surprised me often with insights that go against many ideas I had previously embraced from earlier readings; for one thing: there are some key differences between industrial production and endeavors like software product development that, contrary to my previous thinking, can make some of the principles and practices of the former very counterproductive for the later. Whenever that happens, in the book you'll find plenty of alternative principles and tools that are argued, and very convincingly, to be better suited for software products. One prominent example is the concept of Cost of Delay, and how that metric can radically change the notions of economically sensible priorities of competing work, or the tradeoffs of optimizing for capacity utilization versus cycle time, or the importance of controlling queues of work in progress through the organization (whose impact are generally not accounted for, but should be). Though I haven't gone through it all yet, I can readily recommend this book without any reservations, particularly to Engineering Managers. It would be ideal that other stakeholders, like Product Owners and Lead Engineers, also be made familiar with this as well. The concepts are at times a little difficult to grasp, even if you have an engineering background; but their value will generally be worth the extra effort and Donald does a good job trying to clarify them with useful analogies and examples of how they can translate to practice. https://lnkd.in/eaiuvQ6n (no referral links) #productdevelopmentflow #leansoftwaredevelopment #costofdelay