1,023 Matching Annotations
  1. Oct 2020
    1. Yet many teams struggle to achieve a unified way of evaluating what they’ve delivered. Only 1 in 10 have a process for assessing the success or failure of newly-launched products and features.

      we've done this informally, but might consider a more formal approach

    2. For the product teams lacking a systematic way of logging these feature requests, pain points, and other bits of user feedback, a lot of valuable information ends up slipping through the cracks.

      we are working at getting better at this but there is room for improvement

    1. Microlearning: Knowledge management applications and competency-based training in the workplace

      Lynn C. Emerson, & Zane L. Berge. (2018). Microlearning: Knowledge management applications and competency-based training in the workplace. Knowledge Management & E-Learning: An International Journal, 10(2), 125–132.

      https://search.ebscohost.com/login.aspx?direct=true&AuthType=shib&db=edsdoj&AN=edsdoj.8793b57070bd45918c6e0875f40ced31&site=eds-live&scope=site&custid=uphoenix

      The focus of this article is a threefold discussion on microlearning 1) how microlearning best practices facilitate knowledge acquisition in the workplace by engaging and motivating employees through short, personalized, just-in-time learning, 2) ways microlearning integrates with knowledge management applications through situational mentoring, and 3) how competency-based microlearning, via subscription learning, is both an innovative approach to e-learning and an asset to learning organizations focused on improving the performance of their employees.

      8/10

    1. So today, as a somewhat limited experiment, I played around with my Hypothes.is atom feed (https://hypothes.is/stream.atom?user=chrisaldrich, because you know you want to subscribe to this) and piped it into IFTTT. Each post creates a new document in a OneDrive file which I can convert to a markdown .md file that can be picked up by my Obsidian client.

      Trying to see if this work for me when linking with google drive. Unsure how to convert to markdown.

  2. Sep 2020
    1. This last characteristic may be the easiest to evaluate. Unless the position is very junior, I’ll usually hire product managers who’ve actually shipped a product. I mean from start to finish, concept to launch. Nothing is a better indication of someone’s ability to ship great products than having done it before. Past performance is an indication of future success
    2. I often joke that much of the time your job is to be the advocate for whoever isn’t currently in the room - the customer, engineering, sales, executives, marketing. That means you need to be capable of doing other people’s jobs, but smart enough to know not to. Great PMs know how to channel different points-of-view. They play devil’s advocate a lot. They tend to be unsatisfied with simple answers.
    3. So what do I look for in a PM? Most importantly, raw intellectual horsepower. I’ll take a wickedly smart, inexperienced PM over one of average intellect and years of experience any day. Product management is fundamentally about thinking on your feet, staying one step ahead of your competitors, and being able to project yourself into the minds of your colleagues and your customers.
    1. Whatever the future intentions of the PM, one thing remains for certain: this position is at the intersection from where founder strategy, user feedback, development team management, and market awareness come together. From what’s been said, it certainly appears that this is not a role that you “fall” into, but rather could aspire to be in.
    2. What’s more, to be a good PM, individuals also need to understand that it’s all about the bigger picture. Great managers “win” games, meaning that it’s not about getting a product out the door, but by ensuring that over the long-term, the team helps solve a larger problem. Nash says it’s not about getting an “E for effort” and brush off things that don’t work.
    3. The product manager isn’t the one that’s just sitting around overseeing the various teams and seeing whether it’s on track to meet the scheduled delivery or launch date. They are the ones who need to understand the market and that means knowing who the competitors are, what consumers want, and being able to help the marketing and sales teams better target them.
    1. More tactically,helping your team often means being the person who writes and summarizes notes after a long meeting, or writing a spec to make sure you have captured the team’s consensus and plan in written form.
      • Write notes after meeting and share with team.
    2. A lot of people describe a product manager as a CEO of the product or the “owner” of the spec, but I think that over-ascribes influence and authority to the product manager. The best teams operate in a way where the team collectively feels ownership over the spec and everyone has had input and been able to suggest and promote ideas. The best product managers coordinate the key decisions by getting input from all team members and are responsible to surface disagreements, occasionally break ties, and gather consensus (or at least ensure that everyone commits to a plan) when decisions get made.

      "CEO" of the product is an overrated term to describe PM.

      • Everybody on the team should feel heard/collective ownership
    3. More importantly, once shipped, the best product managers can measure whether the product shipped is the right one. They should work closely with the team to make sure the right moments in the product are measurable, and that the hard questions about whether people are really using the product can be answered.

      Once shipped good PM's know how to measure success fo the product

    4. Great product managers listen to user feedback all the time — whether it’s from usability tests, meeting users in the field, reading support emails or tweets, or working with the people in your company who do all of those things on a daily basis.

      *

    1. What do you think the most important things we should be doing over the next year? What will get in the way of us doing that? What’s going well, i.e. what should we make sure we don’t change? Is there anything you think I should know about?

      Good questions to ask as a new PM

    1. To me, abandoning all these live upgrades to have only k8s is like someone is asking me to just get rid of all error and exceptions handling and reboot the computer each time a small thing goes wrong.

      the Function-as-a-Service offering often have multiple fine-grained updateable code modules (functions) running within the same vm, which comes pretty close to the Erlang model.

      then add service mesh, which in some cases can do automatic retry at the network layer, and you start to recoup some of the supervisor tree advantages a little more.

      really fun article though, talking about the digital matter that is code & how we handle it. great reminder that there's much to explore. and some really great works we could be looking to.

    1. So why don't we extract the shared state out of the components, and manage it in a global singleton? With this, our component tree becomes a big "view", and any component can access the state or trigger actions, no matter where they are in the tree!
    1. It turns out that even the length of time an element has been mounted is an important piece of state that determines what pixels the user sees. And some of this state can’t simply be lifted into our application state.

      What this means is that our desire to express UI using pure functions is in direct conflict with the very nature of the DOM. It’s a great way to describe a state => pixels transformation — perfect for game rendering or generative art — but when we’re building apps on the web, the idea chafes against the reality of a stateful medium.

  3. Aug 2020
    1. I have a theory that time scarcity is also linked to something I'll call time scatteredness. This happens when you really have no idea how long it takes us to complete tasks, and this skews how much time you think you have or need.

      I relate to this so much I can still feel the sting on my cheek from where it slapped me

    1. it’s a wise idea to begin tracking your time in order to get a more realistic handle on how long specific projects and tasks take you. That’ll override your optimism bias and keep your expectations for your own productivity in check.
  4. Jul 2020
  5. Jun 2020
    1. I could get a lot more done in an 8-9 hour day with a PC and a desk phone than I get done now in a 9-10 hour day with a laptop /tablet / smartphone, which should allow me to be more a lot more productive but just interrupt me. I don't want the mobile flexibility to work anywhere. It sucked in management roles doing a full day then having dinner with friends and family then getting back to unfinished calls and mails. I much prefer to work later then switch off totally at home.
  6. May 2020
    1. Secrets management is one of the most sensitive and critical disciplines in all of DevOps and is becoming increasingly important as we move toward a fully continuous deployment world. AWS Keys, deploy keys, ssh keys are often the key attack vector for a bad actor or insider threat, and thus all users and customers are concerned about robust secrets management.
    1. One of the main goals is to avoid some giant, never-ending task backlog, either within the current week’s “To do later” section, constantly being carried over week after week and growing in size, or in a separate backlog.md, or similar, file, also just growing in size and causing most tasks to be completely burried & lost. Either a task should be scheduled as “I plan to work on this” or it should be completely discarded (it can always come back later if it turns out to be important).
    1. In our review of engagement issues, the first area we found is the importance of simple, clear goals. When people have clearly defined goals that are written down and shared freely, everyone feels more comfortable, and more work gets done. Goals create alignment, clarity, and job satisfaction—and they have to be revisited and discussed regularly.
    1. Early compilations involved various combinations of four crucial operations: storing, sorting, selecting, and summarizing, which I think of as the four S’s of text management. We too store, sort, select, and summarize information, but now we rely not only on human memory, manuscript, and print, as in earlier centuries, but also on computer chips, search functions, data mining, and Wikipedia, along with other electronic techniques.
    1. However, please note the following: it will depend on how those subdomains are defined. Are they just subsections of a project that belongs together like help.example.com or blog.example.com (and many other possible arrangements that are part of one and the same setup)? In such a case, using the same policy is appropriate. Problems arise when completely different projects which have little to do with one another and whose data collection practices also differ so significantly that they require different privacy policies.
    1. What people will say is that estimates are for planning – that their purpose is to figure out how long some piece of work is going to take, so that everybody can plan accordingly. In all my five years shipping stuff, I can only recall one project where things really worked that way.

      Project estimations are just energy drainers and stress producers

    2. Be explicit about the difference between hard deadlines

      Different types of deadlines:

      • Hard deadline - something seriously bad to the business will happen if the deadline isn’t met
      • Soft deadline - somebody will look bad if the deadline isn’t met
      • Internal deadline - target internal to the team that will not affect anybody outside of the team
      • Expected completion date - team currently predicts that work will be completed
  7. Apr 2020
    1. L’appel de la liberté se fait entendre dans le management, mais une fois encore les managers naviguent de Charybde en Sylla : comment concilier la demande de plus de liberté de mouvement de certains collaborateurs, avec la nécessité de produire plus de résultats en respectant plus de normes ? Avec, à l’horizon, cet impératif de recréer du sens, de refonder l’autonomie du travail dans des organisations kaléidoscopes…

      Question argumentative. L'autrice pose le problème qui occupe sa réflexion et qui induit le thème du débat. La question reformule les problématiques énoncées en début de texte.

    2. La capacité à gérer les entre-deux, en créant de la continuité et de la substance pour porter les transitions entre les pics d’intensité. Cela demande d’acquérir des ressources et de développer des capacités spécifiques de management et d’innovation permettant de générer ces avantages périodiques et de garantir la pérennité.

      Point de vue de l'autrice en réponse à l'avantage concurrentiel transitoire.

    1. wouldn't let me send a two-line memo to another department without showing it to him before I sent it. John's leadership style was oppressive. He micr0-managed everything. I learned from the hellish experience of working for him that unless somebody wants another set of eyes on their correspondence, it's insulting and a waste of time to micro-manage your team members' email messages.
    1. Caroline Diard Enseignant-Chercheur en Management des Ressources Humaines - Laboratoire Métis, École de Management de Normandie – UGEI

      EC en Management de RH champs de référence légal, réglementaire (juridique) Intérêt pour la performance des entreprises. The conversation ajoute dans sa bio:

      • Management des RH
      • Droit du travail
      • Négociation sociale
      • Télétravail
      • Vidéo-protection
      • Contrôle des salariés
    1. Relational databases are designed around joins, and optimized to do them well. Unless you have a good reason not to use a normalized design, use a normalised design. jsonb and things like hstore are good for when you can't use a normalized data model, such as when the data model changes rapidly and is user defined. If you can model it relationally, model it relationally. If you can't, consider json etc.
    2. Joins are not expensive. Who said it to you? As basically the whole concept of relational databases revolve around joins (from a practical point of view), these product are very good at joining. The normal way of thinking is starting with properly normalized structures and going into fancy denormalizations and similar stuff when the performance really needs it on the reading side. JSON(B) and hstore (and EAV) are good for data with unknown structure.
  8. Mar 2020