Month: August 2024

Article originally posted on InfoQ. Visit InfoQ

Transcript

Stenglein: My name is Dave Stenglein. I am now an independent consultant. Spent about half my career doing systems of the Unix SA, back when there was more than just Linux. I’ve been for the last 15 years doing consulting in software, and cloud, and workflow, and things like that. I’m going to talk about empathy, and empathy with platforms. I’m also going to tell you about how you can use empathy in building your platforms as well. This is a non-technical talk, but there’s lots of interesting things having to do with technology in here.

A Tale of Hubris: A Costly Mistake

We’re going to start with a story about something that went sideways with implementing a platform. We had built a cloud native platform, and we were going to embark on a project to extend it. The platform was very nice. It was built on the Netflix stack. It had automated deployments, blue-green. It used, at the time, it was a while ago, many of the tools available for getting really good visibility. It was a great platform, but everything can be improved. There were a number of usability issues that we felt needed to be taken care of so that the users would have a better understanding of what was running where and how to actually separate their deployments, figure out, not what was running where but when it had been running, all sorts of things that we thought would make for a better user experience.

We got approval for a project to extend the platform this way, and we got to work. We started building. It’s what tech teams do. We knew what needed to be done. We sat down, like I said, we built this thing so we were in the best position to make what was needed for it. Then we got to time to demo with the customers who are not stakeholders, we got sign off for this from the stakeholders. Those are not necessarily the same as the users of the system.

When we started demoing our solution for the platform to them, we started getting negative feedback, and we were not somehow meeting their expectations. Then we went back to the drawing board, we took the feedback, wondering why we were so far off the mark, since we built this thing in the first place, and we knew what it needed. We should be able to put something in front of them that would knock their socks off. We ended up doing this a few times, going back, demoing, not getting particularly good feedback. Until the point where we figured out we had a pretty fundamental disconnect with what the users expected and what we were building.

In the end, it became clear that no one was going to use this thing. It didn’t matter if we were going to try and finish building it, no one’s going to adopt what we were building, which is not what you want to hear when you’re building a platform. We ended up with a canceled project, which is costly. You build something with the intent to accelerate teams, and you end up putting a lot of work into it. That’s time and money spent that did not go towards making the company more effective. What happened?

It came down to a matter of our opinion versus our customer’s perspective. We had an opinion that we knew what needed to be done, and we got to work more or less in a vacuum. We did not consider what our users’ perspective was. We didn’t consider that their idea of what was a good solution and a good change for the platform did not match what we thought was the same thing. We thought we’re aligned, we’re not. Our idea that we built it and therefore we knew what was best for it did not work out at all. We didn’t have empathy for our customer. We didn’t attempt to sit in their shoes, find out what their lived experience was, and see what they needed. We assumed what they needed and it just didn’t work out.

How Does Empathy Change Things?

How does empathy change things? What do you think when you see this? Before I think, aw. Thing is, that is sympathy, not empathy. Sympathy is your reaction to seeing someone in distress, and you’re not necessarily seeing that from their perspective. Empathy is the ability to see experiences from the perspective of someone else. This is important from sympathy, because sympathy is just seeing a negative emotion or essentially having a negative emotion when you see someone in distress.

Whereas you see this, and this may be triggering for a few people that are old enough to have seen server rooms, you can imagine what this person is going through. You’re able to see from their perspective, probably because you’ve even been there. Empathy isn’t just about negative emotions, you can also experience excitement through other people. You can essentially be excited for someone because you know what they’re experiencing, now that’s a good thing. Empathy is important for understanding someone’s perspective, and knowing why they might see things in a good light, or bad light.

There are certain do’s and don’ts with empathy. You do want to listen. It’s very difficult for technical people to just listen. It’s almost always the first thing they hear, they pattern match, and then they start solutioning. Instead of listening to the person that is telling them something about what they’re experiencing, and deciding what they need to do with that. You need to ask questions. If you’re going to listen, you also need to do some active listening, which usually involves asking questions that are not leading to a specific solution.

Like, why haven’t you used this? You’re trying to get to the core of an issue, a pain point that somebody is having. You want to be vulnerable, asking questions, and showing that you don’t know things, which is also very difficult for technical people. You want to go in and you want to show them that you’re very capable, and you can solve whatever problem they have. Even if you don’t know what it is, you might just start trying to solve it. Instead, show some vulnerability, show that you don’t know everything, which you don’t, whether or not you’re willing to accept that, and work through that. Don’t explain. It’s very easy, especially as a platform owner, to go to a group of users who are having trouble with your system, and explain to them why they’re doing it wrong. That is a classic mistake that many producers of systems have made.

Don’t minimize. This goes in general, this is across all forms of empathy. If someone had something bad happen to them, don’t tell them, it could have been worse. If somebody is complaining about the build’s taking a half hour, “At least you’re not doing it by hand and taking four hours.” It’s not exactly empathizing or experiencing something from their perspective. Again, don’t solution. Don’t go in and immediately try to solve a problem, before you even have taken the time to understand what the problem is.

Why Do We Build Platforms?

Organizations build platforms to scale. That comes from too many people doing too many things. DevOps was this effort to have people own their own destiny. They became full stack engineering, everything down to sometimes the most minute details about how their software ran and got deployed. Also, that they could move faster and not be impeded by the other teams effectively around them. That works up to a point. Then as you get larger, and you scale out, and the number of concerns that come into play, from security, to audit requirements, to performance, to all sorts of things, it starts to work up into a large amount of cognitive load. What is cognitive load? Cognitive load is actually an area of academic research.

We throw around the term all the time, but it is the study of what the effects are of difficulty learning. If a person has the right makeup of cognitive load, when they’re being presented something new in a learning environment, they’ll be more readily able to absorb it. We’ve extended it into the idea of work. Actually, NASA has an interesting concept that they worked up with, I think the shuttle program, called mental workload, which takes cognitive load and deadlines and environmental factors and all of that, which we experience sometimes, and they call it mental workload. Cognitive load works for us. There are three parts to it. There’s intrinsic cognitive load, which is essentially the problem you are working on. There is germane cognitive load, which is the stuff you need to know to be able to work on the problem. Then there’s extraneous load, which is unrelated to what you’re trying to do.

A quick example of cognitive load is taking a drive to the supermarket. You need to intrinsically figure out the route, do the driving, and get to the supermarket. What’s germane is you need to have a license and know how to operate a car. What’s extraneous is the traffic and potentially detours you need to take around your route, because that’s unrelated to what you’re trying to do and that is extraneous workload. When we get this big pileup of too many people doing too many things across an enterprise, you get all this extraneous load spiking. The overall efficiency of the organization starts to drop. Platforms get scale by capturing more of this extraneous cognitive load into the platform. They capture work, meaning a user doesn’t have to do that work anymore. Or if it’s something we can’t entirely capture, we abstract it and make it simpler. Anything that’s left that we’re unable to take completely away from the user needing to do, we make it simpler to work with.

The Most Effective Way to Build a Platform

What’s the most effective way to build a platform? You want to build your platform as a product. There are some reasons for that, that line up with empathy. A product has customers, customers have choices. That’s a little different from how we’re used to working with things that are internal, even though there’s been plenty of situations where internal customers decided, we don’t want what you’re providing us, we’ll just take our credit card to Amazon and get whatever we need. You have the birth of shadow IT.

If you treat your platform as a product, and you need to make that product the best option, you want it to be that best option, because the other alternative, even if they don’t go off and hand a credit card to someone for an alternative to your platform, it’s just as not do the migration, not adopt what you’re trying to put in front of them. This is bad, because suddenly you’ve built something that is potentially just another layer in the stack of platforms that the company is collecting, because another one has been built. It’s not compelling and solving problems that the users actually need solved. It’s just going to sit out there. It may not even get canceled, it may become just part of the growing spread of tech debt in the company rather than actually solving solutions.

The old approach was very transactional. We would take requests from users through a ticket system, usually. I need feature x, or I need the build system to do y, or something like that. We would take these things and potentially synthesize them into a platform, or we would even take groups of requests and say, you’re asking us to do this work, we need to figure out how to make this much more automated, or we’re not going to survive under the load of requests. That is, unfortunately, the old way of doing things, very low understanding, and very little empathy because of that. There’s this barrier between groups, and it’s ticket systems and requests. There’s very little collaboration. Platform engineering is about building for others, not for yourself.

This is the essential mindset shift of going over to platform engineering, as opposed to systems administration. Sysadmins and even DevOps engineers, and a lot of these, they were responsible for the piece of the system that everybody used, and they were responsible for maintaining it, and changing it on behalf of others. Whereas platform engineering, and a platform team should be building a service, ideally, very much a self-service product for other people to use. That’s a big shift from protecting yourself from work with automation.

The new approach is to create an appealing product. If you’re creating an appealing product, you probably need to know what makes it appealing. If you use empathy and get into your user’s shoes, and see what it is that they need, then you’re going to be a whole lot more successful than firing random stuff off of them based on what you think they need. Seeing from their perspective is like a superpower, if you’re building something that is a product that you want people to adopt. Product-driven product organizations have known this for a long time, they’ve operated in this way. It’s only time for platform teams to start behaving the same way with their internal users. You get happy users which are then satisfied customers. You’re thinking of them as customers that need to be happy, need to be satisfied in order for you to perform well, is like I said, a big mindset shift.

Benefits

There are some big benefits out of this. You’re more efficient with company resources if you’re focused on building what the user needs, what they’ve told you they need. For instance, if I have five features that I’m building, but only two of them are actually useful for our internal customers, that means three of those things I spent money building, but they’re not contributing to anything, they’re just waste, effectively. I’ve just created tech debt. With that being said, if you take five out of five things, and you make those all useful to the engineering teams, you’re going to be making them more effective than if you only built two other things that are useful to them.

Your acceleration is able to grow. If you do the first two things, you’re probably going to get much higher employee satisfaction. A lot of situations with engineers, and a lot of the focus on developer experience has been about satisfaction, employee satisfaction. If you’re working to make things that they need, and see things from their perspective, and eliminate their pain points, of course, they’re going to be happier. This creates a virtuous cycle. If you start with figuring out what the users need, and then building it, they will adopt it. That will make the whole company more efficient and effective. That will make happier users. You will be able to continue doing that. If you just go and build something and expect people to use it, and they don’t adopt it, your cycle just ends. You’re essentially blocking the company from being more effective, more efficient, and getting into this cycle.

Putting Empathy to Use

How do I put empathy to use in building platforms? First, you need to create a culture of empathy. We’re talking about a human emotional system. It’s probably pretty important to put in a cultural aspect to it. You need to start listening. Everybody needs to learn to stop talking for some period when they’re addressing other people, and figure out how to hear what they’re saying, be active listeners, and engage with them as people. Getting to know your co-workers and your customers as people, is pretty important. You’re not going to feel comfortable getting into their shoes, or shadowing them, or figuring out what their life is like, if you can’t identify with them at all as people. The solution used to be, let’s have a drinks night, a happy hour.

I think someone said, some people would be put off by happy hour, so call it snacks and refreshments, or something. Get people together and have them see each other as people. This is really important for establishing work relationships, in general. Things will run more smoothly. In a product sense, it’ll give you the opportunity to talk with them frankly about what they need or don’t need, and get to the bottom of their problems as opposed to just their requests. The way this starts is with using modeling behavior. Anyone can use this kind of approach to co-workers and customers by simply doing it. You do it in front of other people, and that’s how other people learn it’s done. Leadership comes from any level of the organization, it’s not something you need to be a manager in order to demonstrate. You just show a better way of doing things, and people will start following along.

Product management practices. Product companies know that they need to understand their user and what their pain points are, and what they have to solve. Using a lot of these techniques is going to be beneficial when trying to do this for a platform. Surveys are really important because they’re subjective data. When you’re trying to understand someone’s point of view, you need to know how they feel about something. You can’t ask them, or you can’t measure them on their deployment frequency or something like that.

That doesn’t tell you how they feel about the system. You need to survey them, and ask them, do you feel like you’re as effective as you could be? That kind of data point is actually surprisingly valuable. I’ve seen instances where organizations did no DORA metrics measurement, did all subjective surveying, and still managed to have their DORA metrics just pop up on their own because they went from deployment every 2 weeks to 20 per day. They did not focus on the DORA metrics, they focused on the subjective experience of the developers and what their pain points were, and what needed to be solved for. Focus groups. You could use them in your platform team. Bring together your best developers or the ones who don’t like your platform so much, find out why.

Shadowing, this is just do a day in the life. Work alongside your developers, see how they use your platform, and experience it firsthand. You should be dogfooding, too. If you build a platform but you don’t actually use it, then that’s going to have obvious downstream impacts on usability. If you don’t use it, then why should they? Roadmaps, they’re really important to communicate that you’ve heard the user. If your stuff is on a roadmap, then you know that your needs are being considered and might actually be met. Whereas if your needs are not on a roadmap, and everyone looks at the roadmap and scratches their head and say, where did this come from? That shows a pretty big lack of empathy.

If you’ve ever been in a community for gaming, a hobby, or something like that, you’ve used something from a company, and the community has asked, “We have this particular pain point, can you fix it?” You can tell a lot about a company of how they answer that, and what they do about it. The ones that empathize with the users will at least say, we’ll try to work on this. Others will say, out of hand, like, we don’t care. We’re after new users that are maybe not you. You can’t really afford to do that with an internal platform, you need to work much more closely with your users. Then iterations and feedback. If you are building a product, you don’t want to sit on it for a few months, and then put it in front of people and find out they don’t like it, and that you have a whole lot more work to do. Consistently putting things in front of your customer, getting feedback, figuring out if you’re aligned, effectively working agile is the way to go in order to achieve empathy integrated with your process.

The DevEx framework gives you a really nice way to go after what’s important and ask the right questions about what your platform could be solving, or what kind of pains that your users are having that a platform could solve. Because all of these feed into each other in one way or another. If the feedback loops are not as tight because the builds are taking too long, then fixing the builds, period, the amount of time it takes will help them stay in a flow state for longer, because they won’t have to wait for feedback from the build. If you abstract away a lot of the deployment options for working with AWS by hiding a lot of the complexity and reducing the number of types of deployments they can do, you reduce the cognitive load, and get them working faster.

There’s a reason flow state is at the top because the longer you’re in the flow state, the more you’re going to get done, and the more you’re going to do for the company. Also, consider cross pollinating teams. In the open spaces, one of the topics was software engineering versus platform engineering. It’s like, it really shouldn’t be an us versus them type thing. You want software engineers, if at all possible, working on the platform. I think one of the topics was also, how do you get from software engineering to platform engineering? My argument is, any organization should be really happy to have software engineers on the platform engineering team, because that gives them the diversity of viewpoints to see, are we building the right thing? Are we satisfying our customers if we actually have customers on the team? At the same time, the platform engineers would do well to go out and actually work on their teams, their customer teams, and see what the day in the life is for a developer.

Examples in Practice

I’m going to talk through a few examples in practice over the last 10, 15 years of doing consulting with platforms. Before we get too specific, I’ll ask a question, how many people have used an API or a CLI or a system that they really liked, and was really happy with how it was implemented for them as a user? How many people have used something that was really terrible that really seemed like, do they even use this thing? There’s a good example of platforms created without empathy when you think of like, did they even try to use this? Or did they just say, we need to do something, we need to provide them some interface, but we’re not going to use it. Netflix has a CI/CD tool that they built called Spinnaker, that they published open source back in 2016 now.

The little consulting company that I was in, got involved towards the end of the release in order to make it actually usable, because we’d had a lot of experience up to that point, implementing Asgard, which was the predecessor or maybe even older to Spinnaker. It was not particularly friendly to set up for use. A lot of the Netflix stack was made for Netflix to use. A lot of people tried to adopt it, and it wasn’t that easy to get into as an ecosystem. Knowing this, we offered to come in and help with the OSS release, and make it more accessible to more people because Spinnaker was going to be wildly more complex compared to Asgard, or previous tools.

There was a fleet of microservices that you had to bring up, configure, figure out how to run, and just experimenting with it was going to be really difficult. We stepped in, and the work we did was not outrageously difficult or anything, it was mostly creating a metapackage in Debian, so you just did one install. You pulled it all down, you had a little bit of configuration to do. Then you had an experimental Spinnaker that you could work with. The Google team went and really productionized this eventually by writing a full operator for Spinnaker on Kubernetes. At the launch, there was no concept of what it was like for a team that wanted to use this, how they would even deploy it.

Part of that is because Netflix never deploy Spinnaker, they just upgrade Spinnaker in place. They just deploy and deploy. The thing, it’s its own dogfooding. For an open source community, it didn’t represent a very good experience. This is an example of self-advocacy because we knew what it was like. We were end users of Netflix’s open source products. We knew what it was like to just take their stuff and try and work with it as they produce it. We stepped in, and we tried to help. This is an awesome way for platform teams to work with their own customers, take in an inner source model, and allow participation in the platform to make it better. The people who are going to provide the best experience for users are the users themselves. You just need a way to let go and figure out how to incorporate user contributions into your system.

This was a large cloud migration. When I say large, it was like hundreds of apps and dozens to 100 teams just doing the migration portion of it. This wasn’t the app teams even. There was a platform built for these migration teams to use, and moving all of these apps over. It was expected to be cloud native. The customer wanted a completely immutable infrastructure deployment. Terraform was the de facto standard. They wanted immutable instance images. That’s all well and good, but the platform they provided for all these engineering teams to do the migration, it fell short. It didn’t take one of the most common use cases, which is like a Java Tomcat app in an enterprise, and they didn’t provide a standardized build of that.

Every team had to go and figure out how to get Tomcat out of the internal company marketplace vendor thing and build an image, and figure out how to have that image boot and take in parameters from the cloud launch environment and configure it. Every one of these teams had to figure it out from scratch. That resulted in a program that took months for even the first app to get across the line, and enormous amounts of money wasted because they did not put the effort where it needed to be in the platform. They displayed very low customer empathy. They basically said, you’re doing it wrong. It was a classic situation of a platform team that really, they’re under their own stresses, but at the same time didn’t consider how much pain they were causing, therefore, how much cost it was resulting in.

This example is from my wife. She is an avid knitter. A couple of years ago, she told me about a couple of things that happened in the knitting community. A couple of tech bros bought knitting.com years ago, and they displayed very little empathy for their potential customer base, kind of belittling them. They had very little diversity. Product companies know that if they want to understand a customer, they need some people like their customer on the team. One of the guys had a 7-year-old daughter that had gotten into some knitting, and so therefore they thought, buy this knitting.com domain, sounds really cool. They proceeded to really not understand the demographic at all.

The domain is still around, I just have no idea whether or not their business plan panned out. They actually had a podcast called the most transparent podcast on the internet, that they ended up taking down after one episode, after they insulted their customer base by quite a bit. Also, in knitting, it was interesting, they came in, they thought they had this big market to dominate. There is an existing platform out there for community and patterns that get sold, called Ravelry. Ravelry, they did a reskin of their site, they made it less accessible, to the point where they had flashing lights on parts of the site. To this day, years later, they’ve still not backed down on these inaccessible features. When you think of the demographic involved with knitting, you want it to be accessible. They showed incredibly little empathy for their customers.

Key Takeaways

You need to see people and not problems. That’s a huge part of empathy is if you can identify with the person first, there are a range of options in front of you. If you focus in solutioning a specific problem, you’re narrowing your possible set of solutions unnecessarily. If you take the time to listen, take the time to see people and the variety of issues that they face, you’re going to end up with much better results. Listen and try to understand goes with that. If you don’t solution first, you’re going to find out a lot more a lot faster.

What often happens with technical people is you go in, somebody says something, you cut them off, and you start solutioning. They say, no, that’s not it. They start saying more and telling you more, you cut them off again, you start solutioning. The whole process ends up taking longer than if you just let them talk and tell you what they needed to tell you. Then you started identifying what might be done as opposed to running straight into the solution.

Remember who you are building for. You’re not building for yourself, if you’re building a platform team, and you’re building as a product, you’re building for customers. If you can keep that in mind, and start figuring out how to address that. A lot of the stuff that we’re talking about is all actionable on an individual level. You can start doing these product management type things or other stuff, but if you work on a platform team, you can start tomorrow, learning to listen and not immediately solutioning. There’s a bunch of things here that you can do at work. Build a product and make it appealing, and not appealing to you. Make it appealing to a customer. That will require you to get in your customer’s head and figure out, is this really what they need, is this appealing?

Product management methods. There’s a whole universe of product management that, unfortunately, internal tech teams are usually not aware of at all. One of the best things you could do is hire a product manager. There’s actually a whole segment of product managers that have specialized on internal platforms. They’re out there. There are people who could help you almost immediately if you look for them in figuring out this problem of managing your platform as a product. It’s a new space. I’m not saying there’s a huge number of these people out there. When certain companies like Netflix decided that this was something they needed to do, that people were already there to hire. This is going back a couple of years already. There are people out there who are ready to exercise product management practices in service of internal platforms.

Example in Practice

I did have another positive story that happened with a team that we helped. It was an e-commerce arm of a hard goods company. They had a complex Kubernetes environment, and they wanted to automate a lot of the deployment flow with Spinnaker. With that program, we sat down with them for about 10 weeks, we did some discovery. Then we had someone colocated with them for a significant amount of that time, understanding what they needed, doing fast feedback, and demoing regularly.

Then in a fairly short period of time, delivering the initial pilot system that they needed. As a consultant, we often build things for people, and then we hand it off, we try and hold it steadily. Sometimes those things fall over as soon as you walk away. I was very happy to find a year later when we went to the Spinnaker conference, they showed up, and they talked about how they’d adopted this system, migrated all of their flows to it. They had even worked on extending it. That was a really great alignment that happened.

Questions and Answers

Bryant: Do you have any advice for empathizing up and down in the business, because I’ve struggled with when I was an IC empathizing with how managers think, how leaders think, and vice versa? I’d love to hear your take on how you’ve liked the empathy for folks in the business that may be above or below the hierarchy?

Stenglein: My default answer is usually that it needs to come from the higher levels first. It’s very difficult for empathy to happen upwards if it’s not happening at all downwards. If you’re in an executive position, and you show no empathy, then people aren’t going to have any empathy for you. Executives have a different set of concerns that they have to manage. They are responsible for the health of the business, which ultimately results in the health of the employees’ employment. It’s very difficult for them to communicate that, and sometimes executives communicate instead, they’re only concerned about the health of the business. It’s not even a secondary or tertiary concern that employees will still be employed.

The ability of the executives to first take this kind of empathy into account is important, but you can also over-empathize. That’s another thing to do. If you’re running a platform as a product, or you’re running a whole company, you’ve got to be careful about over-empathizing relative to your position. If you over-empathize with every single customer that comes through with every single request, you’re not going to gain any ability to prioritize or anything. If you over-empathize with all of your employees, and you don’t do what’s necessary for the company, in hard times you could end up with a place for no one to work at, as opposed to, unfortunately, having to let people go. It often starts with modeling behavior from the executive on down, that will then make it easier for everyone to empathize.

There’s another interesting, related thing, is that, there was a study that I looked up, it said that customers of e-commerce sites that felt that the company had empathy for them, were more willing to excuse outages. You could think that’d be very useful as a platform team. If you develop enough empathy bank with your users, that when you do have your outage, and you will, that they’ll let it slide. Whereas if you have an antagonistic relationship with your users, and you have an outage, you’re going to be out of a job.

Participant 1: How do you get those requirements and build empathy with the customers when what you’re needing to build isn’t a product request from them. Maybe you need to do something, you need to make a change that’s solving a different concern that isn’t initiated by those developers. You’re going to build something that they have to use, but they didn’t ask you to. It’s not a priority to them that they may not care about.

Stenglein: You got to make it appealing unless you’re going to get into the kind of like antagonistic IT scenario. Again, do you have any goodwill in the bank, and can you put the users through a certain number of forced migrations to things? That’s only going to go so far. At some point, they need to have something that’s in their favor. With these kinds of things, you may need to look at it as you’re not doing it so that they have to.

The whole company needs to do this. It’s not usually the platform team going off and dreaming up new ways to make everyone’s lives painful. It’s like, the company has certain priorities that they need to make, and the platform team needs to do certain things to fulfill it. You’ve got to tie it to the long-term story of why this is better for everyone, including them. You got to tie the story together and make it valuable to them directly or indirectly.

Participant 2: [inaudible 00:40:51]

Stenglein: I think it has a lot to do with relationships and vulnerability, and who starts the process. There’s a certain amount of strength needed to be vulnerable. If you can demonstrate that with the modeling behavior, and start moving. It’s like any change movement. It’s showing the leadership from wherever you are, that this thing is effective, and it’s a great way to work, and keep pushing it.

It’s not always going to work. If the organization around you is anti-empathy, if it’s on the left end of the Westrum scale, you’re never going to get empathy to work in a pathological organization. You can start to get it to work in a bureaucratic one. Of course, you want a generative organization. There’s a certain level of how appropriate it is for your context.

Participant 3: Suppose you’re building a new application, and you have a good [inaudible 00:42:29] so you’re implementing new business requirements. In those scenarios, how can you actually be in the shoes of the person who may use the system, managing things in that new environment altogether? How do you feel the empathy for the users of the system because it’s a new thing altogether.

Stenglein: It comes down to asking them for one thing. Even though they’re new business requirements. They’re new, and they’re a change. You can ask them simply, how do you feel about this change? What is this going to mean to you? That’s frequently a thing you do in technology, like we have some new detailed requirement for remediating patches of a certain level within 24 hours, are you going to be able to do that?

You do a deployment every three months, what’s that going to be like? I feel like you’re asking, what do we do with external requirements? You still need to ask. Because even though they’re external requirements, you’re the one implementing them. You want to do it in such a way that they’ll want to do it. If you just shove it at them and say, new requirements, you’d better migrate and upgrade. It’s going to be a very different experience than if you say, we’ve got some new requirements, how are you feeling about this? How are we going to work together to make sure that we actually all fulfill this?

Bryant: Where do you draw the line between too much empathy? The case study example here was, when some users have picked up bad practices, you listen to them, and you’re actually encoding those bad practices into your platform. How much is too much empathy?

Stenglein: If you’re running your platform as a product, you need to also think about it as a business. Businesses should have a focus. That’s why if you’re running a platform as a product, and you’re using empathy, you’re also not able to do everything everybody wants, because your product will just become this giant mess. You need a way to prioritize while having empathy.

That’s what product companies usually explain. You go to them, you say, I want a feature, if it’s an enterprise thing, or a game, or whatever, and they say, “If enough people want it, we can consider it.” Or they can say, “We make iPhones, we’re not going to start making marshmallows too.” It comes down to having the business side of what it means to operate a platform as a product.

Participant 4: I was talking about empathy really, it’s a challenging thing, because it depends what you mean by it. It’s emotionally charged. If you’re going to actually empathize, is it cognitive empathy, is it emotional? I’ve had a charged type. I’d like what do you mean by empathy a little bit more, because, obviously, that can mean lots of things to lots of people, where in product it’s usually about pains, what are the things they’re struggling with, what can they get through, as opposed to trying to see their perspective all the time? If you truly get it, and they usually get emotionally upset that they are? How do you find that balance? Because I find that sometimes empathy is a charged org.

Stenglein: This comes down to sometimes emotional contagion, that’s called, where you start experiencing the emotions of someone else. That’s important for human connection to other people. The cognitive empathy, the actual modeling of their perspective, is, you want to establish the human relationship, but you also want to do the work to understand their actual perspective, which is what the emotional side doesn’t give you. Of course, you can go way too overboard with empathizing with people.

You need to keep your perspective separate from what you’re doing, which is modeling their perspective. Just because you’re modeling sitting in their shoes, doesn’t mean you’re actually standing in them. I’ve seen plenty of people, especially in management situations, they start over-empathizing with people. It always comes back to the CEO thing, like CEO can’t over-empathize with employees. He’s got a different set of responsibilities.

See more presentations with transcripts

Article originally posted on InfoQ. Visit InfoQ

Vaadin, an open-source web application development platform for Java developers, released version 24.4 in June 2024. The release aims to improve and simplify the developer experience by unifying the Hilla framework with the Vaadin platform, introducing the Vaadin Copilot, and several enhancements to the design system.

One of the most significant changes in this release is the introduction of Vaadin Copilot, a handy AI-powered development tool. Vaadin Copilot allows users to drag and drop components, reorganize layouts, and edit labels and captions while developing the application. Vaadin Copilot is project-aware and seamlessly integrated with supported IDEs, instantly updating the source code as the changes are made in the Vaadin Copilot. The outline view lets users understand the overall UI structure and quickly navigate to specific components.

One of Vaadin Copilot’s key features is its capability to use generative AI to generate and modify UI components based on prompts. The tool offers users a convenient way to change the theme of individual components and the entire application by adjusting the properties in the Theme Editor without having to edit the underlying CSS. Vaadin Copilot is only available for views built in Hilla/React.

Starting with the 24.4.0 release, Vaadin BOM and Vaadin Spring Boot starter include the Hilla framework, allowing users to build hybrid applications containing Flow and Hilla views. It is now possible to wrap React components as Flow components via an adapter Web Component. This integration allows the React components to be used in Java applications, modify the component’s state, and send events back and forth between client and server-side.

Aligning with the theme of a unified Vaadin platform, it is possible to embed Flow components into Hilla/React views by implementing the WebComponentExporter class. The resulting web component can be imported into a Hilla view. Follow the guide for further code examples and details.

Vaadin Flow defaults to React Router, which is configured via the property reactEnable. This can be set in the Vaadin maven plugin or through Java system properties. When set to true, it includes core React dependencies and other React components. If set to false, Vaadin Router is used, React dependencies are excluded, and Lit dependencies are added. See the full list of properties for details.

Other noteworthy changes include the introduction of the file-based router in Hilla. The Hilla file router is built on top of the React Router. It maps the routes defined in files in the src/main/frontend/views directory and subdirectories. The Hilla File router provides a utility function, createMenuItems, to populate menu items from routes in the React main layout.

This release also brings several improvements to the design components, such as support for read-only and required states in the Checkbox, the collapsing of menu items in the Menu Bar from the left end of the bar, and support for query parameters in the Side Navigation.

See the release notes and blog for the complete list of features in Vaadin 24.4.0. In addition to these resources, the Vaadin team held a live-stream session and a community town hall on the 24.4.0 release.

To learn more about Vaadin, refer to their official docs.

Article originally posted on InfoQ. Visit InfoQ

Posted on mongodb google news. Visit mongodb google news

A lawsuit was filed on behalf of investors in MongoDB, Inc. (NASDAQ: MDB) shares over alleged securities laws violations.

An investor, who purchased shares of MongoDB, Inc. (NASDAQ: MDB), filed a lawsuit over alleged violations of Federal Securities Laws by MongoDB, Inc. in connection with certain allegedly false and misleading statements made between August 31, 2023 and May 30, 2024.

Investors who purchased shares of MongoDB, Inc. (NASDAQ: MDB) have certain options and for certain investors are short and strict deadlines running. Deadline: September 9, 2024. NASDAQ: MDB investors should contact the Shareholders Foundation at mail@shareholdersfoundation.com or call +1(858) 779 – 1554.

New York based MongoDB, Inc., together with its subsidiaries, provides general purpose database platform worldwide.

MongoDB, Inc. reported that its Total Revenue rose from over $1.28 billion for the 12 months period that ended on January 31, 2023, to over $1.68 billion for the 12 months period that ended on January 31, 2024, and that its Net Loss over those respective time periods declined from $345.39 million to $176.6 million.

On March 7, 2024, MongoDB, Inc. allegedly announced that due to the sales restructuring, it experienced an annual decrease of approximately $40 million in multiyear license revenue, anticipated near zero revenue from unused Atlas commitments (one of its core offerings) in fiscal year 2025, and provided a disappointing revenue growth forecast that trailed that of the prior year.

Then, on May 30, 2024, MongoDB, Inc. again announced significantly reduced growth expectations, this time cutting fiscal year 2025 growth projections further, again attributing the losses to the sales force restructuring.

Shares of MongoDB, Inc. (NASDAQ: MDB) declined from $459.78 per share on February 20, 2024, to $217.95 per share on June 13, 2024.

The plaintiff alleges on behalf of purchasers of MongoDB, Inc. (NASDAQ: MDB) common shares between August 31, 2023 and May 30, 2024, that the defendants violated Federal Securities Laws. More specifically, the plaintiff claims that between August 31, 2023 and May 30, 2024, the Defendants made materially false and misleading statements and engaged in a scheme to deceive the market and a course of conduct that artificially inflated the price of MongoDB’s common stock and operated as a fraud or deceit on purchasers of MongoDB, Inc. (NASDAQ: MDB) common shares between August 31, 2023 and May 30, 2024 by materially misleading the investing public.

Those who purchased shares of MongoDB, Inc. (NASDAQ: MDB) have certain options and should contact the Shareholders Foundation.

Contact:
Michael Daniels
Shareholders Foundation, Inc.
3111 Camino Del Rio North
Suite 423
San Diego, CA 92108
Tel: +1-(858)-779-1554
E-Mail: mail@shareholdersfoundation.com

About Shareholders Foundation, Inc.
The Shareholders Foundation, Inc. is a professional portfolio monitoring and settlement claim filing service, and an investor advocacy group, which does research related to shareholder issues and informs investors of securities lawsuits, settlements, judgments, and other legal related news to the stock/financial market. Shareholders Foundation, Inc. is in contact with a large number of shareholders and offers help, support, and assistance for every shareholder. The Shareholders Foundation, Inc. is not a law firm. Referenced cases, investigations, and/or settlements are not filed/initiated/reached and/or are not related to Shareholders Foundation. The information is provided as a public service. It is not intended as legal advice and should not be relied upon.

This release was published on openPR.

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

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB – Get Free Report)’s stock price reached a new 52-week low during trading on Monday . The company traded as low as $212.00 and last traded at $212.00, with a volume of 13489 shares changing hands. The stock had previously closed at $232.70.

Analyst Ratings Changes

Several brokerages have recently issued reports on MDB. Scotiabank reduced their target price on MongoDB from $385.00 to $250.00 and set a “sector perform” rating on the stock in a report on Monday, June 3rd. KeyCorp reduced their price objective on MongoDB from $490.00 to $440.00 and set an “overweight” rating on the stock in a research note on Thursday, April 18th. Barclays reduced their price objective on MongoDB from $458.00 to $290.00 and set an “overweight” rating on the stock in a research note on Friday, May 31st. Monness Crespi & Hardt raised MongoDB to a “hold” rating in a research note on Tuesday, May 28th. Finally, Needham & Company LLC reissued a “buy” rating and set a $290.00 price objective on shares of MongoDB in a research note on Thursday, June 13th. One research analyst has rated the stock with a sell rating, five have issued a hold rating, nineteen have given a buy rating and one has given a strong buy rating to the company. Based on data from MarketBeat, MongoDB has an average rating of “Moderate Buy” and an average price target of $355.74.

Get Our Latest Research Report on MongoDB

MongoDB Price Performance

The stock has a market capitalization of $15.82 billion, a PE ratio of -82.81 and a beta of 1.13. The stock’s 50 day moving average is $249.70 and its two-hundred day moving average is $340.31. The company has a debt-to-equity ratio of 0.90, a quick ratio of 4.93 and a current ratio of 4.93.

MongoDB (NASDAQ:MDB – Get Free Report) last released its earnings results on Thursday, May 30th. The company reported ($0.80) earnings per share for the quarter, hitting analysts’ consensus estimates of ($0.80). MongoDB had a negative net margin of 11.50% and a negative return on equity of 14.88%. The business had revenue of $450.56 million for the quarter, compared to analyst estimates of $438.44 million. On average, equities analysts anticipate that MongoDB, Inc. will post -2.67 EPS for the current fiscal year.

Insider Transactions at MongoDB

In other MongoDB news, CFO Michael Lawrence Gordon sold 5,000 shares of MongoDB stock in a transaction dated Tuesday, July 9th. The shares were sold at an average price of $252.23, for a total transaction of $1,261,150.00. Following the completion of the sale, the chief financial officer now directly owns 81,942 shares in the company, valued at $20,668,230.66. The sale was disclosed in a document filed with the SEC, which is available through this hyperlink. In other news, CFO Michael Lawrence Gordon sold 5,000 shares of MongoDB stock in a transaction on Tuesday, July 9th. The stock was sold at an average price of $252.23, for a total value of $1,261,150.00. Following the completion of the sale, the chief financial officer now directly owns 81,942 shares of the company’s stock, valued at $20,668,230.66. The sale was disclosed in a legal filing with the Securities & Exchange Commission, which is available at this link. Also, Director John Dennis Mcmahon sold 10,000 shares of the firm’s stock in a transaction dated Monday, June 24th. The shares were sold at an average price of $228.00, for a total value of $2,280,000.00. Following the transaction, the director now owns 20,020 shares of the company’s stock, valued at $4,564,560. The disclosure for this sale can be found here. In the last ninety days, insiders sold 28,179 shares of company stock worth $6,906,989. 3.60% of the stock is currently owned by company insiders.

Institutional Investors Weigh In On MongoDB

A number of hedge funds have recently bought and sold shares of the stock. Norges Bank acquired a new position in shares of MongoDB in the 4th quarter valued at $326,237,000. Jennison Associates LLC boosted its holdings in shares of MongoDB by 14.3% in the 1st quarter. Jennison Associates LLC now owns 4,408,424 shares of the company’s stock valued at $1,581,037,000 after buying an additional 551,567 shares in the last quarter. Swedbank AB boosted its stake in MongoDB by 156.3% during the 2nd quarter. Swedbank AB now owns 656,993 shares of the company’s stock worth $164,222,000 after purchasing an additional 400,705 shares during the period. Axiom Investors LLC DE acquired a new stake in MongoDB during the 4th quarter worth $153,990,000. Finally, Clearbridge Investments LLC boosted its stake in MongoDB by 109.0% during the 1st quarter. Clearbridge Investments LLC now owns 445,084 shares of the company’s stock worth $159,625,000 after purchasing an additional 232,101 shares during the period. Institutional investors and hedge funds own 89.29% of the company’s stock.

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.

Featured Articles

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

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

In other recent news, MongoDB, Inc. announced the results of its Annual Meeting of Stockholders, confirming the election of three Class I directors and the approval of executive compensation in a non-binding advisory vote. The stockholders also ratified the appointment of PricewaterhouseCoopers LLP as MongoDB’s independent registered public accounting firm for the fiscal year ending January 31, 2025. These developments demonstrate shareholder confidence in MongoDB’s governance and financial oversight.

In the realm of analyst ratings, KeyBanc maintained its Overweight rating on MongoDB with a steady price target of $278.00, highlighting MongoDB’s leading position in the NoSQL database market. Scotiabank revised its price target for MongoDB to $250, maintaining a “Sector Perform” rating, and advised investors to adopt a “wait and see” approach due to a slower operational start and more moderate activity from end-users.

Citi also adjusted its outlook on MongoDB shares, reducing the price target to $350 while maintaining a Buy rating, citing weaker consumption trends and the smallest revenue beat in the company’s history. Despite these setbacks, Citi remains optimistic about MongoDB’s potential for growth in the second half of the year. Guggenheim, on the other hand, upgraded MongoDB stock from Sell to Neutral, attributing the downgrade in guidance and the company’s performance to temporary go-to-market headwinds rather than broader macroeconomic issues. These are the recent developments in MongoDB’s financial landscape.

In light of MongoDB’s recent dip to a new 52-week low, a closer look at the company’s financial health and market performance is warranted. According to InvestingPro data, MongoDB holds a market capitalization of $15.8 billion and has experienced a revenue growth of 29.15% over the last twelve months as of Q1 2023. Despite not being profitable over the last twelve months, analysts are predicting that the company will turn a profit this year. This optimism is reflected in the company’s price/book multiple of 13.45, which, while high, suggests that investors may be expecting future growth.

Two InvestingPro Tips that stand out in this context are MongoDB’s strong cash position, with liquid assets exceeding short-term obligations, and the expectation of net income growth this year. These factors could be pivotal for investors considering whether MongoDB’s current low stock price presents a buying opportunity. It’s also worth noting that MongoDB does not pay dividends, which may influence the investment strategy of income-focused shareholders. For more in-depth analysis, there are an additional 20 InvestingPro Tips available for MongoDB on the InvestingPro platform.

While the tech sector remains volatile, MongoDB’s financial resilience and the anticipation of profitability may offer some solace to investors. The company’s next earnings date is set for August 30, 2024, which will be a critical moment for assessing MongoDB’s progress towards its growth objectives.

This article was generated with the support of AI and reviewed by an editor. For more information see our T&C.

Posted on mongodb google news. Visit mongodb google news

MongoDB, Inc. (NASDAQ:MDB – Get Free Report)’s stock price reached a new 52-week low during trading on Monday . The company traded as low as $212.00 and last traded at $212.00, with a volume of 13489 shares traded. The stock had previously closed at $232.70.

Wall Street Analysts Forecast Growth

Several research firms have issued reports on MDB. Guggenheim upgraded shares of MongoDB from a “sell” rating to a “neutral” rating in a research note on Monday, June 3rd. Mizuho dropped their target price on shares of MongoDB from $380.00 to $250.00 and set a “neutral” rating for the company in a report on Friday, May 31st. Stifel Nicolaus dropped their price objective on shares of MongoDB from $435.00 to $300.00 and set a “buy” rating for the company in a research note on Friday, May 31st. Oppenheimer lowered their target price on shares of MongoDB from $480.00 to $300.00 and set an “outperform” rating for the company in a research note on Friday, May 31st. Finally, Barclays lowered their target price on shares of MongoDB from $458.00 to $290.00 and set an “overweight” rating for the company in a research note on Friday, May 31st. One research analyst has rated the stock with a sell rating, five have given a hold rating, nineteen have assigned a buy rating and one has given a strong buy rating to the company’s stock. According to MarketBeat.com, the stock presently has an average rating of “Moderate Buy” and an average price target of $355.74.

View Our Latest Analysis on MDB

MongoDB Trading Down 4.8 %

The company has a current ratio of 4.93, a quick ratio of 4.93 and a debt-to-equity ratio of 0.90. The firm has a market capitalization of $16.25 billion, a P/E ratio of -78.84 and a beta of 1.13. The stock has a 50 day simple moving average of $249.70 and a 200-day simple moving average of $340.31.

MongoDB (NASDAQ:MDB – Get Free Report) last issued its quarterly earnings data on Thursday, May 30th. The company reported ($0.80) earnings per share for the quarter, hitting analysts’ consensus estimates of ($0.80). The firm had revenue of $450.56 million during the quarter, compared to analysts’ expectations of $438.44 million. MongoDB had a negative return on equity of 14.88% and a negative net margin of 11.50%. On average, equities research analysts forecast that MongoDB, Inc. will post -2.67 EPS for the current fiscal year.

Insider Activity at MongoDB

In related news, CFO Michael Lawrence Gordon sold 5,000 shares of the business’s stock in a transaction dated Tuesday, July 9th. The stock was sold at an average price of $252.23, for a total value of $1,261,150.00. Following the completion of the sale, the chief financial officer now directly owns 81,942 shares of the company’s stock, valued at $20,668,230.66. The sale was disclosed in a filing with the SEC, which can be accessed through this link. In other news, CFO Michael Lawrence Gordon sold 5,000 shares of the stock in a transaction on Tuesday, July 9th. The stock was sold at an average price of $252.23, for a total value of $1,261,150.00. Following the completion of the sale, the chief financial officer now owns 81,942 shares in the company, valued at $20,668,230.66. The transaction was disclosed in a filing with the Securities & Exchange Commission, which is available through the SEC website. Also, CRO Cedric Pech sold 273 shares of the stock in a transaction on Tuesday, July 2nd. The stock was sold at an average price of $265.29, for a total transaction of $72,424.17. Following the transaction, the executive now directly owns 35,719 shares in the company, valued at $9,475,893.51. The disclosure for this sale can be found here. In the last 90 days, insiders have sold 28,179 shares of company stock valued at $6,906,989. 3.60% of the stock is owned by corporate insiders.

Institutional Investors Weigh In On MongoDB

Institutional investors have recently added to or reduced their stakes in the stock. Vanguard Group Inc. increased its position in MongoDB by 1.0% in the 1st quarter. Vanguard Group Inc. now owns 6,910,761 shares of the company’s stock valued at $2,478,475,000 after acquiring an additional 68,348 shares during the period. Jennison Associates LLC boosted its position in MongoDB by 14.3% during the 1st quarter. Jennison Associates LLC now owns 4,408,424 shares of the company’s stock valued at $1,581,037,000 after buying an additional 551,567 shares during the period. Norges Bank purchased a new stake in shares of MongoDB in the 4th quarter worth about $326,237,000. Swedbank AB increased its stake in shares of MongoDB by 156.3% in the 2nd quarter. Swedbank AB now owns 656,993 shares of the company’s stock worth $164,222,000 after acquiring an additional 400,705 shares in the last quarter. Finally, Champlain Investment Partners LLC boosted its holdings in shares of MongoDB by 22.4% during the 1st quarter. Champlain Investment Partners LLC now owns 550,684 shares of the company’s stock valued at $197,497,000 after acquiring an additional 100,725 shares during the last quarter. 89.29% of the stock is owned by institutional investors.

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.

Featured Stories

Before you consider MongoDB, you’ll want to hear this.

MarketBeat keeps track of Wall Street’s top-rated and best performing research analysts and the stocks they recommend to their clients on a daily basis. MarketBeat has identified the five stocks that top analysts are quietly whispering to their clients to buy now before the broader market catches on… and MongoDB wasn’t on the list.

While MongoDB currently has a “Moderate Buy” rating among analysts, top-rated analysts believe these five stocks are better buys.

View The Five Stocks Here

Thinking about investing in Meta, Roblox, or Unity? Click the link to learn what streetwise investors need to know about the metaverse and public markets before making an investment.

Get This Free Report

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

Posted on mongodb google news. Visit mongodb google news

NEW YORK, Aug. 05, 2024 (GLOBE NEWSWIRE) — Levi & Korsinsky, LLP notifies investors in MongoDB, Inc. (“MongoDB” or the “Company”) (NASDAQ: MDB) of a class action securities lawsuit.

CLASS DEFINITION: The lawsuit seeks to recover losses on behalf of MongoDB investors who were adversely affected by alleged securities fraud between August 31, 2023 and May 30, 2024. Follow the link below to get more information and be contacted by a member of our team:

https://zlk.com/pslra-1/mongodb-inc-lawsuit-submission-form?prid=93561&wire=3

MDB investors may also contact Joseph E. Levi, Esq. via email at jlevi@levikorsinsky.com or by telephone at (212) 363-7500.

CASE DETAILS: According to the complaint, on March 7, 2024, MongoDB reported strong Q4 2024 results and then announced lower than expected full-year guidance for 2025. MongoDB attributed it to the Company’s change in its “sales incentive structure” which led to a decrease in revenue related to “unused commitments and multi-year licensing deals.” Following this news, MongoDB’s stock price fell by $28.59 per share to close at $383.42 per share. Later, on May 30, 2024, MongoDB further lowered its guidance for the full year 2025 attributing it to “macro impacting consumption growth.” Analysts commenting on the reduced guidance questioned if changes made to the Company’s marketing strategy “led to change in customer behavior and usage patterns.” Following this news, MongoDB’s stock price fell by $73.94 per share to close at $236.06 per share.

WHAT’S NEXT? If you suffered a loss in MongoDB during the relevant time frame, you have until September 9, 2024 to request that the Court appoint you as lead plaintiff. Your ability to share in any recovery doesn’t require that you serve as a lead plaintiff.

NO COST TO YOU: If you are a class member, you may be entitled to compensation without payment of any out-of-pocket costs or fees. There is no cost or obligation to participate.

WHY LEVI & KORSINSKY: Over the past 20 years, the team at Levi & Korsinsky has secured hundreds of millions of dollars for aggrieved shareholders and built a track record of winning high-stakes cases. Our firm has extensive expertise representing investors in complex securities litigation and a team of over 70 employees to serve our clients. For seven years in a row, Levi & Korsinsky has ranked in ISS Securities Class Action Services’ Top 50 Report as one of the top securities litigation firms in the United States.

CONTACT:
Levi & Korsinsky, LLP
Joseph E. Levi, Esq.
Ed Korsinsky, Esq.
33 Whitehall Street, 17th Floor
New York, NY 10004
jlevi@levikorsinsky.com 
Tel: (212) 363-7500
Fax: (212) 363-7171
www.zlk.com 

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

Posted on mongodb google news. Visit mongodb google news

B. Riley Wealth Advisors Inc. reduced its stake in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 58.4% in the first quarter, according to the company in its most recent Form 13F filing with the Securities and Exchange Commission (SEC). The institutional investor owned 1,109 shares of the company’s stock after selling 1,557 shares during the period. B. Riley Wealth Advisors Inc.’s holdings in MongoDB were worth $384,000 at the end of the most recent reporting period.

Other institutional investors and hedge funds have also bought and sold shares of the company. Vanguard Group Inc. raised its position in shares of MongoDB by 2.9% in the 4th quarter. Vanguard Group Inc. now owns 6,842,413 shares of the company’s stock worth $2,797,521,000 after acquiring an additional 194,148 shares in the last quarter. Atalanta Sosnoff Capital LLC lifted its position in MongoDB by 24.7% during the fourth quarter. Atalanta Sosnoff Capital LLC now owns 54,311 shares of the company’s stock valued at $22,205,000 after buying an additional 10,753 shares during the period. Fiera Capital Corp boosted its holdings in shares of MongoDB by 0.8% during the 4th quarter. Fiera Capital Corp now owns 224,293 shares of the company’s stock valued at $91,702,000 after buying an additional 1,695 shares in the last quarter. Artisan Partners Limited Partnership purchased a new stake in shares of MongoDB in the 4th quarter worth about $10,545,000. Finally, Prudential PLC grew its position in shares of MongoDB by 2.4% in the 4th quarter. Prudential PLC now owns 21,169 shares of the company’s stock worth $8,655,000 after buying an additional 489 shares during the period. 89.29% of the stock is currently owned by hedge funds and other institutional investors.

Analysts Set New Price Targets

Several research firms recently commented on MDB. Wells Fargo & Company dropped their price objective on shares of MongoDB from $450.00 to $300.00 and set an “overweight” rating on the stock in a research note on Friday, May 31st. Oppenheimer dropped their price target on MongoDB from $480.00 to $300.00 and set an “outperform” rating on the stock in a research report on Friday, May 31st. Robert W. Baird reduced their price objective on MongoDB from $450.00 to $305.00 and set an “outperform” rating for the company in a research report on Friday, May 31st. Loop Capital dropped their target price on MongoDB from $415.00 to $315.00 and set a “buy” rating on the stock in a report on Friday, May 31st. Finally, Scotiabank reduced their price target on MongoDB from $385.00 to $250.00 and set a “sector perform” rating for the company in a report on Monday, June 3rd. One equities research analyst has rated the stock with a sell rating, five have given a hold rating, nineteen have given a buy rating and one has given a strong buy rating to the company. According to data from MarketBeat.com, the company presently has an average rating of “Moderate Buy” and a consensus target price of $355.74.

View Our Latest Research Report on MDB

Insider Transactions at MongoDB

In related news, CAO Thomas Bull sold 138 shares of MongoDB stock in a transaction on Tuesday, July 2nd. The shares were sold at an average price of $265.29, for a total transaction of $36,610.02. Following the transaction, the chief accounting officer now owns 17,222 shares in the company, valued at approximately $4,568,824.38. The transaction was disclosed in a filing with the SEC, which can be accessed through this link. In related news, CAO Thomas Bull sold 138 shares of MongoDB stock in a transaction that occurred on Tuesday, July 2nd. The stock was sold at an average price of $265.29, for a total transaction of $36,610.02. Following the sale, the chief accounting officer now owns 17,222 shares of the company’s stock, valued at approximately $4,568,824.38. The sale was disclosed in a filing with the Securities & Exchange Commission, which can be accessed through the SEC website. Also, CFO Michael Lawrence Gordon sold 1,569 shares of the business’s stock in a transaction that occurred on Tuesday, July 2nd. The stock was sold at an average price of $265.29, for a total value of $416,240.01. Following the completion of the transaction, the chief financial officer now directly owns 81,942 shares in the company, valued at $21,738,393.18. The disclosure for this sale can be found here. Insiders sold a total of 28,179 shares of company stock valued at $6,906,989 over the last three months. Corporate insiders own 3.60% of the company’s stock.

MongoDB Trading Down 2.8 %

NASDAQ:MDB opened at $232.70 on Monday. MongoDB, Inc. has a one year low of $214.74 and a one year high of $509.62. The business has a fifty day moving average price of $249.70 and a 200-day moving average price of $340.31. The firm has a market capitalization of $17.07 billion, a price-to-earnings ratio of -82.81 and a beta of 1.13. The company has a debt-to-equity ratio of 0.90, a current ratio of 4.93 and a quick ratio of 4.93.

MongoDB (NASDAQ:MDB – Get Free Report) last released its quarterly earnings results on Thursday, May 30th. The company reported ($0.80) earnings per share (EPS) for the quarter, meeting the consensus estimate of ($0.80). MongoDB had a negative return on equity of 14.88% and a negative net margin of 11.50%. The business had revenue of $450.56 million during the quarter, compared to analyst estimates of $438.44 million. Sell-side analysts forecast that MongoDB, Inc. will post -2.67 EPS for the current year.

About MongoDB

(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.

Read More

Want to see what other hedge funds are holding MDB? Visit HoldingsChannel.com to get the latest 13F filings and insider trades for MongoDB, Inc. (NASDAQ:MDB – Free Report).

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

Netflix, a long-time Java adopter, recently upgraded to Java 21. They are now harnessing new features such as generational ZGC, introduced in JEP 439, and virtual threads, introduced in JEP 444, to improve performance across its extensive microservices fleet. While virtual threads, designed for high-throughput concurrent applications, showed early promise, they also brought unique challenges in real-world scenarios.

In a recent post on the Netflix Tech Blog, the JVM Ecosystem team shared insights from their experience with virtual threads, particularly an issue where services experienced timeouts and hung instances. The issue was related to the interaction of virtual threads with blocking operations and OS thread availability, resulting in a deadlock-like situation in their SpringBoot-based applications.

Netflix engineers observed intermittent timeouts and non-responsive instances in services running on Java 21 with SpringBoot 3 and embedded Tomcat. Despite the JVM instances remaining active, they stopped serving traffic, which was characterized by a significant increase in sockets stuck in a closeWait state. This state occurs when the remote side closes a TCP connection, but the local side has not yet closed its end, leaving the socket in a waiting state. More about this can be found in RFC 793 in the terminology section.

Initial diagnostics suggested that virtual threads were implicated in the issue, although they didn’t appear in traditional thread dumps. Using jcmd Thread.dump_to_file, the team found thousands of “blank” virtual threads, indicating threads created but not yet running. The issue was traced to Tomcat’s request handling, where new virtual threads were created but couldn’t be scheduled due to the unavailability of OS threads.

#119821 "" virtual
#119820 "" virtual
#119823 "" virtual
#120847 "" virtual
#119822 "" virtual
...

The analysis revealed that Tomcat’s virtual thread executor was creating threads for each request, but these threads were stuck waiting for a lock. Specifically, the threads were pinned to OS threads due to blocking operations within synchronized blocks, exacerbated by the limited number of available OS threads in the ForkJoinPool.

The problem resulted from a classic deadlock scenario in which virtual threads could not proceed because the required lock was held by other virtual threads pinned to all available OS threads. This prevented new virtual threads from being scheduled, effectively stalling the application.

To resolve the issue, Netflix’s JVM Ecosystem team used a heap dump to inspect the lock’s state and confirmed that no thread owned it, yet the threads waiting for it were unable to proceed. This was a transient state that should have resolved but was instead causing a deadlock-like situation.

The team identified the root cause and developed a reproducible test case to prevent similar issues in the future. While virtual threads in Java 21 have shown potential for improving performance by reducing overhead, this case highlights the importance of understanding their interaction with existing threading models and locking mechanisms.

Adding to Netflix’s findings, a recent case study on InfoQ also delves into the practical challenges and benefits of virtual threads, particularly in scenarios involving heavy concurrent workloads. This study underscores the need for careful consideration and testing when integrating virtual threads into production systems, as even small architectural details can lead to significant performance impacts.

In addition to virtual threads, Netflix’s adoption of generational ZGC has also played a crucial role in optimizing its systems, as mentioned in one of the recent articles. ZGC, with its ability to maintain low pause times even as heap sizes grow, has significantly improved Netflix’s application performance by reducing garbage collection overhead and enhancing responsiveness. More on generational ZGC can be found in this InfoQ news item.

Netflix also has a robust alert system, leveraging its Atlas Streaming Eval platform, which was vital in identifying and diagnosing these issues. The system, designed for improved real-time monitoring and alerting, enabled the team to catch instances in a problematic state and provided critical data for retroactive analysis.

Despite the challenges, Netflix is optimistic about the future of virtual threads and anticipates further improvements in upcoming Java releases, particularly in addressing the integration challenges with locking primitives. This case study is a valuable example for performance engineers and developers as they explore virtual threads in their applications.