Issue link: https://read.uberflip.com/i/1479515
"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior." (Martin Fowler) Relentless, continuous refactoring, driven by and supported by the entire product management organization up to the CPO, is foundational for agility (read: learning and adapting). Agility is so often overlooked and so necessary to stay competitive that it can fairly be called a competitive differentiator in itself. You might be resisting this notion. You might ask if product managers really need to get into this technical depth. You may believe that this is a place where you should trust your engineering partners to take care of it. But it's not only about trust. Let's indulge in an imaginative exercise for a moment: suppose you and your engineering partner are life partners rather than work partners. You two have worked it out that your engineering partner is responsible for taking the dog for a walk each evening. You then pressure your partner to go out to dinner and a bar with you every evening, leaving no time to walk Rover. That's not a lack of trust. It's the opposite: you are not supporting your partner. You are asking them to do something and then you are undermining their success. Ask yourself, are you a product manager who pressures your engineering team to skip refactoring every sprint? To get it done without an acknowledgement or praise? To put it off until later? Bad idea: Rover isn't going to wait forever. A little more than twenty years ago, Joel Spolsky said a pretty weird thing in the middle of a rant about software: he said when you start re-writing a software system from scratch "You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years." (Things You Should Never Do). One thing worth paying attention to here is that Joel writes about software (his blog is called "Joel on Software"). And yet, here he is, talking about market leadership and competition — the turf of the product manager. That's because there is a direct relationship between code reuse and moving fast. You might be more obsessed with your customer than you are with your competitors (and rightly so) but customers are an impatient lot, always wonderfully dissatisfied (Jeff Bezos, 2016 Letter to Shareholders). They aren't going to wait around while you build a database from scratch — not unless your new database is the new product you are launching, and maybe not even then. For a team that is all about learning fast and solving customer needs, building new things is reserved for the specific projects that drive those goals. So how do you know when it's possible to re-use? Some things are obvious, for example if your team wants to create a better search system for internal documents, and your product is a website for consumers to find apartments for rent. Yes, off the shelf search for internal documents might be annoying, but more annoying is going out of business because you lose all your consumer traffic to a competitor who is laser focused on the underserved needs of renters. Other choices aren't so obvious: for example, you want to build a product to help scientists write research papers and you know it will need some artificial intelligence (AI) to work. The AI is a critical aspect of the invention — so should you write it from scratch or use something off the shelf? AMAZON WEB SERVICES | COUNSELING FOR POWER COUPLES