68 Matching Annotations
  1. Jan 2023
    1. I’m noteven going to give you a sales system, really; I’m giving you theframework to create your own.

      the promise of this books is a framework for instantiating sales systems

    2. Here’s the advantage in sales we introverts have over our extrovertedpeers: We don’t rely on our personality. In the absence of naturaltalent, we have to rely on a process...and in the long-run, processbeats personality. Every time.

      process over personality, it the long run the first trumps the latter

    3. By rehearsing three differenttopics, Alex doesn’t need to be spontaneous, nor does he have towait out those long pauses while he and the potential client findtheir verbal footing. He now goes into a meeting already prepared toinitiate—and, more important, control—the small talk. Establishingrapport is no longer a chore or a necessary evil. It’s a to do: a taskthat Alex is relaxed and prepared for because he already knows howthe routine goes.

      prepare canned material since you're not naturally spontaneous

    4. Introverts, on the other hand, just rely on the system.

      Rely on the system

    5. “Build it and they will come” maywork in the movies, but if that’s your strategy in business, you’re justcounting the days till you close your doors.

      build it and they will come is a fantasy

    6. So, they concentrate on the work. Business owners oftengo into business for themselves because they’re great at theirfunctional skill. Lawyers start their own firms because they knowthe law. Electricians start their own electrical contracting companiesbecause they’re good electricians. IT professionals start their ownconsultancy business because they’re proficient with a specificplatform.But just because you’re good at something—or even great atit—doesn’t mean that customers will automatically show up atyour door.

      customers will not show at your door because you're good at something!

  2. Dec 2022
    1. Just as long-distance runners push through pain to experience the pleasure of “runner’s high,” I have largely gotten past the pain of my mistake making and instead enjoy the pleasure that comes with learning from it. I believe that with practice you can change your habits and experience the same “mistake learner’s high.”

      This is a great analogy: getting past the pain of failing but enjoy the learning. It's not about the falls along the way, it's about the path and the lessons learned along the way

    1. The principles you choose can be anything you want them to be as long as they are authentic—i.e., as long as they reflect your true character and values

      principles allow you to stay true to your character and values

    2. Think for yourself to decide 1) what you want, 2) what is true, and 3) what you should do to achieve #1 in light of #2 . . . . . . and do that with humility and open-mindedness so that you consider the best thinking available to you.

      Principle 1:

    3. While it isn’t necessarily a bad thing to use others’ principles, adopting principles without giving them much thought can expose you to the risk of acting in ways inconsistent with your goals and your nature.

      You can use another's principle but just don't adopt them without thinking about it

    4. To be principled means to consistently operate with principles that can be clearly explained.

      To be principled = having clear, explainable principles with which you operate

    5. If instead we classify these situations into types and have good principles for dealing with them, we will make better decisions more quickly and have better lives as a result.

      classify situations and have good principles for dealing with them

    6. Principles are fundamental truths that serve as the foundations for behavior that gets you what you want out of life. They can be applied again and again in similar situations to help you achieve your goals.

      What principles are: fundamental fondational truths

    7. Whatever success I’ve had in life has had more to do with my knowing how to deal with my not knowing than anything I know.

      Establishing a system for learning from mistakes

    1. Strategy needn’t be the purview of a small set of experts. It can bedemystified into a set of five important questions that can (and should) beasked at every level of the business: What is your winning aspiration?Where should you play? How can you win there? What capabilities do youneed? What management systems would support it all? These choices,which can be understood as a strategic choice cascade, can be captured on asingle page.

      aspire to capture the cascade on a single page

    2. The final strategic choice in the cascade focuses on management systems.These are the systems that foster, support, and measure the strategy.

      Measuring resonated with me. It gives a sense that management is about measuring and indeed what can't be measured can't be controlled. Management is about controlling

    3. Two questions flow from and support the heart of strategy: (1) whatcapabilities must be in place to win, and (2) what management systems arerequired to support the strategic choices? The first of these questions, thecapabilities choice, relates to the range and quality of activities that willenable a company to win where it chooses to play. Capabilities are the mapof activities and competencies that critically underpin specific where-to-play and how-to-win choices

      Capabilities = activities and competencies that are the foundation to where-to-pay and how-to-win choices

    4. To determine how to win, an organization must decide what will enable itto create unique value and sustainably deliver that value to customers in away that is distinct from the firm’s competitors. Michael Porter called itcompetitive advantage—the specific way a firm utilizes its advantages tocreate superior value for a consumer or a customer and in turn, superiorreturns for the firm.

      How to win requires a competitive advantage: unique value proposition + deliver it

    5. Where to play selects the playing field; how to win defines the choices forwinning on that field. It is the recipe for success in the chosen segments,categories, channels, geographies, and so on. The how-to-win choice isintimately tied to the where-to-play choice. Remember, it is not how to wingenerally, but how to win within the chosen where-to-play domains.

      This choice is tightly coupled with "Where to Play": it's not only How to win, but it's "How to win within the chosen where-to-play domains"

    6. The next two questions are where to play and how to win. These twochoices, which are tightly bound up with one another, form the very heart ofstrategy and are the two most critical questions in strategy formulation.

      The two most important questions in strategy formulation are: where to play and how to win. They define the specific activities of the organisation.

    7. At Olay, the winning aspirations were defined as market share leadershipin North America, $1 billion in sales, and a global share that put the brandamong the market leaders. A revitalized and transformed Olay wasexpected to establish skin care as a strong pillar for beauty along with haircare. Establishing and maintaining leadership of a new masstige segment,positioned between mass and prestige, was a third aspiration.

      Concrete winning aspirations

    8. The first question—what is our winning aspiration?—sets the frame for allthe other choices. A company must seek to win in a particular place and in aparticular way. If it doesn’t seek to win, it is wasting the time of its peopleand the investments of its capital providers. But to be most helpful, theabstract concept of winning should be translated into defined aspirations.Aspirations are statements about the ideal future. At a later stage in theprocess, a company ties to those aspirations some specific benchmarks thatmeasure progress toward them

      You must aspire to win otherwise you're wasting people's time

    9. Consider the salesperson in the Manhattan store. She defines winning asbeing the best salesperson in the store and having customers who aredelighted with her service.

      I like this individual examples. It shows that it has to go up to there as well

    10. The result is a set of nested cascades that cover the fullorganization (figure 1-2)

      Strategy span the full depth of the organisation: starting at the corporate level, going through the brand or departmental level, and finishing at the individual levels

    11. pecifically,strategy is the answer to these five interrelated questions:1. What is your winning aspiration? The purpose of your enterprise, itsmotivating aspiration.2. Where will you play? A playing field where you can achieve thataspiration.3. How will you win? The way you will win on the chosen playing field.4. What capabilities must be in place? The set and configuration ofcapabilities required to win in the chosen way.5. What management systems are required? The systems and measuresthat enable the capabilities and support the choices.

      Strategy is a series of five cascading questions

    12. Our intent is to provide you with a do-it-yourself guide to strategy. Weoffer you the concepts, process, and practical tools you need to create anddevelop a winning strategy for your business, function, or organization—astrategy that serves your customers better and enables you to compete moresuccessfully and to win.

      The promise of this book is to be a practical do-it-yourself guide to strategy so that every business leader can develop a winning strategy for his organisation.

    13. Strategy is a relatively young discipline. Until the middle of the lastcentury, much of what people now think of as strategy was categorizedsimply as management.

      Strategy is not management

    14. Taken together, the five choices, one framework, and one processprovide a playbook for crafting strategy in any organization.

      To craft a stratagy in any organisation, one must: 1. Five Choices 2. Strategy logic flow framework 3. Reverse Engineering - Process

    1. While you might think that pairing less experienced engineers is a waste of time, every single time I had a less experienced engineer work by themselves, I ended up regretting it.

      This has been my experience this year

    1. Passons en revue rapide les moyens pour développer les compétences au sein d’une organisation (service, entreprise, administration, association…) :le recrutement (apport de compétences externes pérenne) ;l’externalisation / la sous-traitance (apport de compétences externes ponctuel ou pérenne) ;la formation (apport de compétences internes pérenne) ;la redéfinition des postes de travail (meilleure adéquation des compétences internes) ;l’apprentissage sur le tas ou en situation de travail : l’apprenant développe seul ses compétences (développement individuel des compétences) ;l’accompagnement individuel : mentorat, coaching (déblocage et développement individualisé des compétences) ;la mise en place de groupes de qualité, pour la résolution de problèmes ou le codéveloppement (développement collectif des compétences internes) ;l’autoformation : assister à des conférences, se former en dehors des dispositifs, tenir une veille... (développement autonome des compétences internes).  

      Il y a 8 façon de développer les compétences au sein d'une organisation allant du recrutement, en passant par la formation, la mise en situation et l'autoformation

    1. Quand vous lisez cette définition, vous pouvez remarquer des points importants. Le premier, c’est qu’il faut qu’il y ait écart ; le deuxième, c’est que cet écart concerne les compétences. Enfin, le troisième, c’est qu’on est centré à la fois dans le temps (“un moment donné”) et sur une personne (“un individu”).

      Besoins = * +écart (niveau actuelle, niveau espéré) * + compétences * + temps * + cible

    1. Le “P” placé en début du PADDIE+M est quant à lui une phase de planning, qui permet de fixer un cadre temporel bien défini au projet. Cela est notamment nécessaire pour les projets d’envergure ou les projets contraints par le temps.

      Utiliser le PADDIE+M lorsqu'on est sur un projet d'envergure et/ou contraint dans le temps

    2. les objectifs pédagogiques (qui diffèrent des objectifs de formation)

      Quelles est. cette différence ?

    1. Ils sont complémentaires et souvent “en cascade” : la définition des orientations permet d’aider à la conception des dispositifs. Chaque dispositif conçu nécessite d’être rendu opérationnel et requiert donc une ingénierie pédagogique.

      Step by step

    1. À la fin de ce cours, vous serez capable de :analyser un besoin de formation ;designer un dispositif pertinent ;développer ce dispositif en équipe ;implémenter la formation ;évaluer l’action de formation.

      Les objectifs pédagogiques du cours

    2. L’ingénierie est un processus structuré et méthodique qui permet de passer de besoins opérationnels à la mise en œuvre d’une solution.

      Ingénierie: - Méthode, structure, processus - Pas des besoins à une solution

      C'est cela que je n'ai pas saisi en discutant avec les universités françaises

    3. Cela correspondrait à ne pas faire le travail d’ingénierie, car il n’y aurait pas eu d’analyse.

      L'ingénierie nécessite une analyse avant de poser des solutions

  3. Nov 2022
    1. The “Goals, Signals, Metrics” framework is the most important thing I learned from Ciera, while at Google. This is a framework for defining metrics:Define the actual goal you’re trying to accomplish. Opt for a descriptive definition, for example, say “here is a description of what we want to actually accomplish with our work.” Not the vaguer, “I want to measure X.”Define signals. How would you know if you accomplished that goal, if you had infinite knowledge of everything? These are called “signals.” For example, a signal is “how happy are people with my product?” You cannot directly know how happy people are with your product, unless you’re magically all-knowing. However, if having happy customers is one of your goals, then this is the right signal for that.Figure out your metrics. These are proxies for that signal. Metrics are always proxies, there are no perfect metrics.

      Goals, Signals, Metric framework for defining metrics

    2. You can’t ask everybody about everything, all of the time. This seemingly simple and straightforward statement was one of our most important learnings. It seems obvious when you say it out loud, but implementing this insight is more complicated!To implement the approach of asking developers different questions at different times, you use some math and observation. We needed to get statistically significant data over a certain period of time, for a certain population of developers. However, we set ourselves the constraint to only ask a developer one question, about one thing, every X number of days. So, we couldn’t ask about 300 different tools at once; we needed to narrow our questions down to larger workflows. Even with this narrowing, we could not get enough data unless we asked everybody about all of them, all of the time.Despite our efforts, we still needed to keep a developer survey in place. Developers are happier answering 30 questions in ten minutes, once a quarter, than getting a daily email with one question – even if it only takes 30 seconds to answer.’Note from Gergely: For its own reasons, Amazon does get employees to answer one question per day via the Connections app, as covered in Inside Amazon’s Engineering Culture.

      This an interesting insight, contrasted by seemingly by Amazon's practice. I'll need to explore it because I might find some interesting practices that can be applied to KDA

    3. Across the software industry, many companies have adopted the “religion” of being data-driven when it comes to user-facing products. It’s a big area of focus when training new Product Managers: how to collect data, how to present it, how to analyze it, and what to do with the results. However, this is not necessarily an area of focus for software engineers.

      This is an interesting point. The last sentence kind of gives an indication that's we've all been doing engineering wrong. Shouldn't it be data driver all along ?

    1. Engineering—The Practical Application of Science

      That's for me the key insight here: engineering is applied science!

    1. Figure 4.5 What can you do to encourage or allow the stakeholders to modify their behavior to help achieve the business goal?

      I would have included the why here

  4. Oct 2022
    1. Both Behavior Driven Development and Test Driven Development are examples of Example Driven Development.

      Example Driven Development

    2. Acceptance tests often use a full or near-full application stack, whereas unit tests concentrate on individual components in isolation. Unit tests make it easier to focus on getting a particular class working and identifying what other services or components it needs. Unit tests also make it easier to detect and isolate errors or regressions. You’ll typically write many small unit tests in order to get an acceptance criterion to pass (see Figure 3.12). At the unit testing level, teams practicing BDD often use Test Driven Development, or TDD, to drive out the actual implementation

      this interplay between BDD and TDD: BDD for end to end features TDD to grow the components and units that are needed to make the feature pass

    3. This is a typical BDD approach, often referred to as “outside-in”. As we implement a layer, we will discover other things it needs to function, other services it needs to call. We have a choice; we can either build these things straight away, or we can put them to one side, model them as an interface or a dummy class, and come back to them later. If the first approach works just fine for simpler problems, for more complex code it is generally much more efficient to stay focused on the work at hand.

      Outside in approach, coupled with the london and chicago style usage in the wild

    4. Writing the executable specifications before writing the code is a great way to discover and flesh out the technical design you need in order to deliver the business goals. It helps you discover what domain classes would make sense, what services you might need, and how the services need to interact with each other. It also helps you think about how to make your code easy to test. And code that is easy to test is easy to maintain.

      Programming by intention

    5. They aren’t too sure what this service should look like just yet, but they do know that it needs to give them a list of proposed departure times. And writing the glue code gives them the perfect opportunity to experiment with different API designs, and see what they like best.

      Programming by intention

    6. The test reports will be generated using Serenity BDD,[7] an open source library that makes it easier to organize and report on BDD test results.

      Finding out about this tool for the first time

    7. We can use examples like the ones Tracy and her team recorded as the basis for more formal acceptance criteria. In a nutshell, the acceptance criteria are what will satisfy stakeholders (and QA) that the application does what it’s supposed to do.

      Acceptance criteria provide a way for stakeholders and QA to verify whether a feature is completely implemented

    8. In this section, we’ll see how to take these business-focused examples and rewrite them in the form of executable specifications. You’ll see how you can automate these specifications, and how doing so leads to discovering what code you need to write. And you’ll see how these executable specifications can be a powerful reporting and living-documentation tool.

      From user stories and examples to acceptance criteria written in gherkin

    9. Often these conversations uncover uncertainty or complexity, which leads us to split features into smaller chunks. In Scrum, a User Story needs to be small enough to deliver in a single sprint. If a feature will take more than one sprint to build, it is good practices to split a it into several stories that can be delivered incrementally over several sprints. This way, the team can get feedback earlier and more often, which in turn reduces the risk of error.

      This is talked about in the user story book

    10. Tracy uses a technique called Example Mapping[4] to make the discovery process more visual. She notes down these examples and rules using colored post-its on a wall: blue cards represent the business rules, and green cards represent examples and counter-examples of these rules. Pink cards represent questions that we don’t have answers for right now. A yellow card at the top of the board reminds us which feature or user story is being discussed.

      Example Mapping as a tool to illustrate the discovery process

    11. Many teams find Impact Mapping (see Figure 3.3) a useful exercise to discover and prioritize high-level capabilities and features that can help deliver a business goal. Impact Mapping helps business and technical people discuss business goals through the prism of four fundamental question: "Why are we doing this (i.e. what are our business goals)?", "Whose behavior do we need to change (i.e. who are the key actors)?", "How might their behavior change (i.e. what changes in their behavior would help us achieve our business goals)", and "What software features might support this behavior change".

      Impact Mapping = Why Who How What

    1. Figure 7.1 In this chapter we’ll look at how to make the automated executable specifications robustand maintainable.

      This is great!

      In my opinion, the author should have included it in chapter 6.

    2. The order here is important. When you plan features and stories, your principal aimshould be to deliver business value. Start out with what business value you intend toprovide B, then who needs the feature you’re proposing, c, and finally what featureyou think will support this outcome d

      This is an interesting take: start with the business need

    3. A key part of this practice involves defining scenarios, or concrete examples of howa particular feature or story works. These scenarios will help you to validate andextend your understanding of the problem, and they’re also an excellent communica-tion tool. They act as the foundation of the acceptance criteria, which you then inte-grate into the build process in the form of automated acceptance tests. In conjunctionwith the automated acceptance tests, these examples guide the development process,helping designers to prepare effective and functional user-interface designs and assist-ing developers to discover the underlying behaviors that they’ll need to implement todeliver the required features.

      Scenarios are concrete exemples of how a particular feature or story works

    4. Figure 1.11 High-level and low-level executable specifications generate different sorts of livingdocumentation for the system

      Business goal -> Features (User Stories) -> Exemples (Acceptance Criteria) -> Executable Specifications (In a BDD tool) -> Low-Level Specification (Unit Tests)

    5. This notation eventually evolved into a commonly used form often referred to asGherkin.

      The birth of Gherkin

    6. Domain-Driven Design,13 which promotes the use of a ubiquitouslanguage that business people can understand to describe and model a system.

      DDD advocates using the language of the domain to describe and model a system

    7. North observed that a few simple practices, such as naming unit tests as full sen-tences and using the word “should,” can help developers write more meaningful tests,which in turn helps them write higher quality code more efficiently. When you think interms of what the class should do, instead of what method or function is being tested, it’seasier to keep your efforts focused on the underlying business requirements.

      use should in naming your tests, it makes you think about the behaviour of what you are implementing, an NLP technique according to Continuous Delivery guy

    8. Despite its advantages, many teams still have difficulty adopting and using TDDeffectively. Developers often have trouble knowing where to start or what tests theyshould write next. Sometimes TDD can lead developers to become too detail-focused,losing the broader picture of the business goals they’re supposed to implement. Someteams also find that the large numbers of unit tests can become hard to maintain asthe project grows in size.

      The problems with TDD: - not knowing where to start - focusing too much on the tree and forgetting the forest - high coupling between tests and implementation

    9. Behavior-Driven Development ( BDD) is a set of software engineering practicesdesigned to help teams build and deliver more valuable, higher quality software faster.It draws on Agile and lean practices including, in particular, Test-Driven Development(TDD) and Domain-Driven Design ( DDD). But most importantly, BDD provides a com-mon language based on simple, structured sentences expressed in English (or in thenative language of the stakeholders) that facilitate communication between projectteam members and business stakeholders.

      BDD is at the crossroad of TDD and DDD, while giving a common language for stakeholders and team members to understand each others

    10. As practitioners, we like to keep things grounded in real-world examples, soin chapter 2 you’ll see what BDD looks like in a real project, all the way from dis-covering the requirements and automating the high-level acceptance criteria tobuilding and verifying the design and implementation, through to producingaccurate and up-to-date technical and functional documentation.

      I should probably start here

    11. The goal of this book is to help get teams up and running with effective BDD practices.It aims to give you a complete picture of how BDD practices apply at all levels of thesoftware development process, including discovering and defining high-level require-ments, implementing the application features, and writing executable specificationsin the form of automated acceptance and unit tests.

      The book promise's to get you up and running with BDD

    Annotators

    1. pecification by Example, agileacceptance testing, Behavior-Driven Development, and all the alternative names for thesame thing solve these problems. This book will help you get started with those prac-tices and learn how to contribute better to your team, regardless of whether you qualifyyourself as a tester, developer, analyst, or product owner.

      The book promise/objective: get started with Agile Acceptance Testing, Behaviour-Driven Development (BDD), and Specification by Exemple.

    2. If you’re a practitioner, like me, and your bread and butter come from making or helpingsoftware go live, this book has a lot to offer. I primarily wrote this book for teams whohave tried to implement an agile process and ran into problems that manifest themselvesas poor quality, rework, and missed customer expectations. (Yes, these are problems, andplainly iterating is a workaround and not a solution.)

      These are the problems that currently plage us: poor quality, expectation not understood or miscommunicated, etc.

    3. It presents the collectiveknowledge of about 50 projects, ranging from public websites to internal back-officesystems. These projects involved diverse teams, from small ones working in the same of-fice to groups spread across different continents, working in a range of processes includ-ing Extreme Programming (XP), Scrum, Kanban, and similar methods (often bundledtogether under the names agile and lean). They have one thing in common—they all gotthe practices of collaborating on specifications and tests right, and they got big benefitsout of that.

      Experience over 50 projects, working in different ways however each having a common things: collaborating on specification and test right to achieve positive returns

    Annotators

    1. How to set up your Software Development Teams?This is one of the most important questions to consider when working to create great software.

      Central question to this paper I suppose

    Annotators