FRDM (pronounced free•dom) delivers enterprise-grade Software as a Service that’s transforming how businesses manage risk (like child labor) and increase transparency in their supply chain

FRDM

The exchange-traded fund, or ETF, has become such as successful vehicle for investing that there is likely one for any situation you can dream of. From countries with economic freedom ( ) to the metaverse ( ), you might be paralyzed by the . How can you make sure to choose the appropriate ETFs for your portfolio? FRDM META abundance of choices Where Do I Find Good ETFs? When searching for ETFs, it’s best to first narrow it down with a specific type of objective in mind. Are you looking for a specific region (e.g. China, Europe, Emerging Markets, Domestic)? Are you looking for specific company size (e.g. large-cap, mid, small, micro)? Are you looking for certain themes, commodities, or sectors (e.g. technology, semiconductors, energy, gold)? I would suggest searching via Google rather than your brokerage because the latter will bias results in their favor. The is a popular website that displays a wide selection of ETFs. If you are looking for other options, I would suggest googling “ “. ETF Database ETF Screener If you are not finding what you are looking for, here is a list of some that I have encountered over the past few years. ETF providers Ark Blackrock Cambria Funds Charles Schwab Direxion Fidelity/iShares Invesco JP Morgan Roundhill Simplify State Street Vanguard Wisdomtree Where Will This ETF Fit In My Portfolio? Most investors, myself included, preach diversification of assets within a portfolio. If you adhere to this advice, then you need to establish where this ETF will fit in with your existing assets. This first step is establishing your objective for the ETF. Some key questions to ask yourself are whether this ETF will be: Short term/Tactical vs. Long term/Core holding? Held in a taxable vs. non-taxable account? Domestic vs. International Developed vs. Emerging Markets stocks? High vs. Medium vs. Low dividend/shareholder yield (i.e. value vs. growth stocks)? Large cap vs. Mid/Small Cap vs. Diversified cap size? One sector/industry vs. Diversified sectors/industries? What Does This ETF Contain? ETFs typically contain a basket of stocks or bonds; however, some will include other types of assets (e.g. commodities, crypto exposure, etc.). Using the as an example, we can locate their documentation to further understand what is in this ETF. Within this documentation, the assets being held are often described in the “Objective”, “Overview”, “Portfilo and Management” and “Holdings” sections. Within the documentation, you can find out the following characteristics of VTI: Vanguard Total Stock Market (VTI) “Seeks to track the performance of the .” CRSP US Total Market Index “Large-, mid-, and small-cap equity diversified across growth and value styles.” Top 10 holdings include Apple, Microsoft, Alphabet, Amazon, etc. 27.6 percent is in the technology sector 1.37 percent shareholder yield This information informs you that this is a diversified portfolio of U.S.-based stocks across all industries and sizes. If you want more details you could dive deeper into the that this ETF tracks. ETFs that track an index are “passively managed” (i.e. less active) than ones that are actively managed (e.g. ARKK fund). The active managed ones tend to change holdings more frequently and are often more expensive than the passively managed funds. market index With a shareholder yield of 1.37 percent (i.e. blend of value and growth), shareholders can expect a return of this amount of money for each share. refers to buybacks, debt paydowns, and dividends, while dividend yield only refers to dividends. Value companies tend to have higher shareholder yields and return more cash back to the shareholder, while growth companies tend to reinvest their earnings back into the company. Shareholder yield The objective of the fund is not something to be taken lightly. Because of the popularity of ETFs, there are many available that are more complex than your traditional index fund. If a fund factsheet mentions words such as “leverage”, “covered calls”, “managed futures”, “hedge”, “options wrapper”, or other advanced financial terminology, then you should probably avoid it unless you have a solid grasp or seek a financial professional’s opinion. How Active Do You Want To Be? Choosing ETFs that are more tactical require a pre-determined exit plan as opposed to the long term plays which you can HODL. There is a range of how active you need to be with each ETF. While leveraged ETFs are typically held less than year, target date funds could be held for your entire life. In general, ETFs designed to be core holdings in a portfolio (e.g. SPY, VEA, AGG) can be left alone for decades if the investor chooses to do so. How Liquid Is The ETF? Liquidity can be defined as the ease in which you can buy or sell the ETF (i.e. swap it with cash or for cash). While most funds are easy to buy via clicking a button, the level of liquidity will determine how much it costs to move in and out of these funds. Increased liquidity means it will be quicker and easier to buy the fund at a fair price. Lower liquidity will increase volatility in prices for those funds. There are three methods I use to understand the liquidity of an ETF: Spreads, Assets Under Management (AUM), and Volume. The bid-ask spread for a fund is the difference in the price that someone is willing to pay (the bid) versus the price where someone is willing to sell (the offer or ask). Whether the brokerage displays the bid-ask spread for a fund or not, these still exist under the hood. Brokerages like Robinhood opt for simplicity so they hide this detail, while traditional finance firms like Fidelity will display the information to the investor. A smaller spread (or difference) between the bid and ask means higher liquidity. Take a look at a few ETFs below to see how much this spread can vary from the most liquid (SPY) to the least liquid (TRTY) of the bunch. Another indirect method of determining liquidity is to identify how many assets are under management for that fund or the volume (i.e. activity) for the fund. The more popular funds tend to have higher AUM’s and volume, which correlates with higher liquidity. You can often find the AUM and volume for a fund in ETF screeners (see below). Source: ETFDB : A more advanced statistic related to fund performance and standard deviation is . Higher standard deviation means higher volatility, which is a tough thing to stomach in real time. Note sharpe ratio How Expensive Is This ETF? The expense ratio of a fund is the managerial cost for holding this fund. If the fund appreciates 5%, you will realize a gain of <5% because of this fee*. This fee is incredibly important because many of the funds you encounter are virtually identical. It would be akin to choosing between a white sedan and an off-white sedan where the latter is priced 5,000 dollars higher for no reason. Investing newbies, like myself in 2017, will often make their ETF selections solely based off of ETF expense ratios, and the managerial cost of holding the fund. While this is an incredibly important box to check off, it is not the sole consideration. When comparing funds that seem similar, it might be beneficial to see how correlated the funds are. If two funds have 95 percent correlation, or higher, over several years then you likely can choose the cheaper fund. The process for checking correlations is fairly simple. First, go to a website that calculates the correlation between two funds like . Then, enter two funds that you want to compare, such as the Schwab U.S. Small-Cap ETF (SCHA) and Vanguard Small-Cap Value ETF (VBR). I edited the dates to show a longer time period, going back to 2010. Over the past 12 years, these funds had a correlation of 0.98. Additionally, they had very similar monthly and annual standard deviations. Because they are strongly correlated had similar standard deviations, then it likely will not matter which one you pick. Below, you will see a chart of their performance over time and their correlation results. this one and Source: Koyfin Source: Portfolio Visualizer *There are some exceptions, such as the offered by Fidelity. zero-fee funds Applying The Process As you go through this fund selection process, there are many fantastic, free resources out there. Some of my favorite resources that I use frequently include the following: ETF Database/Screener Wisdom Tree Fund Comparison Tool Koyfin’s data research and analytics tools Thankfully, the cost of buying or selling funds is free or nearly free on most platforms. Therefore, it is easy enough to update your portfolio as you learn more over time. This framework should enable you to have a better understanding of the differences between various funds. Some logical next steps would be improving your understanding of sharpe ratios, risk, and modern portfolio theory in order to build your ideal portfolio. ~ The Data Generalist Financial Disclosure: Anything on this website is not financial advice.

How To Identify A Good ETF

Vice-chancellor and Germany's finance minister, Olaf Scholz, says ‘No’ to Facebook, ‘Yes!” to digital currency. "Such a payment system would be good for financial center Europe and its integration into the world financial system,"  Scholz stated  in a local business news magazine, WiWo. published "We should not leave the field to China, Russia, the US or any private providers," Scholz said directing his comment at . Facebook’s Libra Coin Germany recently a blockchain strategy preventing parallel currencies to be issued, just three weeks ago. Scholz stated, “A core element of state sovereignty is the issuing of a currency, we will not leave this task to private companies.” passed “We cannot accept a parallel currency,” Scholz said during a panel discussion in Berlin. “You have to reject that clearly.” The German cabinet is expected to adopt a comprehensive blockchain strategy on Wednesday which aims to boost the digital transformation of its economy but also tackle the risks stemming from such new technologies.In its blockchain strategy, Berlin says it will liaise closely with its European and international allies to prevent stablecoins from becoming alternative currencies, according to a government document seen by Reuters. “The Federal Government will work at European and international level to ensure that stablecoins will not become an alternative to official currencies,” the document said.” Source Some argue Libra would be “Frankly a dangerous precedent” to shut down. Andreessen Horowitz partner Katie Haun, former Ex-federal prosecutor has contended the United States blocking Facebook’s Libra Coin will certainly come with national security implications. If you’re not familiar with Katie Haun, you should be. On October 6th, broke her down pretty well. CNBC In my words, she’s the successful, intelligent, bombshell that went from DoJ to Btc and she’s taking the crypto world by storm. Katie is the first female general partner at Andreessen Horowitz, and co-heads its $350 million cryptocurrency fund. She and the firm have been a driving force alongside Facebook to launch its libra cryptocurrency. Katie was a  U.S. Department of Justice prosecutor, investigating prison gangs, corrupt officials and the mafia. Her assignment was to “take down bitcoin.” Katie reflects; “They said ‘we have this perfect assignment for you’ — there’s this thing called bitcoin and we need to investigate it,” she says. “That was the first time I’d ever heard of bitcoin.” Katie is now one of the most recognizable investors in the industry,  Ben Horowitz calls her, “the credible face of crypto.” reports, “the social media titan’s project was facing “the same criticisms” and misperceptions that the asset class faces more broadly. CoinTelegraph “They were just heightened and they got more attention because of the high-profile nature of the project and the fact that Facebook was involved. I think it would be a really dangerous thing, and frankly a dangerous precedent to start shutting down technology before it’s built.” “Haun underscored her perspective that there are national security implications if the United States falls behind in terms of cryptocurrency development, pointing to plans to launch competitors to Libra by states such as China and .” . Russia Source . Facebook and their Stablecoin relationship woes continue. PalPal officially pulled out Oct. 4th and Mastercard is rumoring to follow suit. Conclusion Do you think CaLibra will end up being a wallet for other digital assets? I don’t have the answers, but it’s exciting to watch, as Facebook ranked No. 76 in the 2018 Fortune 500 list of the largest United States corporations by revenue. What they do with their platform can potentially change the course of banking history. Need To Know More About Stablecoins? I’ve written a lot about them… read more on or . Medium Hacker Noon I’d love to professionally discuss, collaborate and connect with you all. Would love any feedback, positive and negative; as I’m only here to improve and educate myself/others. So, how can we mutually benefit one another? 💻 Let’s Connect on Social Media 📱 @ LinkedIn @ instagram @ Twitter @ Facebook

Olaf Scholz vs. Facebook's Libra 

You’re a North Korean engineer who’s been selected to develop a new government project. It’s an HTML form, which North Korean political leaders will fill in for purposes. [REDACTED] One of the fields requires the user to select the title by which they prefer to be addressed. , you decide to go for your good old > element. It looks like this on Windows (Chrome): Since the list can get pretty long <select Nothing out of the ordinary, perfectly acceptable in most cases. You know that . But you're not sure if the is aware of this. You feel like this is not too big of a deal, as long as the list is in alphabetical order. <select> has that kind of "search" that jumps to the items as you type Great Leader What about mobile? This is how it looks on Android (Chrome): Android tries to use as much of the screen as possible, covering the address bar. Here it is on iOS (Safari): On iOS, the small number of visible items makes for an awful experience with larger lists. Both of them lack a way to search or filter list items. Will the look the other way? Not wanting to take any chances, you take this matter into your own hands. You want something that can be filtered on mobile, and makes better use of screen real estate. Father of the Nation On desktop platforms this is not too hard to achieve: just a custom dropdown with a text input for filtering. For mobile, you’ll need something different. Let’s focus on the mobile version, and presume that you’ll have some way to pick the correct implementation depending on the platform. This is your plan for mobile: A full-screen modal with a fixed text input at the top for filtering, and a scrollable list of items below it. Your first instinct tells you the implementation should go like this: Select a title X Item 1 Item 2 < = > button onclick "openModal()" </ > button < = = > div class "modal" id "modal" < = > div class "modal-header" < = = > input type "text" id "filter-input" < = > button onclick "closeModal()" </ > button </ > div < = > div class "modal-body" < > button </ > button < > button </ > button  </ > div </ > div { : none; : fixed; : ; : ; : ; : column;
} { : flex;
} { : ; : auto;
} .modal display position top 0 left 0 height 100vh flex-direction .modal .show display .modal-body flex 1 overflow-y modal = .getElementById( ) filterInput = .getElementById( ) {
  modal.classList.add( )
  filterInput.focus()
} {
  modal.classList.remove( )
} const document 'modal' const document 'filter-input' ( ) function openModal 'show' ( ) function closeModal 'show' The important bits: to fix the modal to the screen; position: fixed to make the height 100% of viewport's; height: 100vh Modal divided in two parts: header and body; Header’s height defined by its children, no need to set it explicitly; Body fills the remaining height with ; flex: 1 : auto in the body to make it scrollable when the list doesn't fit. scroll-y Works as expected on iOS: But on Android the last items are being cut off: Why? Some mobile browsers hide the address bar when the user scrolls down. This changes the visible viewport height, but not the meaning of . So actually a bit taller than what is initially visible. 100vh 100vh Your modal has , so you don't need to use units. will fill the available height correctly: position: fixed vh height: 100% Neat! This is already an improvement from the native versions of on mobile. Now you need to implement the filter behavior. <select> You’re pretty sure that your wouldn’t want to go through the trouble of having to touch the filter input every time after opening the modal. So you should the filter input as soon as the modal opens. This way, the keyboard pops up and the user can start typing right away. Guiding Sun Ray focus() Everything looks good on Android: On iOS, the modal header is scrolled out of bounds once you try to scroll the list: What’s going on? When you filter by “Leader”, the list becomes small enough to fit the screen without scrolling, but only if the keyboard isn’t visible. On Android, opening the keyboard shrinks the viewport down to the visible area. But . iOS lets you scroll the page while the keyboard is open, revealing that missing portion of the page. This behavior can break elements like yours. on iOS, the viewport size remains unchanged; it is just being covered by the keyboard position: fixed To make matters worse, there’s no way to know how tall the keyboard will be, or if it is there at all (the user can be using a hardware keyboard). No clever CSS trick can save you this time. So you need to have a scrollable list, where all the items are accessible, without knowing if an arbitrary portion of the lower part of screen is visible or not. This is your workaround: You add a spacer at the bottom of the list (highlighted in green for visibility). The height of this spacer is the height of the list area, minus one element. This way, it’s always possible to scroll all the way to the bottom, bringing the last element to the very top of the list. There are still ways to make the modal scroll outside the viewport, and you need to patch them. One way is by swiping on any non-scrollable elements currently visible. In your case, that’s the modal header. You can’t just disable all pointer events through CSS, since you need the inner elements (filter input and close button) to still be usable. The solution is to disable scrolling on events: touchmove header = .getElementById( )

header.addEventListener( , event => {
  event.preventDefault()
}) const document 'modal-header' 'touchmove' The default reaction to is scrolling, so blocking that with preventDefault() will make it unscrollable. touchmove Now let’s take a small detour. I’ve been writing these examples in HTML + JavaScript to make the article a bit more universal. But I came across this spiral of workarounds while developing in React. This is how I define my event handler in React: {
  event.preventDefault()
} <Element onTouchMove={handleTouchMove} /> ( ) function handleTouchMove event // … The expectation might be that in plain JavaScript, this would translate to something like this: element = .getElementById( )

element.addEventListener( , event => { }) const document 'element' 'touchmove' // call the callback for this element But what happens is closer to this (not real code): .addEventListener( , event => { element = React.getElementFromEvent(event) }) document 'touchmove' const // call the callback for this element React binds the events at the document level, instead of binding them at the level of each individual node. Here is what happens when I try to touch events in React: preventDefault() The browser blocks it. , and those can’t be blocked with at the document level. The solution is to bind the event manually at the node level, instead of doing it through React's event system: This was introduced with a Chrome update that made events be “passive” by default preventDefault ref = React.createRef();

componentDidMount() {
  ref.addEventListener( , handleTouchMove)
} {
  event.preventDefault()
} <Element ref={ref} onTouchMove={handleTouchMove} /> 'touchmove' ( ) function handleTouchMove event // … So yes, particularly in React, this workaround requires a workaround. As I write this, , so the problem may no longer exist by the time you read this article. React’s event system is being rewritten Now back to problem. your There is one more way to scroll your hopes and dreams away. If the user insists on scrolling when there are no more items to show, the viewport can be scrolled up. None of this fazes you anymore, you just jam another workaround in there: modalBody = .getElementById( )

menuScroll = { (modalBody.scrollHeight - modalBody.scrollTop === modalBody.clientHeight) {
    modalBody.scrollTop -= }
}

modalBody.addEventListener( , menuScroll) const document 'modal-body' => () if 1 'scroll' You push the list’s scroll position one pixel away from the edge when the scroll reaches the bottom. This way, the outer scroll is never triggered. The solution is already pretty solid, but there is one more thing you’d like to improve. The modal suddenly covering the screen might be a bit jarring. What if isn’t paying attention and gets spooked? Who will take care of your kids? His Excellency A simple transition animation could make it easier to follow. Perhaps you could slide the modal from the bottom of the screen? Easy to achieve with CSS transitions: { : flex; : ; : top ;
} { : ;
} .modal /* ... */ display top 100vh transition 500ms .modal .show top 0 Now, instead of initializing your modal with and , you start it already with , but pushed outside the viewport with top: . When the modal is set to visible, it will scroll smoothly to the top of the screen. Let's see the result on Android: display: none top: 0 display: flex 100vh Android behaving well again! And now on iOS: iOS blasts the modal to outer space as soon as it is visible. It seems like toggling the keyboard while the modal is being animated isn’t a good idea. You feel pretty confident that showing the keyboard only after the animation is done should fix it: {
  modal.classList.add( ) setTimeout( {
    filterInput.focus()
  }, )
} ( ) function openModal 'show' // new => () 500 Simple enough. You wait for 500ms, the same as the transition duration, and only then you the input to make the keyboard pop up. You tell yourself that you'll clean this up later, maybe using events or some fancy library, instead of relying on the values being consistent between JS and CSS. But you know it won't happen. The result: focus() Now iOS doesn’t seem to be focusing the input at all. Of course, it couldn’t be that easy. , and isn't that. Your workaround is to turn the "Select a title" button into a text input: iOS only allows focus events to happen as a direct result of a user interaction setTimeout < = = = > input onfocus "openModal()" readonly true placeholder "Select a title" The hides the caret and makes sure the user can't type anything into this new input during the transition. This way, iOS will show the keyboard based on the first focus event, allowing you to change the focus to the second input after the transition is done. readonly And it works! You’re finally done. You feel proud of your work, knowing your family will live at least another couple months. Find the full code for the modal here

In North Korea, Front End Devs Face Platform Inconsistencies That You Might Not Know Even Existed

Singularity: Streamlining Game Development with a Universal Backend Framework

এককতা: একটি ইউনিভার্সাল ব্যাকএন্ড ফ্রেমওয়ার্ক সহ গেম ডেভেলপমেন্টকে স্ট্রীমলাইন করা

Singularity: Optimierte Spieleentwicklung mit einem universellen Backend-Framework

Singularidad: agilización del desarrollo de juegos con un marco de backend universal

Singularity : rationaliser le développement de jeux avec un framework backend universel

सिंगलेरिटी: यूनिवर्सल बैकएंड फ्रेमवर्क के साथ गेम डेवलपमेंट को सुव्यवस्थित करना

Singularity: ユニバーサル バックエンド フレームワークによるゲーム開発の効率化

Singularity: 범용 백엔드 프레임워크로 게임 개발 간소화

Singularidade: simplificando o desenvolvimento de jogos com uma estrutura de back-end universal

Singularity: оптимизация разработки игр с помощью универсальной серверной платформы

Tekillik: Evrensel Arka Uç Çerçevesiyle Oyun Geliştirmeyi Kolaylaştırma

Điểm kỳ dị: Hợp lý hóa quá trình phát triển trò chơi với Khung phụ trợ phổ quát

Singularity：使用通用后端框架简化游戏开发

In May 2024, Google rolled out its AI Overview feature to enhance users’ experiences in the search engine. This latest feature was intended to streamline searching by summarizing information from multiple sources. The answers it provides are typically concisely written responses to queries that people enter in the search bar. With this new AI Overview, Google’s intentions were clear — to leverage advanced AI to make search faster and more reliable. However, the reality of the AI Overview’s performance has fallen short of expectations in the months since its release. Almost immediately after its launch, users began encountering some unexpected issues. Social media and community forums buzzed with examples of the AI Overview producing absurd recommendations. Some of its responses even provided dangerous advice to users. Among the most viral incidents was the suggestion to use ⅛ cup of nontoxic glue on pizza to help the cheese stick. People eventually discovered this recommendation was pulled from an old, satirical post on Reddit. Now, they are expressing their opinions and concerns on the internet about how Google was too quick to launch AI Overview. What Users Think of Google’s AI Overview Now, nearly two months after its release, user reactions to Google’s AI Overview still vary. Some people love it, while others express dissatisfaction. A HackerNoon poll found that 29% said they hated the feature and would prefer Google to get rid of it. Meanwhile, another 29% disliked it for now but believe Google could make some improvements. Reddit users have been vocal about AI Overview's shortcomings and poor advice. From eating a rock a day to incorrect cooking temperatures, the errors have led to widespread criticism of Google. A Reddit thread in the r/technology community discussed these issues extensively. Users expressed frustration over the feature, pointing out that it does not know the difference between humor and authentic content. Some people even mentioned that AI Overview was never a good idea in the first place. On the other hand, some people come to Google’s defense by explaining how LLMs work and the reasoning behind some of the inaccurate information they provide. Despite the backlash, some users see potential in the technology. Some believe it is valuable but needs some refinements. Google’s Thoughts on the Matter When people read about how poor some of the responses from the overviews are, they wonder whether Google truly considered how its audience would use its products. After all, 60% of online users consider trustworthiness a top priority when using a brand’s products — meaning providing trustworthy answers should have been the number one priority. However, it seems Google skipped over the testing part and launched its AI Overview without question. Google has admitted to the search feature’s errors. In a blog post, Google’s head of search, Liz Reid, stated that she saw AI Overview feature sarcastic and satirical content. While she finds public forums to be the best source of authentic information, Reid suggested that AI Overview can lead to some unhelpful advice. However, Google also claims some screenshots of AI Overviews with nonsensical responses may be fake. WIRED has even conducted its own testing to determine if this is true. It found that one screenshot with over 5 million views did not align with how AI Overview presents information to users. Still, Google realizes that AI Overviews prevent users from experiencing its full potential. That is why it has made over a dozen improvements, including enhancing the detection of queries that do not call for an AI Overview. Google also intends to keep a close eye on the tool and adjust its features according to user feedback. The Implications of the State of AI AI has proven to be a helpful tool for many, but some of the issues it presents clearly indicate that it still needs to improve. The overall takeaways about the state of AI involve a few things to keep in mind. 1. AI Relies Too Heavily on Biased Datasets AI systems are only as good as the data they are trained on, presenting a large problem for bias. When machine learning engineers feed these datasets to AI systems, they often contain bias from decades of content. As a result, LLMs will replicate these biases and open the possibility of perpetuating existing misinformation. For instance, if an AI system frequently sources data from platforms known for low-quality content, it can propagate false information. Addressing these biases requires a larger effort to curate diverse and high-quality datasets. Additionally, mechanisms should be established to detect and mitigate bias in AI training processes. 2. AI Lacks Contextual Awareness and Advanced Reasoning While AI can process data quickly, it often fails to understand nuances to provide deeper context. A great example is when Google’s AI Overview misinterpreted information from a travel blog post about slot canyons near Las Vegas. It confused them with normal canyons, not even knowing their differences. This mistake can confuse some people, showing AI’s limitations in understanding and reasoning contextually. Such errors diminish user trust and highlight the need for more sophisticated AI systems to accurately grasp and analyze context. 3. AI Acts as a People Pleaser One of the more troubling aspects of AI systems is their propensity to generate a response for every query. Even if they cannot provide a sensible answer, they will still create a response. This eagerness to please often leads to the machine fabricating information or presenting incorrect data confidently. As such, it provides misleading advice that can spread from one person to the next. AI Overview has had several cases where it offered advice based on satirical content or outdated sources simply because it was compelled to provide an answer. With this tendency comes the necessity to recognize AI’s limitations and refrain from asking it further questions when it cannot answer accurately. 4. AI Is Limited on Data Another clear issue is the constraints of the datasets on which they are trained. With a fixed cutoff date, AI can quickly become obsolete and provide responses that are no longer relevant or accurate. This is especially problematic in a rapidly changing world. As technology, medicine and global events evolve, AI’s outdated information can lead to significant errors in its answers. AI would need constant updates to keep information fresh. However, this is a large undertaking because the process must always start from scratch. Yet, AI's reliability diminishes without such updates, making it imperative to address this issue. Dealing With AI Weaknesses The recent launch of Google’s AI Overview provides insightful information on the current state of AI and its limitations. However, as AI evolves, users may begin to see it as a more trustworthy tool. Nonetheless, it is quite clear that these tools need serious updates to end people’s complaints. It may take some time before significant advancements are made, but it will be interesting to see what AI's future has in store. In May 2024, Google rolled out its AI Overview feature to enhance users’ experiences in the search engine. This latest feature was intended to streamline searching by summarizing information from multiple sources. The answers it provides are typically concisely written responses to queries that people enter in the search bar. With this new AI Overview, Google’s intentions were clear — to leverage advanced AI to make search faster and more reliable. However, the reality of the AI Overview’s performance has fallen short of expectations in the months since its release. Almost immediately after its launch, users began encountering some unexpected issues. Social media and community forums buzzed with examples of the AI Overview producing absurd recommendations. Some of its responses even provided dangerous advice to users. Among the most viral incidents was the suggestion to use ⅛ cup of nontoxic glue on pizza to help the cheese stick. People eventually discovered this recommendation was pulled from an old, satirical post on Reddit. Now, they are expressing their opinions and concerns on the internet about how Google was too quick to launch AI Overview. use ⅛ cup of nontoxic glue on pizza What Users Think of Google’s AI Overview Now, nearly two months after its release, user reactions to Google’s AI Overview still vary. Some people love it, while others express dissatisfaction. A HackerNoon poll found that 29% said they hated the feature and would prefer Google to get rid of it. Meanwhile, another 29% disliked it for now but believe Google could make some improvements. 29% said they hated the feature Reddit users have been vocal about AI Overview's shortcomings and poor advice. From eating a rock a day to incorrect cooking temperatures, the errors have led to widespread criticism of Google. Reddit A Reddit thread in the r/technology community discussed these issues extensively. Users expressed frustration over the feature, pointing out that it does not know the difference between humor and authentic content. Some people even mentioned that AI Overview was never a good idea in the first place. thread in the r/technology community On the other hand, some people come to Google’s defense by explaining how LLMs work and the reasoning behind some of the inaccurate information they provide. Despite the backlash, some users see potential in the technology. Some believe it is valuable but needs some refinements. Google’s Thoughts on the Matter When people read about how poor some of the responses from the overviews are, they wonder whether Google truly considered how its audience would use its products. After all, 60% of online users consider trustworthiness a top priority when using a brand’s products — meaning providing trustworthy answers should have been the number one priority. However, it seems Google skipped over the testing part and launched its AI Overview without question. 60% of online users consider trustworthiness Google has admitted to the search feature’s errors. In a blog post, Google’s head of search, Liz Reid, stated that she saw AI Overview feature sarcastic and satirical content. While she finds public forums to be the best source of authentic information, Reid suggested that AI Overview can lead to some unhelpful advice. However, Google also claims some screenshots of AI Overviews with nonsensical responses may be fake. WIRED has even conducted its own testing to determine if this is true. It found that one screenshot with over 5 million views did not align with how AI Overview presents information to users. one screenshot with over 5 million views Still, Google realizes that AI Overviews prevent users from experiencing its full potential. That is why it has made over a dozen improvements, including enhancing the detection of queries that do not call for an AI Overview. Google also intends to keep a close eye on the tool and adjust its features according to user feedback. The Implications of the State of AI AI has proven to be a helpful tool for many, but some of the issues it presents clearly indicate that it still needs to improve. The overall takeaways about the state of AI involve a few things to keep in mind. 1. AI Relies Too Heavily on Biased Datasets AI systems are only as good as the data they are trained on, presenting a large problem for bias. When machine learning engineers feed these datasets to AI systems, they often contain bias from decades of content. As a result, LLMs will replicate these biases and open the possibility of perpetuating existing misinformation. For instance, if an AI system frequently sources data from platforms known for low-quality content, it can propagate false information. Addressing these biases requires a larger effort to curate diverse and high-quality datasets. Additionally, mechanisms should be established to detect and mitigate bias in AI training processes. 2. AI Lacks Contextual Awareness and Advanced Reasoning While AI can process data quickly, it often fails to understand nuances to provide deeper context. A great example is when Google’s AI Overview misinterpreted information from a travel blog post about slot canyons near Las Vegas. It confused them with normal canyons, not even knowing their differences. misinterpreted information from a travel blog post This mistake can confuse some people, showing AI’s limitations in understanding and reasoning contextually. Such errors diminish user trust and highlight the need for more sophisticated AI systems to accurately grasp and analyze context. 3. AI Acts as a People Pleaser One of the more troubling aspects of AI systems is their propensity to generate a response for every query. Even if they cannot provide a sensible answer, they will still create a response. This eagerness to please often leads to the machine fabricating information or presenting incorrect data confidently. As such, it provides misleading advice that can spread from one person to the next. AI Overview has had several cases where it offered advice based on satirical content or outdated sources simply because it was compelled to provide an answer. With this tendency comes the necessity to recognize AI’s limitations and refrain from asking it further questions when it cannot answer accurately. 4. AI Is Limited on Data Another clear issue is the constraints of the datasets on which they are trained. With a fixed cutoff date, AI can quickly become obsolete and provide responses that are no longer relevant or accurate. This is especially problematic in a rapidly changing world. As technology, medicine and global events evolve, AI’s outdated information can lead to significant errors in its answers. AI would need constant updates to keep information fresh. However, this is a large undertaking because the process must always start from scratch. Yet, AI's reliability diminishes without such updates, making it imperative to address this issue. Dealing With AI Weaknesses The recent launch of Google’s AI Overview provides insightful information on the current state of AI and its limitations. However, as AI evolves, users may begin to see it as a more trustworthy tool. Nonetheless, it is quite clear that these tools need serious updates to end people’s complaints. It may take some time before significant advancements are made, but it will be interesting to see what AI's future has in store.

What We Can Learn About the State of AI From Google’s AI Overview Launch

In my previous article, Managing Architectural Tech Debt, I talked about understanding and managing architectural technical debt. Architectural technical debt is the often ignored, but ironically, one of the most damaging, categories of technical debt. In this article, I want to dive deeper into one way to manage architectural technical debt (and technical debt as a whole)—architectural observability (AO). AO is a new category of observability that I believe is just as important, if not more so, as application performance management (APM). I believe we need to shift left observability—to the architectural stage—where we can not just see symptoms, but fix core problems. Let’s take a look. APM Is (Half) the Answer You already know that APM is important. Gartner defines it as “software that enables the observation and analysis of application health, performance and user experience.” And IDC reports that companies using APM solutions see a 2.5x improvement in mean time to resolution (MTTR) and a 50% reduction in the number of incidents. APM and observability: Helps to ensure better user experiences by monitoring, in real-time, performance and responsiveness.
Can help identify defects.
Can provide data to teams, such as usage patterns, bottlenecks, and overall health to keep systems healthy. Overall, APM has become a necessary tool for troubleshooting and fixing issues in enterprise environments. APM has become table stakes. And APM works! In my current role, we use APM to observe the usage of our APIs to understand the breakdown of URI (uniform resource identifier) requests across all of our consumers. When our APIs are not functioning as expected, we lean to APM in order to gain visibility into performance bottlenecks. In cases where an alert is triggered, the same interface can be utilized for initial troubleshooting efforts in order to help pin down the root cause. But even though APM works, there’s a problem. APM identifies the symptoms of the defects, but not the actual defects themselves. It’s up to the team to track down why the problems are occurring. And with the pressure we often feel in prod to “just fix the problem as fast as you can,” I often see that while symptoms may be addressed, teams don’t have the time (or organizational support) to find and fix the actual core problems. Imagine taking aspirin because you get a headache every night, but never taking the time to figure out why you keep having headaches. To find—and address—the why of our defects, we need architectural observability. Architectural Observability: Getting to the Real Answers We need to shift our processes left, stop focusing on symptoms, and instead focus on the root cause of these problems and actually reduce the number of incidents caught with APM. That’s where architectural observability comes in. Architectural observability is the ability to analyze an application’s architecture (both statically and dynamically), understand how it works, observe changes, and identify and fix architectural technical debt. Architectural observability is the next step in observability tools. Architectural observability gives you visibility into your application architecture, helping you solve problems (not just identify symptoms) earlier in the SDLC by identifying architectural issues. You probably already have the data you need to implement AO—it uses the same data sources as APM (for example, OpenTelemetry (OTel). But AO takes that data and applies a layer of intelligence that focuses on analyzing the architecture and the sources of architectural technical debt. For example, an AO tool might analyze: Architectural complexity - The interdependence and relationships of services within the architecture, the number of flows in a service, identifying multi-hop flows and circular flows. Dependency mappings - Relationships among services including circular dependencies. Architectural drift - What has changed since your last release, what new domains/services were added, what new dependencies and flows were introduced. Technical debt - Such as resource exclusivity, service dependencies, duplicate services that should be merged, and complexity. Technical debt is a huge problem in the industry. 70% of organizations say that technical debt is a major obstacle to innovation. Database-related issues - Examine if multiple services are accessing tables. Architectural observability is proactive and strategic. Where APM tools alert on the leaks in the roof when it is already raining, AO identifies architectural issues that can lead to those leaks, way before they actually occur. Using Tools to Gain Architectural Observability Used well, AO doesn’t just help you find issues earlier, but helps you: Truly discover and understand your architecture and its relationships and dependencies.
Prevent issues caused by architectural changes.
Make systems more resilient and scalable by continually monitoring, modernizing, and strengthening your architecture.
Minimize technical debt. I love that last one. As I pointed out in my last article, architectural debt is a foe of mine that I have been battling for over a decade. Architectural observability is a new field and is starting to gain traction as something teams must have. There aren’t many tools yet built around the concept, but let’s look at how your team might use one of the first AO tools—vFunction—to gain AO. Once you’ve connected to your applications (through the OTel connector or similar), the tool analyzes your system (in this case with vFunction, it’s using AI to understand and analyze your architecture). Then you get a report on the current state of your architecture. You’ll see details such as: A visualization of the architecture across your entire app portfolio
A map of services and entry points, cross services APIs, and external APIs
Exclusivity of database tables (Kafka, Redis, MongoDB) and other resources
Complexity scores
And more… And you can use architectural observability to monitor your architecture not just in the present state, but dynamically as it changes. Changes to your architecture (a.k.a., architectural drift)? You’ll know right away.
Add a dependency impacting resiliency? You’ll catch it before migrating.
Did you create a circular flow? Did you significantly increase the complexity of your system? Find out early. Incurring even more technical debt? You can’t hide from it now. With architectural observability, you now have hard proof of how architectural debt is affecting your systems and how, by using AO, you can identify and prioritize the actual problems in your systems early and often, rather than only addressing the symptoms in production. AO makes applications more resilient, more scalable, and helps your team move faster. And AO can help proactively. Is your team moving from a monolith to a microservice? AO can give you a plan to move your architecture forward. With AO, you could analyze your monolith, understand how its domains and functionality are structured and connected, and then get actionable steps on how to modularize and move the functionality to microservices. And once you have a distributed architecture (microservices or distributed monoliths), you’ll want to make sure your architecture doesn’t drift or get more complex to the point that things start to break, you lose control, and you have to slow down your engineering velocity. AO keeps your applications in check whether monolith or microservices. Architectural Observability Gives You Better Systems My readers may recall that I have been focused on the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester Architectural observability adheres to my mission statement perfectly. By moving from plain vanilla observability to architectural observability, we can shift left for more reliable, more resilient, and better-performing systems. This shift affords us more time to spend on the business problems that our teams understand best. As John F. Kennedy once said: “The best time to repair the roof is when the sun is shining.” Architectural observability should be placed on the same level (or higher) as APM. With AO, teams can truly understand their architecture, have a broader and more insightful view of their applications than with APM alone, and fix problems earlier. Have a really great day! In my previous article, Managing Architectural Tech Debt , I talked about understanding and managing architectural technical debt. Architectural technical debt is the often ignored, but ironically, one of the most damaging , categories of technical debt. Managing Architectural Tech Debt architectural the most damaging In this article, I want to dive deeper into one way to manage architectural technical debt (and technical debt as a whole)— architectural observability (AO) . AO is a new category of observability that I believe is just as important, if not more so, as application performance management (APM). I believe we need to shift left observability—to the architectural stage—where we can not just see symptoms, but fix core problems. architectural observability (AO) Let’s take a look. APM Is (Half) the Answer You already know that APM is important. Gartner defines it as “software that enables the observation and analysis of application health, performance and user experience.” And IDC reports that companies using APM solutions see a 2.5x improvement in mean time to resolution (MTTR) and a 50% reduction in the number of incidents. IDC reports APM and observability: Helps to ensure better user experiences by monitoring, in real-time, performance and responsiveness. Can help identify defects. Can provide data to teams, such as usage patterns, bottlenecks, and overall health to keep systems healthy. Helps to ensure better user experiences by monitoring, in real-time, performance and responsiveness. Can help identify defects. Can provide data to teams, such as usage patterns, bottlenecks, and overall health to keep systems healthy. Overall, APM has become a necessary tool for troubleshooting and fixing issues in enterprise environments. APM has become table stakes. And APM works! In my current role, we use APM to observe the usage of our APIs to understand the breakdown of URI (uniform resource identifier) requests across all of our consumers. When our APIs are not functioning as expected, we lean to APM in order to gain visibility into performance bottlenecks. In cases where an alert is triggered, the same interface can be utilized for initial troubleshooting efforts in order to help pin down the root cause. But even though APM works, there’s a problem. APM identifies the symptoms of the defects, but not the actual defects themselves . It’s up to the team to track down why the problems are occurring. And with the pressure we often feel in prod to “just fix the problem as fast as you can,” I often see that while symptoms may be addressed, teams don’t have the time (or organizational support) to find and fix the actual core problems. but not the actual defects themselves why Imagine taking aspirin because you get a headache every night, but never taking the time to figure out why you keep having headaches. To find—and address—the why of our defects, we need architectural observability . why architectural observability Architectural Observability: Getting to the Real Answers We need to shift our processes left, stop focusing on symptoms, and instead focus on the root cause of these problems and actually reduce the number of incidents caught with APM. root cause of these problems That’s where architectural observability comes in. Architectural observability is the ability to analyze an application’s architecture (both statically and dynamically), understand how it works, observe changes, and identify and fix architectural technical debt. Architectural observability Architectural observability is the next step in observability tools. Architectural observability gives you visibility into your application architecture, helping you solve problems (not just identify symptoms) earlier in the SDLC by identifying architectural issues. You probably already have the data you need to implement AO—it uses the same data sources as APM (for example, OpenTelemetry (OTel). But AO takes that data and applies a layer of intelligence that focuses on analyzing the architecture and the sources of architectural technical debt. For example, an AO tool might analyze: Architectural complexity - The interdependence and relationships of services within the architecture, the number of flows in a service, identifying multi-hop flows and circular flows. Architectural complexity - The interdependence and relationships of services within the architecture, the number of flows in a service, identifying multi-hop flows and circular flows. Architectural complexity Dependency mappings - Relationships among services including circular dependencies. Dependency mappings - Relationships among services including circular dependencies. Dependency mappings Architectural drift - What has changed since your last release, what new domains/services were added, what new dependencies and flows were introduced. Architectural drift - What has changed since your last release, what new domains/services were added, what new dependencies and flows were introduced. Architectural drift Technical debt - Such as resource exclusivity, service dependencies, duplicate services that should be merged, and complexity. Technical debt is a huge problem in the industry. 70% of organizations say that technical debt is a major obstacle to innovation. Technical debt - Such as resource exclusivity, service dependencies, duplicate services that should be merged, and complexity. Technical debt is a huge problem in the industry. 70% of organizations say that technical debt is a major obstacle to innovation. Technical debt major obstacle to innovation. Database-related issues - Examine if multiple services are accessing tables. Database-related issues - Examine if multiple services are accessing tables. Database-related issues Architectural observability is proactive and strategic. Where APM tools alert on the leaks in the roof when it is already raining, AO identifies architectural issues that can lead to those leaks, way before they actually occur. Using Tools to Gain Architectural Observability Used well, AO doesn’t just help you find issues earlier, but helps you: Truly discover and understand your architecture and its relationships and dependencies. Prevent issues caused by architectural changes. Make systems more resilient and scalable by continually monitoring, modernizing, and strengthening your architecture. Minimize technical debt. Truly discover and understand your architecture and its relationships and dependencies. Prevent issues caused by architectural changes. Prevent Make systems more resilient and scalable by continually monitoring, modernizing, and strengthening your architecture. Minimize technical debt. I love that last one. As I pointed out in my last article , architectural debt is a foe of mine that I have been battling for over a decade. my last article Architectural observability is a new field and is starting to gain traction as something teams must have. There aren’t many tools yet built around the concept, but let’s look at how your team might use one of the first AO tools—vFunction—to gain AO. Once you’ve connected to your applications (through the OTel connector or similar), the tool analyzes your system (in this case with vFunction, it’s using AI to understand and analyze your architecture). Then you get a report on the current state of your architecture. You’ll see details such as: A visualization of the architecture across your entire app portfolio A map of services and entry points, cross services APIs, and external APIs Exclusivity of database tables (Kafka, Redis, MongoDB) and other resources Complexity scores And more… A visualization of the architecture across your entire app portfolio A map of services and entry points, cross services APIs, and external APIs Exclusivity of database tables (Kafka, Redis, MongoDB) and other resources Complexity scores And more… And you can use architectural observability to monitor your architecture not just in the present state, but dynamically as it changes. Changes to your architecture (a.k.a., architectural drift)? You’ll know right away. Add a dependency impacting resiliency? You’ll catch it before migrating. Did you create a circular flow? Did you significantly increase the complexity of your system? Find out early. Changes to your architecture (a.k.a., architectural drift)? You’ll know right away. Add a dependency impacting resiliency? You’ll catch it before migrating. Did you create a circular flow? Did you significantly increase the complexity of your system? Find out early. Incurring even more technical debt? You can’t hide from it now. more With architectural observability, you now have hard proof of how architectural debt is affecting your systems and how, by using AO, you can identify and prioritize the actual problems in your systems early and often, rather than only addressing the symptoms in production. AO makes applications more resilient, more scalable, and helps your team move faster. And AO can help proactively. Is your team moving from a monolith to a microservice? AO can give you a plan to move your architecture forward. With AO, you could analyze your monolith, understand how its domains and functionality are structured and connected, and then get actionable steps on how to modularize and move the functionality to microservices. And once you have a distributed architecture (microservices or distributed monoliths), you’ll want to make sure your architecture doesn’t drift or get more complex to the point that things start to break, you lose control, and you have to slow down your engineering velocity. AO keeps your applications in check whether monolith or microservices. Architectural Observability Gives You Better Systems My readers may recall that I have been focused on the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester Architectural observability adheres to my mission statement perfectly. By moving from plain vanilla observability to architectural observability , we can shift left for more reliable, more resilient, and better-performing systems. This shift affords us more time to spend on the business problems that our teams understand best. architectural observability As John F. Kennedy once said: “The best time to repair the roof is when the sun is shining.” Architectural observability should be placed on the same level (or higher) as APM. With AO, teams can truly understand their architecture, have a broader and more insightful view of their applications than with APM alone, and fix problems earlier. Have a really great day!

From Observability to Architectural Observability—Shifting Left for Resiliency

Empowerment is widely endorsed. There is consensus that top management should trust teams to solve problems and provide them with the autonomy to achieve goals and milestones. This trust is not just a formality but a recognition of the value and expertise that teams bring to the table. However, the challenge lies in transitioning teams from a feature-factory mentality to a value-driven approach. Development teams often need to prepare for such a shift to gain experience in taking on this level of responsibility. Let's face it: being accountable for outcomes is much more complex than simply delivering fixed tasks with specific features. Despite the increased risk associated with focusing on outcomes, it is far more interesting and exciting for everyone involved. Remember when time used to go much slower when we were kids? Scientists say that is because we explore the world and learn something new daily. Here are some strategies to effectively transition from focusing solely on output to achieving meaningful outcomes. Overcome the feature-centric mindset once and for all. Mindset Difference. For a long time, success was delivering features within deadlines and scope. I excelled at meeting stakeholders’ wants. They were happy with the results, and we were comfortable with how we worked. There was no room for confusion. Everyone understood their tasks and deadlines without problem. Every Sprint followed a similar pattern: features, features, features, a bug fix here and a refactor there, but nothing more. Our primary responsibility was to deliver outputs on time, a task we were adept at fulfilling. However, with the restructuring of the leadership team, expectations shifted. They emphasised achieving goals rather than dictating specific tasks. When they stopped telling us what to do, we panicked. We needed guidance as to where even to start. The questions running through our minds were: Where should we start?
What if we make a wrong decision? Will we be held accountable?
How do we define success now? It was embarrassing. We wanted responsibility and autonomy, and that’s exactly what we got. The real challenge, however, lay in figuring out how to deal with it. We were empowered to achieve goals but needed to prepare for the task. Output vs Outcome. Until then, we had solely concentrated on outputs, completely unaware of the true essence of outcomes. Let’s try to summarise the difference. An output is created for customers to use, such as product recommendations in the e-commerce industry. These recommendations are designed to deliver value. Their outcomes assess the effectiveness of outputs. For instance, when customers add recommended products to their carts, increasing sales represents an outcome. Now, here's the exciting part: Various outputs can achieve outcomes. It's like solving a problem where multiple alternatives exist. When you begin with the outcome in mind, you unlock diverse possibilities and increase your chances of creating significant value. Start small. Getting someone who is already an expert on the topic will make your life much easier. To get where you’ve never been, seek guidance from someone already there! I froze when I first faced true empowerment, and so did everyone else. Despite our attempts to shift focus towards outcomes, our lack of experience inevitably led to failure, as anticipated. We struggled with conducting discovery experiments;
Developers expected precise requirements from me as usual, and;
Stakeholders prioritised feature predictability; The dynamics began to shift when an experienced person joined our team. Instead of overhauling everything at once, we transitioned gradually from focusing on outputs to emphasising outcomes. Our Sprints primarily focused on delivering outputs, with some items oriented towards achieving outcomes. This mixed approach allowed us to change to a new working method gradually. For instance, in one Sprint, we allocated approximately 70% of our capacity to completing a pre-defined integration with partners and 20% to exploring methods to reduce our churn rate. Through this process, we discovered the barriers preventing us from fully embracing the unknown: We hesitated to provide estimates for ambiguous requirements due to past blame for unmet deadlines;
We avoided exploring alternative solutions, fearing the prospect of failure and criticism;
The uncertainty of the unknown made us uneasy as it challenged our accustomed security; Gradually, however, clarity emerged, and we began transforming our work approach. Mindset transformation is required. Transitioning from focusing on output to prioritising outcome is challenging and demanding, as it upends everything you thought you knew about your work methods. With an output mindset, decisions typically revolve around how to deliver predefined features. When a value-driven mindset with a focus on outcomes is an adapter, you need to make decisions frequently—some say even 10 times as many. You must choose problems to solve, find solutions, test them, inspect them, and adapt. It’s more demanding, without a doubt. It also means that you are still working when customers receive the functionality. It is crucial to understand how it works, what they like, how to improve, and how to measure the outcome. So what can help: Coaching: Ask your team questions; do not provide answers. The brains of an entire team have much more computing power than those of a Product Owner or manager;
Problems over solutions: Focus on understanding the problem's context, relevance, and impact before discussing solutions;
Learning over predictability: Prioritizing learning over predictability involves embracing the unknown through frequent small experiments and rapid end-user learning. Understanding what not to build is as crucial as identifying what to make, aiming to create value while minimising waste;
Evidence over opinions: Moreover, decisions should be guided by objective evidence from experiments rather than opinions. This is about having a data-driven mindset; Once you've shifted your mindset to focus on outcomes, the orientation towards achieving meaningful results becomes motivating and inspiring. Every Sprint becomes a different story. So What? Moving from output to outcome is stressful. The burden on your shoulders will be heavy, but you’ll never learn so many new things. Scrum teams yearn for empowerment but can feel overwhelmed when it arrives. Navigate this shift with guidance from experienced mentors and embrace gradual progress. Remember, it's a marathon, not a sprint. Prioritise moving in the right direction over rushing against time. Empowerment is widely endorsed. There is consensus that top management should trust teams to solve problems and provide them with the autonomy to achieve goals and milestones. This trust is not just a formality but a recognition of the value and expertise that teams bring to the table. However, the challenge lies in transitioning teams from a feature-factory mentality to a value-driven approach. Development teams often need to prepare for such a shift to gain experience in taking on this level of responsibility. Let's face it: being accountable for outcomes is much more complex than simply delivering fixed tasks with specific features. Despite the increased risk associated with focusing on outcomes, it is far more interesting and exciting for everyone involved. Remember when time used to go much slower when we were kids? Scientists say that is because we explore the world and learn something new daily. Here are some strategies to effectively transition from focusing solely on output to achieving meaningful outcomes. Overcome the feature-centric mindset once and for all. Mindset Difference. For a long time, success was delivering features within deadlines and scope. I excelled at meeting stakeholders’ wants. They were happy with the results, and we were comfortable with how we worked. There was no room for confusion. Everyone understood their tasks and deadlines without problem. Every Sprint followed a similar pattern: features, features, features, a bug fix here and a refactor there, but nothing more. Our primary responsibility was to deliver outputs on time, a task we were adept at fulfilling. However, with the restructuring of the leadership team, expectations shifted. They emphasised achieving goals rather than dictating specific tasks. When they stopped telling us what to do, we panicked. We needed guidance as to where even to start. The questions running through our minds were: Where should we start? What if we make a wrong decision? Will we be held accountable? How do we define success now? Where should we start? What if we make a wrong decision? Will we be held accountable? How do we define success now? It was embarrassing. We wanted responsibility and autonomy, and that’s exactly what we got. The real challenge, however, lay in figuring out how to deal with it. We were empowered to achieve goals but needed to prepare for the task. Output vs Outcome. Until then, we had solely concentrated on outputs, completely unaware of the true essence of outcomes. Let’s try to summarise the difference. An output is created for customers to use, such as product recommendations in the e-commerce industry. These recommendations are designed to deliver value. Their outcomes assess the effectiveness of outputs. For instance, when customers add recommended products to their carts, increasing sales represents an outcome. Now, here's the exciting part: Various outputs can achieve outcomes. It's like solving a problem where multiple alternatives exist. When you begin with the outcome in mind, you unlock diverse possibilities and increase your chances of creating significant value. Start small. Getting someone who is already an expert on the topic will make your life much easier. To get where you’ve never been, seek guidance from someone already there! I froze when I first faced true empowerment, and so did everyone else. Despite our attempts to shift focus towards outcomes, our lack of experience inevitably led to failure, as anticipated. We struggled with conducting discovery experiments; Developers expected precise requirements from me as usual, and; Stakeholders prioritised feature predictability; We struggled with conducting discovery experiments; Developers expected precise requirements from me as usual, and; Stakeholders prioritised feature predictability; The dynamics began to shift when an experienced person joined our team. Instead of overhauling everything at once, we transitioned gradually from focusing on outputs to emphasising outcomes. Our Sprints primarily focused on delivering outputs, with some items oriented towards achieving outcomes. This mixed approach allowed us to change to a new working method gradually. For instance, in one Sprint, we allocated approximately 70% of our capacity to completing a pre-defined integration with partners and 20% to exploring methods to reduce our churn rate. Through this process, we discovered the barriers preventing us from fully embracing the unknown: We hesitated to provide estimates for ambiguous requirements due to past blame for unmet deadlines; We avoided exploring alternative solutions, fearing the prospect of failure and criticism; The uncertainty of the unknown made us uneasy as it challenged our accustomed security; We hesitated to provide estimates for ambiguous requirements due to past blame for unmet deadlines; We avoided exploring alternative solutions, fearing the prospect of failure and criticism; The uncertainty of the unknown made us uneasy as it challenged our accustomed security; Gradually, however, clarity emerged, and we began transforming our work approach. Mindset transformation is required. Transitioning from focusing on output to prioritising outcome is challenging and demanding, as it upends everything you thought you knew about your work methods. With an output mindset, decisions typically revolve around how to deliver predefined features. When a value-driven mindset with a focus on outcomes is an adapter, you need to make decisions frequently—some say even 10 times as many. You must choose problems to solve, find solutions, test them, inspect them, and adapt. It’s more demanding, without a doubt. It also means that you are still working when customers receive the functionality. It is crucial to understand how it works, what they like, how to improve, and how to measure the outcome. So what can help: Coaching: Ask your team questions; do not provide answers. The brains of an entire team have much more computing power than those of a Product Owner or manager; Problems over solutions: Focus on understanding the problem's context, relevance, and impact before discussing solutions; Learning over predictability: Prioritizing learning over predictability involves embracing the unknown through frequent small experiments and rapid end-user learning. Understanding what not to build is as crucial as identifying what to make, aiming to create value while minimising waste; Evidence over opinions: Moreover, decisions should be guided by objective evidence from experiments rather than opinions. This is about having a data-driven mindset; Coaching: Ask your team questions; do not provide answers. The brains of an entire team have much more computing power than those of a Product Owner or manager; Coaching: Problems over solutions: Focus on understanding the problem's context, relevance, and impact before discussing solutions; Problems over solutions: Learning over predictability: Prioritizing learning over predictability involves embracing the unknown through frequent small experiments and rapid end-user learning. Understanding what not to build is as crucial as identifying what to make, aiming to create value while minimising waste; Learning over predictability: Evidence over opinions: Moreover, decisions should be guided by objective evidence from experiments rather than opinions. This is about having a data-driven mindset; Evidence over opinions: Once you've shifted your mindset to focus on outcomes, the orientation towards achieving meaningful results becomes motivating and inspiring. Every Sprint becomes a different story. So What? Moving from output to outcome is stressful. The burden on your shoulders will be heavy, but you’ll never learn so many new things. Scrum teams yearn for empowerment but can feel overwhelmed when it arrives. Navigate this shift with guidance from experienced mentors and embrace gradual progress. Remember, it's a marathon, not a sprint. Prioritise moving in the right direction over rushing against time.

From Outputs to Outcomes

COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 20 of 42. 18. “ESDT.tex” {ID_004736} {PTR-F/93/1} 340. The document is a LaTeX source presented as if it was precursor work to the Bitcoin White Paper created during Dr Wright’s employment at BDO. Dr Wright relies upon it as a draft addressing technical concepts which influenced his development of Bitcoin. By its presence in BDOPC.raw, the document purports to pre-date 31 October 2007. (a) COPA’s Reasons for Alleging Forgery 341. This document is among the 71 New Reliance Documents that were inserted into the BDO Drive by the editing process and which the parties’ experts agree were manipulated [Madden / Lynch1 [12] Q/6/5]. 342. Copies of the document are also located on the Samsung Drive. These copies display signs of metadata editing and clock manipulation. [PM46 [74-79] H/278/17] 343. A related LaTeX file has been recovered which encodes the same textual content in a different way. That document had been deleted but was recoverable from within the Samsung Drive. The structure of that file is consistent with the file being generated automatically by software conversion tools (rather than being authored by hand). [Madden4 [67-70] H/278/16]. 344. There is a related file {ID_004735} which appears intended to create an image for the paper. The code in that file is consistent with having been generated by conversion tools such as Aspose. [Madden3 [75] G/5/31] 345. A related document, ESDT.pdf, was recovered from the Samsung Drive. ESDT.pdf was a compiled form of {ID_004736} but was deleted and emptied from the Recycle Bin in September 2023 [PM46 [41-52] H/278/10]. The metadata associated with the deleted file indicates that it was modified on 16 September 2023, but the other timestamps have been backdated to 31 October 2007. 346. The metadata of this document (when compared with metadata of other documents related to it) displays signs of metadata editing directly using specialised metadata editing tools. [Madden3 [52-63] G/5/23] 347. The document was sourced from BDOPC.raw. The section “BDOPC.raw” above is repeated. This document was added to BDOPC.raw by the Manipulation User. (b) COPA’s Reasons for Inferring Dr Wright’s Knowledge / Responsibility 348. The effect of the tampering is to make the document appear to be supportive of Dr Wright’s claim to be Satoshi Nakamoto, contrary to fact. 349. The further effect of tampering is to lend support to Dr Wright’s new position that the Bitcoin White Paper was created in LaTeX. That story is a recent product of Dr Wright’s change in his account. 350. This document was added to BDOPC.raw by the Manipulation User. The Manipulation User is Dr Wright. Paragraph 45 of the section “BDOPC.raw” above is repeated. 351. Dr Wright has attached particular importance to this document: 351.1. It is said to be among Dr Wright’s “Notes, drafts and articles addressing technical concepts that underpin the concepts developed in the Bitcoin White Paper" [Wright6 E/21/3; Schedule 1 to Field1, L20/223/4] 351.2. It is said to be important to Dr Wright’s case because it is a version of “a paper prepared for a 360º Security Summit on 15 June 2006 concerned with “Implementing Effective Risk-Based Controls”, which Dr Wright prepared in his role at BDO. The hash chain technology discussed in the paper is analogous to the blockchain technology used in Bitcoin." [Wright6 E/21/3; Schedule 1 to Field1, L20/223/5] 352. The document was not disclosed at the proper time. It was disclosed instead from the BDOPC.raw image. BDOPC.raw is not a reliable source because it has been manipulated by Dr Wright. The section “BDOPC.raw” above is repeated. (c) Dr Wright’s Explanations and COPA’s Rebuttal 353. Dr Wright claimed that his use of Xcopy had caused the load file metadata for this and two related documents to all have creation times at precisely the same time on 19 September 2017, with August 2008 accessed and modified times for this document and one other related one. He also claimed that he was still accessing files at BDO in 2008 and so that these may have been copied from a different drive: {Day5/102:21} and following. See Wright11 {CSW/2/43} for an example of him claiming how Xcopy works. 354. COPA submitted that this explanation should be rejected as dishonest for the following reasons: 354.1. If the BDOPC.raw is accepted as being forged, it follows that documents on it should be treated as being forged unless they are documents which Mr Madden says are original to the image that was taken in October 2007. 354.2. Mr Madden states that Xcopy simply does not have the effect that Dr Wright claims. This was also the view of Mr Lynch, as recorded in their Joint Report: {Q/6/4}. 354.3. Dr Wright’s excuse about accessing files at BDO in 2008 is inconsistent with his claim that the files on the BDO Drive are a time capsule and taken from a capture of the BDO files he had in 2007. 354.4. Mr Lynch agreed with Mr Madden that ID_0004736 was manipulated: {Q/6/5}. Continue Reading Here. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.

This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series. You can jump to any part of this filing here. This part is 20 of 42. COPA v. Wright, Court Filing, retrieved on January 29, 2024, is part of HackerNoon’s Legal PDF Series . You can jump to any part of this filing here . This part is 20 of 42. HackerNoon’s Legal PDF Series HackerNoon’s Legal PDF Series here here 18. “ESDT.tex” {ID_004736} {PTR-F/93/1} 340. The document is a LaTeX source presented as if it was precursor work to the Bitcoin White Paper created during Dr Wright’s employment at BDO. Dr Wright relies upon it as a draft addressing technical concepts which influenced his development of Bitcoin. By its presence in BDOPC.raw, the document purports to pre-date 31 October 2007. (a) COPA’s Reasons for Alleging Forgery (a) COPA’s Reasons for Alleging Forgery 341. This document is among the 71 New Reliance Documents that were inserted into the BDO Drive by the editing process and which the parties’ experts agree were manipulated [Madden / Lynch1 [12] Q/6/5]. 342. Copies of the document are also located on the Samsung Drive. These copies display signs of metadata editing and clock manipulation. [PM46 [74-79] H/278/17] 343. A related LaTeX file has been recovered which encodes the same textual content in a different way. That document had been deleted but was recoverable from within the Samsung Drive. The structure of that file is consistent with the file being generated automatically by software conversion tools (rather than being authored by hand). [Madden4 [67-70] H/278/16]. 344. There is a related file {ID_004735} which appears intended to create an image for the paper. The code in that file is consistent with having been generated by conversion tools such as Aspose. [Madden3 [75] G/5/31] 345. A related document, ESDT.pdf, was recovered from the Samsung Drive. ESDT.pdf was a compiled form of {ID_004736} but was deleted and emptied from the Recycle Bin in September 2023 [PM46 [41-52] H/278/10]. The metadata associated with the deleted file indicates that it was modified on 16 September 2023, but the other timestamps have been backdated to 31 October 2007. 346. The metadata of this document (when compared with metadata of other documents related to it) displays signs of metadata editing directly using specialised metadata editing tools. [Madden3 [52-63] G/5/23] 347. The document was sourced from BDOPC.raw. The section “BDOPC.raw” above is repeated. This document was added to BDOPC.raw by the Manipulation User. (b) COPA’s Reasons for Inferring Dr Wright’s Knowledge / Responsibility (b) COPA’s Reasons for Inferring Dr Wright’s Knowledge / Responsibility 348. The effect of the tampering is to make the document appear to be supportive of Dr Wright’s claim to be Satoshi Nakamoto, contrary to fact. 349. The further effect of tampering is to lend support to Dr Wright’s new position that the Bitcoin White Paper was created in LaTeX. That story is a recent product of Dr Wright’s change in his account. 350. This document was added to BDOPC.raw by the Manipulation User. The Manipulation User is Dr Wright. Paragraph 45 of the section “BDOPC.raw” above is repeated. 351. Dr Wright has attached particular importance to this document: 351.1. It is said to be among Dr Wright’s “Notes, drafts and articles addressing technical concepts that underpin the concepts developed in the Bitcoin White Paper" [Wright6 E/21/3; Schedule 1 to Field1, L20/223/4] “Notes, drafts and articles addressing technical concepts that underpin the concepts developed in the Bitcoin White Paper" 351.2. It is said to be important to Dr Wright’s case because it is a version of “a paper prepared for a 360º Security Summit on 15 June 2006 concerned with “Implementing Effective Risk-Based Controls”, which Dr Wright prepared in his role at BDO. The hash chain technology discussed in the paper is analogous to the blockchain technology used in Bitcoin." [Wright6 E/21/3; Schedule 1 to Field1, L20/223/5] “a paper prepared for a 360º Security Summit on 15 June 2006 concerned with “Implementing Effective Risk-Based Controls”, which Dr Wright prepared in his role at BDO. The hash chain technology discussed in the paper is analogous to the blockchain technology used in Bitcoin." 352. The document was not disclosed at the proper time. It was disclosed instead from the BDOPC.raw image. BDOPC.raw is not a reliable source because it has been manipulated by Dr Wright. The section “BDOPC.raw” above is repeated. (c) Dr Wright’s Explanations and COPA’s Rebuttal (c) Dr Wright’s Explanations and COPA’s Rebuttal 353. Dr Wright claimed that his use of Xcopy had caused the load file metadata for this and two related documents to all have creation times at precisely the same time on 19 September 2017, with August 2008 accessed and modified times for this document and one other related one. He also claimed that he was still accessing files at BDO in 2008 and so that these may have been copied from a different drive: {Day5/102:21} and following. See Wright11 {CSW/2/43} for an example of him claiming how Xcopy works. 354. COPA submitted that this explanation should be rejected as dishonest for the following reasons: 354.1. If the BDOPC.raw is accepted as being forged, it follows that documents on it should be treated as being forged unless they are documents which Mr Madden says are original to the image that was taken in October 2007. 354.2. Mr Madden states that Xcopy simply does not have the effect that Dr Wright claims. This was also the view of Mr Lynch, as recorded in their Joint Report: {Q/6/4}. 354.3. Dr Wright’s excuse about accessing files at BDO in 2008 is inconsistent with his claim that the files on the BDO Drive are a time capsule and taken from a capture of the BDO files he had in 2007. 354.4. Mr Lynch agreed with Mr Madden that ID_0004736 was manipulated: {Q/6/5}. Continue Reading Here. Continue Reading Here . Here About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings. This court case retrieved on January 29, 2024, judiciary.uk is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction. judiciary.uk judiciary.uk

FRDM

frdm.co

-- employees

Since n.d.

COMPANY RANKING

FRDM

EVERGREEN INDEX #5054

Representing this company? Click here to claim and customize this page!

FRDM WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

FRDM

frdm.co

-- employees

Since n.d.

COMPANY RANKING

FRDM

EVERGREEN INDEX #5054

RELATED COMPANIESRANK

STORIES ABOUT FRDM

Representing this company? Click here to claim and customize this page!

FRDM WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!