Month: March 2025

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB – Get Free Report)’s share price hit a new 52-week low during trading on Thursday following a weaker than expected earnings announcement. The stock traded as low as $200.19 and last traded at $205.36, with a volume of 2933806 shares traded. The stock had previously closed at $264.13.

The company reported $0.19 EPS for the quarter, missing analysts’ consensus estimates of $0.64 by ($0.45). The firm had revenue of $548.40 million for the quarter, compared to analysts’ expectations of $519.65 million. MongoDB had a negative return on equity of 12.22% and a negative net margin of 10.46%. During the same quarter in the previous year, the company posted $0.86 EPS.

Analysts Set New Price Targets

Several equities research analysts have commented on the stock. Piper Sandler decreased their target price on shares of MongoDB from $425.00 to $280.00 and set an “overweight” rating on the stock in a research report on Thursday. The Goldman Sachs Group dropped their target price on shares of MongoDB from $390.00 to $335.00 and set a “buy” rating for the company in a report on Thursday. Mizuho upped their price target on MongoDB from $275.00 to $320.00 and gave the stock a “neutral” rating in a report on Tuesday, December 10th. China Renaissance assumed coverage on MongoDB in a report on Tuesday, January 21st. They set a “buy” rating and a $351.00 price objective for the company. Finally, Bank of America lowered their target price on MongoDB from $420.00 to $286.00 and set a “buy” rating on the stock in a report on Thursday. One analyst has rated the stock with a sell rating, six have assigned a hold rating and twenty-four have assigned a buy rating to the company’s stock. According to data from MarketBeat.com, MongoDB presently has an average rating of “Moderate Buy” and an average price target of $322.61.

View Our Latest Stock Report on MDB

Insider Activity

In other MongoDB news, CFO Michael Lawrence Gordon sold 5,000 shares of the firm’s stock in a transaction dated Monday, December 16th. The shares were sold at an average price of $267.85, for a total value of $1,339,250.00. Following the transaction, the chief financial officer now owns 80,307 shares of the company’s stock, valued at $21,510,229.95. This trade represents a 5.86 % decrease in their ownership of the stock. The sale was disclosed in a legal filing with the SEC, which is available at this link. Also, CAO Thomas Bull sold 1,000 shares of MongoDB stock in a transaction that occurred on Monday, December 9th. The shares were sold at an average price of $355.92, for a total value of $355,920.00. Following the completion of the transaction, the chief accounting officer now owns 15,068 shares of the company’s stock, valued at approximately $5,363,002.56. The trade was a 6.22 % decrease in their ownership of the stock. The disclosure for this sale can be found here. In the last 90 days, insiders have sold 50,314 shares of company stock worth $13,337,753. 3.60% of the stock is currently owned by corporate insiders.

Institutional Inflows and Outflows

Hedge funds and other institutional investors have recently bought and sold shares of the company. Universal Beteiligungs und Servicegesellschaft mbH acquired a new position in shares of MongoDB during the fourth quarter worth approximately $13,270,000. Azzad Asset Management Inc. ADV raised its stake in shares of MongoDB by 17.7% during the fourth quarter. Azzad Asset Management Inc. ADV now owns 7,519 shares of the company’s stock valued at $1,750,000 after purchasing an additional 1,132 shares in the last quarter. Infinitum Asset Management LLC acquired a new stake in MongoDB in the fourth quarter worth about $8,148,000. Polar Asset Management Partners Inc. acquired a new position in MongoDB during the 4th quarter valued at about $14,458,000. Finally, Mackenzie Financial Corp raised its position in shares of MongoDB by 47.8% during the 4th quarter. Mackenzie Financial Corp now owns 5,731 shares of the company’s stock worth $1,334,000 after buying an additional 1,854 shares in the last quarter. 89.29% of the stock is owned by institutional investors and hedge funds.

MongoDB Stock Performance

The business’s 50 day moving average price is $262.69 and its two-hundred day moving average price is $274.71. The company has a market capitalization of $14.37 billion, a price-to-earnings ratio of -70.43 and a beta of 1.30.

About MongoDB

(Get Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Further Reading

Receive News & Ratings for MongoDB Daily – Enter your email address below to receive a concise daily summary of the latest news and analysts’ ratings for MongoDB and related companies with MarketBeat.com’s FREE daily email newsletter.

Article originally posted on mongodb google news. Visit mongodb google news

Article originally posted on InfoQ. Visit InfoQ

The InfoQ Dev Summit Boston 2025 conference (June 9-10) will bring together senior software practitioners to share proven strategies for integrating AI, scaling resilient architectures, and optimizing developer experience – three key areas that will define engineering success in the next 18 months.

Unlike conferences that only discuss the theory, this event by the team behind InfoQ and QCon, focuses on real-world implementations, with insights from Netflix, The New York Times, Shopify, CarGurus, Vanguard, and more. Speakers will share strategies that attendees can apply immediately, helping teams avoid costly trial and error.

“The next 18 months are critical for engineering teams. Those who successfully integrate AI, scale architectures, and optimize DevEx will lead. Those who don’t risk falling behind. At InfoQ Dev Summit Boston, we focus on what matters most – practical, real-world solutions for senior developers. No fluff, no hidden product pitches – just engineering insights you can use immediately”,

explained Eder Ignatowicz, InfoQ Dev Summit Boston 2025 Chair, Senior Principal Software Engineer and Architect @RedHat.

The conference’s sessions will provide practical insights from engineering leaders actively solving these challenges in production.

Keynote:

• Phil Calçado, Founder & CEO @Outropy, previously at SoundCloud, DigitalOcean, and SeatGeek, will deliver the keynote: “Key Lessons from Shipping AI Products Beyond the Hype“. Drawing from 20+ years in software development, Phil will break down the practical realities of integrating AI into products, separating what works from what doesn’t.

Featured Talks:

• Vladimir Zakharov, Enterprise Software Developer with 20+ years on Wall Street & an Open Source Contributor, will explore: “Are You Missing a Data Frame? The Power of Data Frames in Java“.
• Erin Doyle, Sr. Staff Software Engineer @Lob, formerly a Full Stack Engineer & Instructor @Egghead, will discuss: “Empathy-Driven Platforms: You Build It, Let’s Run It Together“.
• Brendan McLoughlin, Frontend Architect @CarGurus, formerly an Ember Data Maintainer, will take a problem-solving approach in: “Thinking Like a Detective: Solving Cloud Infrastructure Mysteries“.
• Travis Gosselin, Distinguished Engineer of Developer Experience @SPS Commerce, will dive into: “Building an Internal Developer Portal that Empowers Developers“.
• Hugo Marques, Senior Software Engineer @Netflix, formerly at Twitter and AWS, will share lessons from real-world experience in: “Java Concurrency from the Trenches: Lessons Learned in the Wild“.
• Francisco Javier Arceo, Senior Principal Software Engineer @Red Hat, Kubeflow Steering Committee Member, and Feast Maintainer, will break down: “Powering Enterprise AI Applications with Data and Open Source Software“.

Additional speakers include:

A Practical, Results-Driven Summit

InfoQ Dev Summit distinguishes itself from other conferences by focusing on real-world engineering execution rather than high-level trends.

• Deep dives into architecture, tooling, and team strategies that are immediately applicable.
• Focus on what teams need to adopt now, helping them navigate AI, platform engineering, and DevEx challenges effectively.
• Proven takeaways that accelerate team progress and maintain a competitive advantage in a rapidly changing technical landscape.

Early bird pricing is available until March 11. Teams can take advantage of group discounts to align on strategic engineering initiatives.

In addition to our upcoming InfoQ Dev Summit Boston 2025 event, we’re excited to announce two more InfoQ Dev Summit conferences this year: InfoQ Dev Summit Munich (October 15-16, 2025) and InfoQ Dev Summit New York (dates in December 2025 to be announced). These events will continue our focus on real-world case studies and actionable solutions from senior engineering practitioners, helping development teams tackle today’s most pressing software challenges.

Posted on mongodb google news. Visit mongodb google news

Cirrascale Cloud Services has introduced an Inference Cloud powered by the Qualcomm AI Inference Suite, enabling businesses to deploy AI models and applications efficiently with a single click. This new offering addresses the increasing demand for generative AI, providing scalable AI solutions from the cloud. The suite supports a variety of AI workloads including large language models. With cost-effective access through API interfaces, companies can integrate AI capabilities into applications such as chatbots, image generation, and code development. This development builds on previous collaborations between Cirrascale and Qualcomm, using advanced technology to streamline AI adoption.

Elsewhere in the market, Yonyou Network TechnologyLtd (SHSE:600588) was a standout up 10% and closing at CN¥20.00, close to the 52-week high. Meanwhile, MongoDB (NasdaqGM:MDB) trailed, down 26.9% to end trading at $192.98, hovering around its 52-week low.
On Wednesday, MongoDB announced its earnings, revealed its financial guidance for the upcoming fiscal year, and introduced a $200 million share buyback program.

Microsoft’s AI initiatives and global cloud expansion present substantial growth opportunities. Discover more about Microsoft’s strategic advancements in our detailed narrative on the company.

On a related note, be sure to check out our Market Insights article “Cybersecurity in 2025: Higher Stakes, Bigger Opportunity,” which explores how advancements in AI and automation are reshaping cybersecurity landscapes, thus creating significant investment opportunities within the Cloud AI sector.

Best Cloud AI Stocks

• Apple (NasdaqGS:AAPL) ended the day at $235.33 down 0.2%.
  Two days ago, the company launched its new Mac Studio and MacBook Air, featuring advanced chips and capabilities designed to enhance AI performance and connectivity.
• Alphabet (NasdaqGS:GOOGL) ended the day at $172.35 down 0.4%.
• Microsoft (NasdaqGS:MSFT) settled at $396.89 down 1%, close to the 52-week low.
  On Thursday, the company announced an expanded AI collaboration with TCW Group to enhance investment management and operational capabilities.

Seize The Opportunity

This article by Simply Wall St is general in nature. We provide commentary based on historical data
and analyst forecasts only using an unbiased methodology and our articles are not intended to be financial advice. It does not constitute a recommendation to buy or sell any stock, and does not take account of your objectives, or your
financial situation. We aim to bring you long-term focused analysis driven by fundamental data.
Note that our analysis may not factor in the latest price-sensitive company announcements or qualitative material.
Simply Wall St has no position in any stocks mentioned.

Sources:

Have feedback on this article? Concerned about the content? Get in touch with us directly. Alternatively, email editorial-team@simplywallst.com

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Rosenblatt Securities reaffirmed their buy rating on shares of MongoDB (NASDAQ:MDB – Free Report) in a research report report published on Tuesday,Benzinga reports. Rosenblatt Securities currently has a $350.00 target price on the stock.

MDB has been the subject of a number of other reports. Royal Bank of Canada increased their price target on shares of MongoDB from $350.00 to $400.00 and gave the company an “outperform” rating in a report on Tuesday, December 10th. China Renaissance initiated coverage on MongoDB in a research report on Tuesday, January 21st. They set a “buy” rating and a $351.00 price target on the stock. Barclays dropped their price objective on shares of MongoDB from $400.00 to $330.00 and set an “overweight” rating for the company in a research report on Friday, January 10th. Truist Financial reiterated a “buy” rating and issued a $400.00 price objective (up from $320.00) on shares of MongoDB in a research report on Tuesday, December 10th. Finally, Loop Capital cut their target price on MongoDB from $400.00 to $350.00 and set a “buy” rating on the stock in a research note on Monday. One analyst has rated the stock with a sell rating, six have assigned a hold rating and twenty-four have assigned a buy rating to the stock. Based on data from MarketBeat.com, the stock presently has a consensus rating of “Moderate Buy” and an average target price of $322.61.

Check Out Our Latest Report on MongoDB

MongoDB Stock Performance

Shares of MDB stock opened at $192.98 on Tuesday. The business’s fifty day moving average is $262.69 and its 200-day moving average is $274.71. MongoDB has a 1 year low of $192.79 and a 1 year high of $413.87. The stock has a market cap of $14.37 billion, a PE ratio of -70.43 and a beta of 1.30.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its quarterly earnings results on Wednesday, March 5th. The company reported $0.19 earnings per share for the quarter, missing the consensus estimate of $0.64 by ($0.45). MongoDB had a negative net margin of 10.46% and a negative return on equity of 12.22%. The business had revenue of $548.40 million for the quarter, compared to analyst estimates of $519.65 million. During the same period in the previous year, the firm posted $0.86 earnings per share. Equities research analysts predict that MongoDB will post -1.78 earnings per share for the current year.

Insider Buying and Selling at MongoDB

In other MongoDB news, CAO Thomas Bull sold 1,000 shares of the company’s stock in a transaction on Monday, December 9th. The shares were sold at an average price of $355.92, for a total value of $355,920.00. Following the sale, the chief accounting officer now directly owns 15,068 shares of the company’s stock, valued at approximately $5,363,002.56. This represents a 6.22 % decrease in their ownership of the stock. The transaction was disclosed in a document filed with the Securities & Exchange Commission, which can be accessed through this link. Also, CFO Michael Lawrence Gordon sold 5,000 shares of the company’s stock in a transaction that occurred on Monday, December 16th. The stock was sold at an average price of $267.85, for a total value of $1,339,250.00. Following the completion of the sale, the chief financial officer now owns 80,307 shares in the company, valued at approximately $21,510,229.95. This represents a 5.86 % decrease in their position. The disclosure for this sale can be found here. Over the last ninety days, insiders sold 50,314 shares of company stock valued at $13,337,753. 3.60% of the stock is currently owned by insiders.

Institutional Inflows and Outflows

Institutional investors and hedge funds have recently modified their holdings of the company. Strategic Investment Solutions Inc. IL acquired a new position in shares of MongoDB in the 4th quarter worth approximately $29,000. Hilltop National Bank grew its position in MongoDB by 47.2% in the 4th quarter. Hilltop National Bank now owns 131 shares of the company’s stock valued at $30,000 after acquiring an additional 42 shares in the last quarter. NCP Inc. purchased a new stake in MongoDB during the fourth quarter worth about $35,000. Brooklyn Investment Group acquired a new stake in shares of MongoDB during the third quarter worth about $36,000. Finally, Continuum Advisory LLC boosted its stake in shares of MongoDB by 621.1% in the third quarter. Continuum Advisory LLC now owns 137 shares of the company’s stock valued at $40,000 after purchasing an additional 118 shares during the period. Institutional investors and hedge funds own 89.29% of the company’s stock.

MongoDB Company Profile

(Get Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

See Also

Receive News & Ratings for MongoDB Daily – Enter your email address below to receive a concise daily summary of the latest news and analysts’ ratings for MongoDB and related companies with MarketBeat.com’s FREE daily email newsletter.

Article originally posted on mongodb google news. Visit mongodb google news

Article originally posted on InfoQ. Visit InfoQ

Transcript

Matusov: My name is Lizzie Matusov. My goal is to make you walk away thinking a little bit differently about what drives the highest performing engineering teams. When I was at Red Hat, I had a pretty interesting job. I was a software engineer, but I worked in our consulting arm, which basically meant every six or so months, I would get together with a new group of engineers, and we would have a product that we were working to deliver. We would go through the forming, storming, norming, and performing process as we figured out what were the processes that worked best for us to deliver our products over the finish line. We would do really great work.

Then, six months later, we would deliver our product, completely disband and start again with a new team. In running that process as many times as I did, I came to understand that social dynamics, they were driving our performance quite a bit. As I continued on in my career, I realized that those social drivers were critical towards understanding the performance of our engineering teams. To take a step back for a second, it’s actually no surprise that social drivers impact how we work in general. We’re human beings, and that means, by nature, we’re quite social. Social interactions really govern how we see the world. It’s no surprise to know that those social drivers also impact how we perform in situations like at work.

One of my favorite examples away from the engineering world of just how important social drivers is, is through, “The Bear”. It’s a show about a restaurant that goes through this transformation from a casual diner to a high-end restaurant. In one of the most famous scenes of the recent season, it’s one of the first nights of operation of this high-end restaurant, and things are really moving. It’s a very high stakes night. From the front of house, guests are being served these fantastic, high-quality dishes in a dimly lit setting, and it’s really a great experience.

From the back of house, the tension is starting to build with the people that work as the chefs. They’re supposed to be working together as a team, and they’re delivering good work, but the social dynamics between them is a little bit tense. Pressure is growing, and as it mounts over the course of the night, things start to amplify. Finally, the head chef gets locked in a freezer, is getting screamed at by his teammate from the other side, and is then left there for the rest of the night. Not how you want things to go on a team.

It’s actually a really important lesson here, because without knowing the social drivers that impact a team, we don’t know how our team is going to perform under different circumstances. Those chefs, as an example, were incredible at their work, and they were outputting high-quality products, but this was a volatile situation because of their social dynamics, and it could really impact the performance of the restaurant. That same principle applies to engineering teams. I could show you a graph of speed versus quality, and you could look at this and say, this is an engineering team that’s pretty performant. On the left-hand side, you’ve got velocity, which is steadily improving over time.

On the right-hand side you have quality metrics, like change failure rate, which is telling you that the team is deploying regularly with minimal impacts to production and their builds. This would be what we would call an elite performing team. If I showed you these graphs, you’d suddenly think a little bit differently about this team. This is a team that has ever-decreasing psychological safety and heavily increased risk of burnout. This is a team that’s on the edge of breaking. What you see on those top two graphs is not going to last if things don’t change. You might be looking at these graphs and thinking, Lizzie, that’s great, but capturing and analyzing this type of data, it’s not an easy feat.

Confidence by Measurement Cadence

Also, let me tell you why this is important. We took a sample of responses from about 30 companies and asked people to tell us, how often do they measure social drivers and how confident are they in their understanding of their team’s productivity? What you’ll see is that the teams who measure social drivers on a quarterly or monthly basis are more likely to feel confident that they understand their team’s productivity.

It’s not a guarantee, but what this shows us is that without doing some regular measurement of the social drivers on your team, you are just not likely to feel confident in your team’s productivity. In this talk, I want to show you what matters, how to capture that data, and then the steps you can take today to get started.

Timeline

We’re going to first introduce a framework that’s called TAPPs, that covers the most important social dynamics that you should know to understand the performance of your engineering team. Then we’re going to talk a little bit about the measurement. We’ll get into the who and the how. Third, we’ll talk about how to get started.

The TAPPs Framework (Setting the Scene)

Before we get into those dimensions, I want to set the scene. This is probably a situation that many of you have been in before, so it might sound a little bit familiar. Let’s say that we’re thinking about a software engineering team, and they’re working towards a big launch. This is a really important launch, and it’s going to drive a lot of revenue for the company, so no pressure, but a lot of pressure. They’re getting close to the finish line.

The launch plan has been written. We’re on to the final stages of development, and suddenly somebody discovers a bug. We don’t know what the impact of that bug is. We don’t even know really the severity. We just know that it exists. The question is, what does that teammate do? I’m going to walk you through how you should think about that. I’m going to continue the story using what I call the TAPPs framework, or the top four social drivers that you can use to understand the performance of your engineering team, which is trust, autonomy, purpose, and psychological safety.

1. Trust

Let’s start with trust. Trust is the belief that the people you work with are on the same page as you. It’s knowing that the teammates that you work with are going to deliver on their commitments, share honest feedback, and support each other’s work. How does that story go when you have low trust versus high trust? In a low trust setting, the teammate who discovers the bug, they’ll share what they discover to their team, but they’re just not sure that they believe the team is going to take it as seriously as they need to. They’ll tell the team, but they’re also going to go ahead and do their own discovery, their own analysis, their own research, and maybe form their own conclusion.

The rest of the team is probably going to do the same thing. They’re thinking, let me find out for myself, because I’m not sure that I trust my team to have the right assessment of what’s going on. What you just had was a lot of redundant work and a lot of wasted effort. If the bug is not high impact, then what that means is the team just wasted a ton of cycles all doing the same amount of research to come to that same conclusion. If the bug is significant, then all that time that was spent doing redundant work could have been spent helping find a solution. We’re also just assuming as well that the team trusts that the individual has the right assessment of a bug.

There just as well could be a case where everybody says, “I’m not sure that I even trust this as a bug, because you were the one that shared it”. It’s not a great situation. Let’s play out a high trust scenario. In a high trust scenario, the teammate will share what they’ve discovered and call together a meeting. They’ll do some initial diagnosis work together, and then they will break up to do various pieces of the discovery, the analysis, and the triaging. Then the team comes together to knowledge share.

Now they get to learn from one another, they get to pool their knowledge, and they’re able to much more quickly identify and resolve the issue. If it’s not an issue, then we probably found out pretty quickly, and if it was an issue, the team came together quickly in order to find a solution. Trust leads to open communication, faster problem solving, and less rework. It’s what allows the team to break up, work independently, and then come together and share in what they’ve learned, knowing that they understand the whole team is on the same page.

What’s some of the research behind it? In 2019, a team of researchers at Google asked over 600 developers across three different companies to identify what factors impacted their productivity most. What you’ll see in this graph is the top factors, starting from F1 moving down to F10, that predicts engineers’ productivity. Highlighted in yellow are the factors that relate to how well they trust their team, which is 40% of the top 10 factors. These are things like, people on my project are supportive of new ideas, or people who write code for my software are highly capable. These findings show us that trust is imperative in the productivity of software engineers.

The impact of trust is extremely important when it comes to the performance of a team. For team performance, you heard me share earlier about how improves collaboration on the team, which helps makes the team much more productive. From a product performance standpoint, you see increased product reliability and other downstream effects like decreased deployment time and decreased change failure rate. What’s incredible is that the DORA report in 2022 and 2023 found that a high trust culture correlated with a 30% increase in organizational performance.

2. Autonomy

Now that we know that trust is a massive driver of performance on engineering teams, let’s talk about autonomy. Autonomy is the ability of software engineers to make decisions independently about their work. The whole team is going to have a clear sense of alignment on goals and boundaries, but within the team, teammates feel empowered to figure out what makes sense, how to prioritize their work, and how to achieve their team’s goals independently and how they see fit. Let’s consider the story here. In a low autonomy ending, the team is often inhibited by process or permissions, which impacts their own ability to quickly triage and determine the severity of the bug.

This new engineer, or this engineer that comes in and discovers this bug might have some ideas about what it could be, but instead needs to pass it over to a formal channel, instead of independently taking those first steps to discover how severe and what the impact could be. That means there’s a delay in determining how important this issue is. If it’s not a big issue, then there was a small lag. If it is a big issue, then it’s possible that that was just sitting in a queue waiting to be looked at by a formal process, when that engineer could have gotten started understanding what the impact is and come with a much richer discussion. Let’s look at a high autonomy situation.

In a high autonomy situation, the teammate who discovers the bug is going to decide that this is an important thing to look into to understand the potential impact. They’ll probably prioritize it over another task that they’re doing, because they think that the impact could be big. What happens is, if this is not an issue, then they just saved the team from spinning their wheels over something that wasn’t a concern. If it is a big issue, then they’re going to come into the conversation with a lot more information about the impact, the severity, and what they should do next, which allows the team to move much faster.

Autonomy is what gives engineers the power to solve problems faster. As engineers, one of our strongest skills is in our ability to solve problems. Autonomy is really the foundation that allows us to do our best work. Let’s talk about the research. I first want to bring back this study that we just talked about before. You remember how I told you that 40% of the top 10 factors related to trust? Another 30% of them relate to autonomy. Things like, my job allows me to make decisions about what methods I use to complete my work, or, my job allows me to use personal judgment in carrying out my work. There’s another great study that we can look at too.

In 2017, researchers asked software engineers and managers to identify and rank what makes a great manager of software engineers. On the left you’ll see what’s called a violin plot, which shows you the top ranked answers from top to bottom. For each attribute, you’ll see the wavy line shows you the distribution of responses for engineers on top of the line and managers below the line. Then the thick horizontal lines will show you the interquartile range. The vertical line shows you the mean. The most important thing you should take away from this, though, is that enables autonomy was number three.

More interesting thing is that it really had the highest consensus equated from both engineers and managers on being highly important. Basically, engineers and their managers agree that autonomy is foundational for the performance of engineering teams. The results really speak for themselves. Autonomy empowers engineering teams to increase collaboration and improve delivery cycles. In fact, high-performing teams are two times more likely to have high levels of autonomy than low-performing teams. Behaviors of autonomy also just lead the team to move faster, as we heard in our story above.

High autonomy teams are 1.4 times more likely to achieve high deployment frequency and lower lead time compared to people with less autonomy. Perhaps most interesting is that when you give teams a shared goal and the teammates have the space to choose their way of aligning with that goal, it actually builds strategic alignment. You’re giving people the space to say, this is the goal, and how you help us get there is your own way. That’s really important for helping to build organizational alignment towards the same goals for the year.

3. Purpose

We’ve talked about autonomy. Now let’s talk about purpose. I’m sure we’ve all felt the contrast of going from a place where you’re just clocking in and clocking out, and it’s a 9:00 to 5:00, and we’d like to be done with the day, to a team and a company where you feel like what you’re doing really matters. That feeling is purpose. It’s that clear shared understanding of why a team’s work matters and how it aligns with broader organizational goals. Let’s talk about a low purpose ending. You guys have seen, “Office Space”. I think that is one of the most fantastic examples of a team that has very low sense of purpose. In this world, an engineer discovers a bug and they feel indifferent.

Or worse, they’re annoyed, because they’re like, “Now I’m going to have to work late tonight, and I just really didn’t want to be here in the first place”. They’ll probably communicate the issue, but it’s not going to be with the same sense of urgency. The team is probably not going to find the most optimal solution to resolve it, because, quite frankly, if the team has a low sense of purpose, then they don’t really care about finding the best possible outcome for their users. You can see in my description how product quality suffers.

When a team cares a lot about the impact of their work, they’re going to make sure that that work speaks for itself. In a high purpose environment, the engineer and the team will quickly come together to minimize the impact to their project and keep the team marching towards the deadline. They’re going to come up with creative solutions to minimize impact to their end users, because they really care about delivering something for their customers. They’re going to thoroughly report, advocate clearly, and resolve effectively, again, because they care.

Purpose matters, because it aligns engineers’ work to the customers that they serve. There’s actually some really interesting research about this. The 2024 DORA report found that with high user-centricity, delivery throughput did not correlate with product performance. Let me take a step back and talk about what that means. First off, I’ve talked about the DORA report a couple of times, but I realized I didn’t level set what it is.

The context is, the DORA report is a study that’s performed by the DevOps Research Assessment group at Google, where they collect data from over 30,000 engineering leaders across the world, and then they use that to understand what are the drivers and signals of high-performing engineering teams. This year, what they found is that actually in teams with higher user-centricity, which means higher alignment to their users, delivery throughput, or how fast features get delivered, actually doesn’t correlate with product performance. This means that even if you deliver at half the throughput, it doesn’t necessarily mean that your product is going to be better, as long as you have high user-centricity.

That doesn’t intuitively make sense, because we know that rapidly delivering features to your customers usually builds better products. Why does that happen? In the words of the researchers, there’s no longer a disconnect between the software that’s developed and the world that it lives. The researchers believe that it’s because when a team feels a sense of purpose towards their work and the users that they serve, they’re always going to be pointed in the right direction of delivering value. Purpose matters. It’s what makes teams perform better. It makes them excited about their work. It improves both their collaboration and their job satisfaction.

It’s what improves both the stability, the reliability, and the performance of the product. Then, from an organizational standpoint, it’s what keeps the organization together and reduces attrition. Teams want to work on products that they believe really matter.

4. Psychological Safety

Finally, I want to talk about psychological safety. I want to talk a little bit about what it is as well as what it isn’t, because it’s a word that gets thrown out quite a bit, and I want to make sure that we’re clear on what it means. What is psychological safety? It’s the belief that a teammate can take interpersonal risks without fear of negative consequences. Things like speaking up, asking a question, admitting that something went wrong. It’s what allows team members to do that in an environment where they feel safe and comfortable doing that. There are some really important nuances here that I just want to make sure that we get right. Let’s talk about what it’s not.

Dr. Amy Edmondson, a Harvard professor who really brought this term into mainstream popularity, once said, this term implies to people a sense of coziness, that we’re all just going to be nice to each other. That’s not what it’s really about. What it is about is candor. It’s about being direct, taking risks, and being willing to say, I screwed that up. It’s a common and very misguided understanding of the team when people say things like, psychological safety is comfort, or that it’s a soft type of team. Let me walk through how it manifests on teams. I’m going to continue our story here, so that way you can really see how it would play out.

An important additional factor I want you to consider is accountability, because the way psychological safety manifests, depends on how much accountability is present on the team. Let’s say we’ve got a team, this team that we’re talking about has both low psychological safety and a low sense of accountability. This is what we would call the apathy zone. There aren’t really repercussions for mistakes. Teams don’t really have that much support. What happens is people actually struggle to care about their work because they feel a little bit disengaged. It honestly sounds a lot like a low sense of purpose.

It’s actually true that if you have low psychological safety and low accountability, you’re also likely to have a low sense of purpose. If the bug is identified, it’s probably not going to be treated with much of a sense of urgency, but there’s also not a lot of accountability in doing that. Let’s say this team has a high sense of accountability and still, low psychological safety.

This is what we would call the anxiety zone. It’s that fear of humiliation or punishment or blame that keeps the team from working effectively. If you’ve ever experienced a situation where you want to bring something up, but you really don’t want to sound stupid, or you want to mention that this bug is happening, but you don’t want to out your teammate and have them get in trouble for it, that sounds a lot like this anxiety zone.

In the case of our team here, the individual who discovers it, they might try and scramble and solve it themselves, cleaning it up so that nobody else sees, mostly because they don’t want to be associated with that bug. If they bring it up, they’re worried it’s going to be a blame game. They don’t want whoever maybe caused the bug to get in trouble either. We’re focusing a lot on who did it and why are you bringing this up, as opposed to, how do we actually solve for it? That’s a huge communication failure that keeps the team from focusing on what matters, which is solving this bug before we have this launch.

Let’s talk about higher psychological safety. Let’s say we’ve got high psychological safety, but we have low accountability. This is often what people think about when they talk about psychological safety, and they use it in an incorrect context. In this case, the team does work really well together. They have comfort. They know that they can take risks and speak up, but they don’t really have a push to be held accountable for it. They’ll feel comfortable communicating that issue. They’ll triage the impact, and they’ll find a solution, but there’s not really that sense of urgency placed on the team.

The good news here is that the team does like working together, that’s always great. They know that they can take risks. The bad news is they feel no reason. They’re not compelled to take any risks. The real magic happens when you have both high accountability and psychological safety. The team moves fast. They’re focusing their problems on what to do and how to solve, instead of looking back at who did this or why would you ask that. In our story, this would be the team that would work quickly to identify the impact, put out a solution, and would never put an individual to blame in the process.

The team has the opportunity to learn from their experience moving forward, and they’ll be compelled to do better next time from the lessons that they’ve learned. These are the teams that move quickly, perform well, and learn a lot. Psychological safety is the driver behind taking calculated risks, learning quickly, iterating, and building the most innovative solutions.

For the research here, I want to talk about an extremely impactful and one of my favorite research studies on workplaces, to really highlight just how critical psychological safety is. In 2012, Google endeavored to discover, what is the most performant engineering team? They looked at about 180 teams internal to Google to understand, why do some teams consistently perform better than others. They looked at factors like team size, composition, management style, individual skill sets, so many things.

For a while it was just noise, until they started thinking, what if we measure the dynamics that happen within those teams and bring that in as a data point? Suddenly they started seeing correlations. What they actually found was that these individual factors, like team composition, individual skill set, managerial style, they were actually far less important than how the team worked together. They discovered five key elements in order of importance, from top to bottom, that set successful teams up.

At the top, you have psychological safety, followed by dependability, structure and clarity, meaning, and impact. Psychological safety was so important that they basically immediately created working groups to figure out, how do they make every single team exhibit higher psychological safety so they could gain on their performance? What’s also really nice here is that you’ll see some of the items we talked about from the TAPPs framework are also covered here in Google’s Project Aristotle.

Another really awesome way of showcasing the value of psychological safety is the 2019 DORA report. They evaluated which factors contribute to organizational performance and productivity. What they found is that psychological safety is the only dimension that actually impacts both. Solving for psychological safety will improve not just the productivity of the team, but the performance of the organization, more broadly. The impact is profound. Teams with higher psychological safety are up to 20% more productive compared to teams without it.

On the product side, psychological safety correlates with better product performance across the board, because teams feel comfortable taking risks and experimenting and trying new things, knowing that failure isn’t going to be seen as a threat against their own selves. All these benefits give the organization a huge lift in their overall performance, but also in retention. People want to work on teams where they can take risks, try new things, and do so in an environment that supports them.

Measurement: The Who and How

We’ve now covered the dimensions of the TAPPs framework. I want to spend a little bit time talking about measurement, the who and the how. Then we’ll talk a little bit about how we can apply it to our teams today. Let’s first talk about who’s involved in this process. In an engineering organization, the groups that you can imagine are, of course, the engineers who are on the team, the management, and at the highest level, the executive. You need the team to contribute data, because they’re the ones on the ground experiencing and contributing to the social dynamics.

Of course, giving visibility to management and executives is important for building buy-in, for executing these larger projects. I want to focus on a really key line here that is often overlooked, and we should be talking about. The team should be involved in both viewing and analyzing the data. This might seem obvious to some of you, but it’s actually not the status quo.

As engineers, you can probably relate to the experience of someone sending you a survey to fill out that you spend your hard-earned time on, and then you finish it, and you submit it, and you never hear anything again about what happened. Does that sound like an experience some of you have had? Yes, happens all the time. It turns out that the research overwhelmingly shows that having engineering teams see the data and contribute to the analysis of the data is what’s going to lead to actual change on the team. Why is that? There are two big reasons. One, to contribute the data, teams must trust the data.

In the case of social drivers, the most powerful way to capture that data is to ask the engineers who are living that experience day to day. If an engineer just doesn’t believe that this data is actually going to be used to improve their team, why are they going to spend the time on it? Even worse, if they believe that that data could be used in an adverse way against their team, then they’re certainly not likely to give authentic and honest responses. This is something that was also highlighted in Nicole Forsgren and Gene Kim’s book, “Accelerate”. The second reason is because building alignment is what drives results.

When the team can weigh in on their perspective and build buy-in on what actions the team should take, they’ll feel a greater sense of ownership over that work. When they feel greater sense of ownership over the changes, those changes will get executed faster. We just talked about how autonomy builds strategic alignment by giving the team the independence to achieve an organizational goal in the way that they see best. The same thing goes for driving these performance improvements more broadly. The more you can give the engineering team the opportunity to build alignment in their social drivers and how they work, the better the results will be.

Now that we know who should be involved, let’s talk about how to actually measure this data. In my work, I’ve talked to thousands of engineering leaders, and sometimes I’ll ask them questions like, how are you guys measuring these social drivers today? A very common answer that I get is, we do it in one-on-ones. If you guys have experience with one-on-ones, which I would venture to say at least 80% of the people do, then you probably know something about how those agendas might go.

In a 30-minute discussion, let’s say, you’ve got to talk about your holiday PTO coming up. How’s this upcoming project? Any challenges? Any blockers? What are our priorities for Q4? Let’s make sure to have that performance and career conversation so you’re set up for next year. We forgot to talk about the team social drivers, let’s make sure to cover that too. I don’t know how long you guys have for your one-on-one conversations, but this is a lot to pack in to 30 minutes. That’s a problem, because what that means is that it’s rushed, and the team might not be getting the space to really think about the social drivers that impact them.

Worse, it’s unstructured, biased data. It’s unstructured because you’re probably not going to be listening to people compare apples to apples. What you’ll be hearing is, here’s a story of how trust was impacted in my engineering team. As a manager, those stories are really important, but it’s very difficult to understand how one story compares to another story as far as severity and impact.

More importantly, we’re asking teammates to exchange information on social drivers with another human being. You have to assume a certain level of social drivers being present in order to have that conversation. If you think back to psychological safety, if you have a team with low psych safety, a teammate is going to feel hesitant bringing up some of these situations because they don’t want to get another teammate in trouble, or they don’t want to look like the person who is bringing up all these issues and causing nuances in the team.

In an honest search for information, the strategy of one-on-ones is actually not a very effective way to capture this data. The best way to measure social drivers on engineering teams is through anonymous, aggregated surveys. The biggest criticism we hear is that, and it’s just so hard to set these surveys up so they’re measuring the right thing and getting the right responses. I hear you. Let’s talk about how we can actually do this. To design a survey well, you need a few ingredients. I’m going to use trust as one of our TAPP social dimensions here as an example.

First things first, you need to have a clear research-backed question. This question is actually pulled from one of the research papers we talked about, so it was designed by the researchers at Microsoft in one of their productivity and performance studies. Actually, I’ll share a link so you guys can just get all of the TAPPs questions, the questions that you would want to ask on your team, so you don’t have to even worry about designing this. One thing that I will point out is that it’s a single barrel question, which means it’s only asking one thing, that makes it clear and easy to map to the original dimension.

The second thing is a survey scale. What you need is consistency. Here we’re using a Likert scale, which is, from 1 to 5, strongly disagree to strongly agree. It’s easy to understand. It creates space for outlier answers. Most importantly, you can start to do statistical analysis on this data and see how the mean or the ranges change over time.

Finally, and perhaps most importantly, you want to design the survey to be anonymous and also aggregate your responses to the team level over time. Social dimensions are inherently about the interactions between teammates, and so your atomic unit should really be the team, not the individuals who are responding. To reinforce this and to also keep a high trust environment, you’re going to want to make this data anonymous, and again, aggregated to the team level.

How to Get Started

Now that we know what the social dimensions are, we can understand how best to measure them. Let’s talk about what your teams can do today to go out and start capturing this data. To get started, you’re going to want to focus on three key steps that I’m going to break down. First, you’re going to want to build a process that’s going to allow you to capture this data over time, more reliably. Second, you’re going to want to review the data regularly and with curiosity. We’ll talk about what that means. Third, you want to drive actions and improvement, and create a consistent flywheel, from measurement to improvement.

First things first, you want to build a process to reliably measure TAPPs over time. This means that you’re regularly collecting data so you can analyze how it changes over time. There’s nothing wrong with starting with one-on-ones, but the benefit of moving to a survey-based structure, especially an anonymized and aggregated survey, is that you can more easily establish a process that allows you to see that change over time. You can look at things like the range of responses. You can look at the means. You can see how this graph changes over time.

Suddenly, you’re getting a much better understanding of your team’s psychological safety over a longer time horizon. I also recommend that you measure these dimensions at least quarterly. If you establish a flywheel and good trust with your engineering teams, capturing this data monthly is actually going to be your best bet, because it allows you to capture early signals of changes that need to be addressed, as well as crazy outliers that might be a conversation that you need to have.

Now that we’ve talked about how to set up that process, let’s talk about how to review that data with curiosity in mind. For this, I have a few tips. When you’re analyzing this data, think about changes over time over a single snapshot. Again, if there’s a crazy swing, you’ll want to know what happened there. In general, you want to look at how things are trending over time, because that’ll give you a better sense of how does the team actually operate in their day to day and the social drivers that impact them, as opposed to maybe what happened on a particular Tuesday.

The second thing you want to do is ask yourself, why? As teams we should understand the stories of what’s going on. If you see a giant spike upwards, that could be after a team off-site, where the team really felt like they came together and really understood each other. Or if you see things suddenly shoot down, and you look and say, this correlates with when our deadlines got pushed up by six weeks, and pressure really mounted. Ask yourself those questions. Think about the why. Then, third, I touched on this a bit before, but don’t over-index on a single data point, particularly when you’re looking at ranges.

You really want to think about, how are the averages, or how are the team’s responses changing over time? Instead of, again, really over-indexing on a single data point. Now the team is capturing data and they’re reviewing it regularly, you can now use that data to drive meaningful improvements. For example, if you see a consistent trend of the team’s sense of purpose declining, you could consider bringing your team closer to their end users. Maybe that’s having them listen to some customer success conversations, or having the product team come in and do a lunch and learn where they’re able to talk about this last feature that was built and how it actually impacted the users.

Then, those actions are going to drive changes in your team’s sense of purpose, and hopefully, if you’ve set up a consistent form of measurement, you can see those changes over time. Now you’re able to create this process of continuing to collect the data, analyzing these data, taking the right actions, and seeing change on the other side.

Key Takeaways

First, to capture the top social drivers behind engineering team performance, use the TAPPs framework, that’s trust, autonomy, purpose, and psychological safety. Why do these four things matter? Trust is what unlocks open communication, faster problem solving, and less rework. Autonomy empowers engineers to make decisions faster and solve their problems. Purpose is what aligns engineers’ work to the customers that they serve. Psychological safety enables risk taking, honest communication, and greater innovation. That is the TAPPs framework. How do you go about executing it?

For the best results, engineers should have visibility into data collection and analysis. Of course, you want to make sure that management and executives are involved as well, but don’t leave this line out. The best way to measure social drivers is through anonymized, aggregated surveys. One-on-ones are a great place to start, but if you really want to kick off that flywheel of moving from information to action to measurement, you’re going to want to use a consistent measurement technique like surveys.

To get started today, teams should build a consistent process, review the data regularly, and of course, with curiosity, and drive actions and improvements. When we know the top social drivers that impact a team, we can create a happier and higher-performing engineering culture.

Resources

You can actually access the survey questions for the TAPPs framework, www.getquotient.com/qcon, so if you want to grab that, start measuring it on your team. You’ll also be able to access research from this presentation, and more, and other topics on engineering leadership.

See more presentations with transcripts

Posted on mongodb google news. Visit mongodb google news

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

AI game is changing.

The chip guys, like Nvidia, they had their moment. The first AI wave? They rode it high.

But guess what? That ride’s over. Nvidia’s been flatlining since June 2024.

Remember the internet boom? Everyone thought Cisco and Intel were the kings, right? Wrong. The real money was made by the companies that actually used the internet to build something new: e-commerce, search engines, social media.

And it’s the same deal with AI. The chipmakers? They’re yesterday’s news. The real winners? They’re the robotics companies, the ones building the robots we only dreamed about before.

We’re talking AI 2.0. The first wave was about the chips, this one’s about the robots. Robots that can do your chores, robots that can work in factories, robots that will change everything. Labor shortages? Gone. Industries revolutionized? You bet.

This isn’t some far-off fantasy, it’s happening right now. And there’s one company, a robotics company, that’s leading the charge. They’ve got the cutting-edge tech, they’re ahead of the curve, and they’re dirt cheap right now. We’re talking potential 100x returns in the next few years. You snooze, you lose.

Here’s the catch (it’s a good one): To uncover this sleeping giant, you’ll need our exclusive intel.

We want to make sure none of our valued readers miss out on this groundbreaking opportunity!

That’s why we’re slashing the price of our Premium Readership Newsletter by a whopping 70%.

For a ridiculously low price of just $29.99, you can unlock a year’s worth of in-depth investment research and exclusive insights – that’s less than a single restaurant meal!

Here’s why this is a deal you can’t afford to pass up:

• Access to our Detailed Report on this Game-Changing AI Stock: Our in-depth report dives deep into our #1 AI stock’s groundbreaking technology and massive growth potential.

• 11 New Issues of Our Premium Readership Newsletter: You will also receive 11 new issues and at least one new stock pick per month from our monthly newsletter’s portfolio over the next 12 months. These stocks are handpicked by our research director, Dr. Inan Dogan.

• One free upcoming issue of our 70+ page Quarterly Newsletter: A value of $149

• Bonus Reports: Premium access to members-only fund manager video interviews

• Ad-Free Browsing: Enjoy a year of investment research free from distracting banner and pop-up ads, allowing you to focus on uncovering the next big opportunity.

• 30-Day Money-Back Guarantee:  If you’re not absolutely satisfied with our service, we’ll provide a full refund within 30 days, no questions asked.

Space is Limited! Only 1000 spots are available for this exclusive offer. Don’t let this chance slip away – subscribe to our Premium Readership Newsletter today and unlock the potential for a life-changing investment.

Here’s what to do next:

1. Head over to our website and subscribe to our Premium Readership Newsletter for just $29.99.

2. Enjoy a year of ad-free browsing, exclusive access to our in-depth report on the revolutionary AI company, and the upcoming issues of our Premium Readership Newsletter over the next 12 months.

3. Sit back, relax, and know that you’re backed by our ironclad 30-day money-back guarantee.

Don’t miss out on this incredible opportunity! Subscribe now and take control of your AI investment future!

No worries about auto-renewals! Our 30-Day Money-Back Guarantee applies whether you’re joining us for the first time or renewing your subscription a year later!

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Article originally posted on mongodb google news. Visit mongodb google news

Posted on mongodb google news. Visit mongodb google news

Market Overview

Investors are concerned about U.S. economic growth and AI investment prospects. Trump’s tariff concessions failed to quell pessimism, with the Nasdaq falling over 4% this week, officially entering a 10% correction zone.

Affected by the impact of DeepSeek and Alibaba’s latest AI achievements, the U.S. AI boom is cooling down. Investors are closely monitoring tech company earnings reports to assess the sustainability of AI trades. Micron Technology’s revenue guidance fell short of the highest expectations, with its stock price plunging over 20% during intraday trading, dampening market sentiment.

Software stock MongoDB fell about 27%, Applovin dropped 18.36%, BigBear.AI decreased by 12.5%, with Q4 revenue below expectations and losses exceeding expectations. It is expected that adjusted EBITDA will be in the negative single digits this year, with U.S. stocks at one point dropping over 16% after hours.

The seven major tech giants all fell, with NVIDIA down 5.74%, Tesla down 5.61%, Meta down 4.35%, Amazon down 3.68%, Microsoft down 1.03%, Google A down 0.39%, and Apple down 0.17%.

However, Broadcom’s optimistic earnings guidance after hours eased some AI investors’ concerns, with Q2 revenue exceeding expectations. Its stock price surged over 17% at one point, leading NVIDIA to turn positive after hours.

China National People’s Congress Press Conference: Responding to the U.S. with “an eye for an eye,” plans to cut reserve requirement ratio and interest rates at an opportune time this year

Key points from the Q&A include: The People’s Bank of China will cut interest rates and reserve requirement ratios at an opportune time this year; plans to establish a venture guidance fund to support large tech companies in issuing bonds; the Ministry of Finance has “ample” policy tools and room to respond to uncertainties; a special action to promote consumption will be introduced; and if the U.S. further increases tariffs, there will be corresponding responses.

Trump Concedes, Delays Tariffs on Mexican Goods Under USMCA Until April 2

According to CCTV News, on Thursday, March 6, local time, U.S. President Trump signed an amendment to tariffs on Mexico and Canada, exempting products that comply with the “United States-Mexico-Canada Agreement” (commonly referred to as USMCA) from tariffs until April 2.

Before Trump’s announcement of the exemption for Mexican products, U.S. Secretary of Commerce Wilbur Ross stated that all goods and services that comply with the USMCA could be exempt from tariffs.

Trudeau later stated that Canada would not remove retaliatory tariffs unless the U.S. first cancels all increased tariffs.

Trump: Delay of Tariffs on Mexico Unrelated to Stock Market, “Didn’t Even Look at the Market”

Trump stated during a press conference at the White House that the decision to delay tariffs on trade with Canada and Mexico under the USMCA is unrelated to the performance of the U.S. stock market. Trump said he “didn’t even look at the market” because the U.S. will be strong in the long run.

When asked about his views on the U.S. stock sell-off, Trump stated that the culprits behind the decline are “globalists.” “Those globalists foresee how wealthy our country will become, and they don’t want to see that happen.”

Broadcom’s Earnings Exceed Expectations, Surging 17% After Hours

The earnings report showed that Broadcom’s revenue for the first fiscal quarter was $14.92 billion, a 25% year-on-year increase, exceeding analysts’ expectations of $14.61 billion; adjusted EPS was $1.60, higher than the analysts’ expectation of $1.50
At the same time, Broadcom expects second-quarter revenue to be approximately $14.9 billion, a year-on-year increase of 19%, exceeding analysts’ expectations of $14.59 billion; it is anticipated that second-quarter AI semiconductor revenue will reach $4.4 billion, sending a strong signal to investors that AI computing spending remains robust, which stimulated the company’s stock price to rise by as much as 17% in after-hours trading.

Analysts believe that Broadcom’s latest financial report indicates that the historic spending boom in the AI sector continues. As the complexity of AI computing tasks and personalized demands increase, large technology companies will further turn to custom chips instead of relying on standard chips, a trend that is expected to allow Broadcom to continue benefiting.

“AI Chip Popularity” Marvell Technology Stock Price Plummets 20%

Marvell expects first-quarter sales to be approximately $1.88 billion, which, while in line with average expectations, falls short of the highest expectation of $2 billion. Analysts believe that this financial report does little to ease market tensions regarding AI stocks.

During the conference call, the company stated that ASICs account for 25% of data center business revenue, and AI revenue for fiscal year 2026 will significantly exceed the $2.5 billion target. The company is steadily progressing towards its goal of capturing a 20% market share in the global data center business, while the total market size is also developing towards $75 billion, currently growing faster than expected. Additionally, the company’s optical business is strong, with a significant increase in orders in the second half of last year and robust demand this year.

JD.com Q4 Net Profit Increases 190.8% Year-on-Year, Plans to Repurchase Up to $5 Billion in Stock Over the Next 36 Months

JD.com’s Q4 revenue grew 13.4% year-on-year, marking the fastest growth rate in nearly three years; operating profit increased by 319.3% year-on-year. The continuous improvement in profitability is mainly attributed to the company’s optimization in cost control and operational efficiency. JD.com’s stock price rose by 10% in pre-market trading but later retraced most of its gains.

JD.com stated during the conference call that policy support has boosted consumption, and the company expects profit margins to steadily improve, targeting high single digits. Instant retail is an extension of the core retail business, and delivery services, as a high-frequency business, can enhance user stickiness. JD.com will continue to optimize its delivery network to improve overall retail efficiency.

Alibaba Open Sources QwQ-32B, Comparable to DeepSeek R1 Performance with 1/21 Parameters, Cost Only 1/10

The QwQ-32B large language model has only 32 billion parameters, which can not only compete with the DeepSeek-R1 with 671 billion parameters (of which 37 billion are activated) but also surpass it in certain tests. The breakthrough of QwQ-32B will further promote the paradigm shift of AI large models from “great power produces miracles” to “delicacy produces wisdom,” breaking some people’s overly pessimistic views after GPT-4.5 hit a wall.

European Central Bank Cuts Interest Rates as Expected, Lowers Rates by 25 Basis Points, Suggests Easing Cycle May Be Nearing Its End

On Thursday, the European Central Bank lowered the deposit facility rate from 2.75% to 2.5%, marking the sixth rate cut since June of last year, but also hinted that the rate-cutting cycle may be nearing its end as inflation cools and the economy digests the severe changes in geopolitics. Traders have reduced their expectations for further rate cuts by the European Central Bank, anticipating a further cut of 41 basis points by the end of the year

Article originally posted on mongodb google news. Visit mongodb google news