- Build Vs. Buy has become build vs. die. The great companies will need to be world class builders
- If something is core to your business , something hour customers deeply care about, you should build. Otherwise, buy. The way you integrate micro services and build the customer facing solutions is what will differentiate you
- Don’t neglect to ask your developers what you should build vs buy
- Leverage and lean on software over hardware as much as possible. Software can iterate and be updated daily. It can plug into other tools and always become more useful. Hardware, by contrast, is quite static and slow
- If you’re an incumbent, it isn’t enough to simply hire developers, you have to change your entire culture and mindset. Own the code and be agile, move quickly and iterate. You should think of yourself as a software company that happens to do X, rather than simply doing X
- We are in the third great era of software, one of building blocks rather than solutions. These building blocks are APIs and today’s leading companies stitch together APIs into unique value propositions. They are chunks of code that can be combined in an infinite way. These now comprise your digital supply chain and it is important to understand how they work and what to look out for. AWS changed the game by creating the foundation for these building blocks. This created a new species of startup that was much faster and leaner than their predecessors. It also allowed for small teams and individuals to buy software rather than only the C-Suite at large enterprises
- Business people and developers tend not to naturally work. However, things get easier when business people start sharing problems rather than solutions and let the creative developers figure it out. Code is creative
- Experimenting is key but you have to have a hypothesis. What are you measuring? What does success and failure look like? Will the opportunity be big enough? These things must be written down before you start and will help guide your progress
- Think of each small team as an independent startup where the product or service is clear, pricing is transparent and there is a contract. This makes collaboration easy as it is mostly automated through documentation and APIs. Think of your output as a product that is serving a customer, even if that customer is internal.
- Small teams are easier to coordinate and they need a vision and a customer they care about. Small, multidisciplinary teams with single threaded leaders keeps the teams agile, accountable, close to the customers, and knowing that their work matters
- Agile - plan, develop, test, deliver, assess
- Expect changes (limit WIP, push decisions out as much as possible), close collaboration between business development and devs
- Rather than adding bodies, look to see if you can invest in improving your infrastructure
What I got out of it
- Sharing problems rather than solutions, understanding how to structure effective developer teams (small, customer they care about, transparent pricing, agile, single threaded leaders, accountable, close to the customer) will stay with me
