Skip to content

The unicorn project summary

Some interesting notes to keep in mind when engaging on projects:

  • Punishing failure and “shooting the messenger” only cause people to hide their mistakes, and eventually, all desire to innovate is completely extinguished.
  • Creating software should be a collaborative and conversational endeavor—individuals need to interact with each other to create new knowledge and value for the customer.
  • what is happening: Too many promises to the market? Bad engineering leadership? Bad product leadership? Too much technical debt? Not enough focus on architectures and platforms that enable developers to be productive?
  • Technical debt refers to things we need to clean up, or where we need to create or restore simplicity, so that that we can quickly, confidently, and safely make changes to the system.
  • Dev productivity responsibilities should be assigned to only the most senior and experienced engineers.
  • Without constant feedback from a centralized build, integration, and test system, developers really have no idea what will happen when all their work is merged with everyone else’s.
  • developers need a system where they can get fast and continual feedback on the quality of their work. If you don’t find problems quickly, you end up finding them months later. By then, the problem is lost in all the other changes that every other developer made, so the link between cause and effect disappears without a trace.
  • Most people are trying to follow a process, like ticketing process, as defined by others, and to do the best, the rules are wrong not the people response. This is important to remember before judging a person's response.

  • Examples of questions:

    • How many transactions per second are we expecting for product displays and orders?
    • howmany transactions per second are the current builds capable of handling right now?
    • That will tell us how many servers we need for the horizontally scalable portions, as well as how far we’re off for the vertically scaled components, like the database.

  • As a developer always ask yourself, How can you create anything of value if you don’t have feedback on how it’s used?

  • The risk of polyglot solution, how any one person could possibly understand the system as a whole, especially when it’s built from so many different technology stacks.
  • Technology decisions are commitments to support them for years or even decades—these are decisions that go far beyond just one team.
  • Ops is a cost center. The only way to fund infrastructure is through new projects. If you don’t find new funding sources, you’re screwed. They are scared for their position.
  • The lack of trust and too much information flowing around is causing things to go slower and slower.
  • Without continuous builds, we are like a car manufacturer without an assembly line, where anyone can do whatever they want, independent of the plant goals.
  • Code deployment lead time, code deployment frequency, and time to resolve problems are predictive of software delivery, operational performance, and organizational performance, and they correlate with burnout, employee engagement, and so much more.
  • Simplicity is important because it enables locality. Locality in our code is what keeps systems loosely coupled, enabling us to deliver features faster. Teams can quickly and independently develop, test, and deploy value to customers. Locality in our organizations allows teams to make decisions without having to communicate and coordinate with people outside the team, potentially having to get approvals from distant authorities or committees so far removed from the work that they have no relevant basis to make good decisions
  • pay down technical debt as a part of daily work. Not just features delivery. Technical debt is inherently neither good nor bad—it happens because in our daily work, we are always making trade-off decisions. We make a grave mistake when we don’t realize how much this impacts our future productivity.

  • There are five ideals on what we do:

    • First Ideal of Locality and Simplicity. We need to design things so that we have locality in our systems and the organizations that build them. And we need simplicity in everything we do.
    • The Second Ideal is Focus, Flow, and Joy. It’s all about how our daily work feels. do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work? Being able to test and push code to production is more productive, makes for happier customers, creates accountability of code quality to the people who write it, and also makes the work more joyful and rewarding.
    • The third ideal is Improvement of Daily Work. Reflect upon what the Toyota Andon cord teaches us about how we must elevate improvement of daily work over daily work itself.
    • The Fourth Ideal is Psychological Safety, where we make it safe to talk about problems, because solving problems requires prevention, which requires honesty, and honesty requires the absence of fear. In manufacturing, psychological safety is just as important as physical safety.
    • the Fifth Ideal is Customer Focus, where we ruthlessly question whether something actually matters to our customers, as in, are they willing to pay us for it or is it only of value to our functional silo?

  • When everyone knows what the goals are, teams will self-organize to best achieve those goals. They realize that they are on a journey of learning and exploration, and that making mistakes is inevitable. Creating ever-safer systems and continual improvement is now viewed as part of daily work.

  • To address concurrency and race condition functional programming principles with immutable function, where output is derived from input, are better tools to think with.
  • Developers need to access production logs without asking ops.
  • transformational leadership requires understanding the vision of the organization, the intellectual stimulation to question the basic assumptions of how work is performed, inspirational communication, personal recognition, and supportive leadership. It’s about excellence, the ruthless pursuit of perfection, the urgency to achieve the mission, a constant dissatisfaction with the status quo, and a zeal for helping those the organization serves.
  • Norm Kerth says in the Agile Prime Directive, ‘Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.’
  • When investigating an issue, start by assembling a timeline and gathering details on what happened. The goal is to enable the people closest to the problem to share what they saw, so we can make our systems safer. The only rule is that you can’t say ‘I should have done X’ or ‘If I had known about that, I would have done.
  • personas so that everyone can better understand and relate to the people who you’re building products for.
  • it is important to think through problems clearly, writing things down enforced a logical rigor that he thought was very important for leaders to have. “How can you send a company down a strategic path when you haven’t thought through what all the implications are?
  • This is not a story about small beating large; it’s fast beats slow.
  • Adopting and event based streaming platform, unlike the centralized Data Warehouse, the responsibility for cleaning, ingesting, analyzing, and publishing accurate data to the rest of the organization would be pushed into each business and application team, where they have the most knowledge of what the data actually means. It also helps to support an immutable event sourcing data model, which would be a massive simplification compared to the current morass of complexity built up over decades. Errors in data uploads are being caught right away through automated tests. The teams can easily access any data from across the organization, and easily add new data, contributing to the entire collective knowledge
  • Are we playing to win and to establish the technical supremacy we need to keep up with what the business needs, or do we just keep limping along, shackled to things built decades ago, and tell our business leadership to throw in the towel and stop having good ideas?
  • To avoid too much pressure on old back end systems, you can reconfigure the load balancers to rate-limit the transactions.
  • External systems may also been down or rate limit our access. Example is shipping providers, shipping options api. if they can’t get information from all shippers, they’ll just present ground shipment as the only option.
  • Demonstrate how the future requires creating a dynamic, learning organization where experimentation and learning are a part of everyone’s daily work.
  • the Hoare principle: “There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complex that there are no obvious bugs in it.

Company strategy based on geofrey Moore's book:

  • Horizon 1 is your successful, cash-cow businesses, where the customer, business, and operational models are well-known and predictable.
  • Almost all businesses fade over time, because any profitable operation will attract competitors. The economic logic of selling reductions in transactional cost is irresistible and inevitable
  • Horizon 2 lines of business represent the future of the company. They may introduce the company’s capabilities to new customers, adjacent markets, or with different business models. These endeavors may not be profitable, but this is where we find higher-growth areas. It is from here that enterprising leaders create the next generation of Horizon 1 businesses.
  • Horizon 3, where the focus is on velocity of learning and having a broad pool of ideas to explore. The name of the game is to prototype ideas and to answer as quickly as possible the three questions of market risk, technical risk, and business model risk: Does the idea solve a real customer need? Is it technically feasible? And is there a financially feasible engine of growth? If the answer is no to any of them, it’s time to pivot or kill the idea. “If the answer is yes, then the idea is continually developed until it earns the right to graduate to Horizon 2, where the business builders take over.

  • Horizon 1 thrives on process and consistency, on rules and compliance, and on bureaucracies, which create extraordinary resilience. These are the mechanisms that allow greatness to be consistently delivered over decades. In contrast, in Horizon 3, you must go fast, you must be constantly experimenting, and you must be allowed to break all the rules and processes governing Horizon 1.

  • Regardless of what horizon you’re in, this is the Age of Software. Almost all business investment now involves software. And that means we must elevate developer productivity.

  • Companies are unable to properly invest in the next generation of innovation. they underinvest in Core, because they are being controlled by Context. Cores are the central competencies of the organization. These are things that customers are willing to pay for and what investors reward. Context is everything else. how much of the $80 million of your technology spending is Core, actively building competitive advantage, and how much of it is Context, which is important and maybe even mission-critical, but still needs to be standardized, managed down, and maybe even outsourced entirely?
  • Example of value for event sourcing: in current app there are twenty-three deeply nested API calls made whenever someone checked for product availability. With microservuce dedicated to serve one complex query api, represented as values that were re-computed every time one of their inputs changed, which comes from event sourcing. Now it is one api call. It will decouple all of these services from each other, allowing teams to make changes independently, no longer reliant upon the single integration team to implement their business rule changes. It will make the tracking of data and state across the enterprise simpler, safer, more resilient, easier to understand, cheaper to run, faster to deliver. It applies functional programming ar scale as an architecture principles.
  • The power to disrupt the customer experience is no longer just the domain of the FAANGs: the Facebooks, Apples, Amazons, Netflixes, and Googles,” Erik continues. “Instead, it is within reach of almost any organization that wants to disrupt the market. And who better to disrupt things for the benefit of customers than the organizations that already have a decades-long relationship with them?
  • What’s needed is focus and urgency, and the modern methods of managing the value creation process.
  • Small doesn’t beat big, instead, fast beats slow. And fast and big will win almost every time.