×

Why You Need a Mobile Database – The New Stack

MMS Founder
MMS RSS

Posted on nosqlgooglealerts. Visit nosqlgooglealerts

<meta name="x-tns-categories" content="Data / Storage / Technology / Sponsored / Contributed“><meta name="x-tns-authors" content="“>

Why You Need a Mobile Database – The New Stack

Modal Title

2022-09-30 09:16:04

Why You Need a Mobile Database

contributed,sponsor-couchbase,sponsored,sponsored-post-contributed,



Data

/

Storage

Providing a fast, reliable experience is key to the success of your mobile app. Using a database built for mobile apps is key to achieving it.


Sep 30th, 2022 9:16am by


Featued image for: Why You Need a Mobile Database

Image via Pixabay.

Mobile app usage is increasing worldwide, not only in user volume, but in daily time spent on apps. TechCrunch recently reported that mobile users now spend between four and five hours — roughly a third of waking hours — on smartphone apps daily. And when it comes to which apps they use, there is no shortage of choices. Business of Apps reported that Google Play currently offers around 2.8 million apps and games, and the Apple App Store offers around 4.5 million.

But this huge volume of apps — and the increasing length of time that users are spending on them — means that users can be extremely selective with the apps they choose to engage with. In fact, according to a research study by mobile marketing analytics vendor AppsFlyer, nearly one in every two apps are uninstalled within 30 days, and a study by Andrew Chen found that losing 80% of mobile users is “normal” for all but the most popular apps.

A big reason for the high rate of app abandonment is bad experience, particularly slowness and unreliability. A report by Think Storage Now found that 70% of mobile app users will abandon an app that takes too long to load. And an older but still often cited Compuware study found that 84% of app users will abandon an app if it fails just two times.

These facts help emphasize that the margin of error is small when it comes to keeping users happy and engaged. Providing a fast, reliable experience is key to the success of your mobile app, and using the right database — one built for mobile apps — is key to achieving it.

Database Options for Mobile Apps

You may wonder what we mean by “mobile database.” A database is a database, right?

Not exactly. When it comes to developing a mobile application, whether native, web based or hybrid, you need to choose a database that can provide the speed and reliability your users demand. Let’s examine the options.

Relational vs. NoSQL

A relational database stores data in highly organized tables maintained by a rigid and fixed schema designed for consistency. But relational rigidity comes with a price — app developers must conform their code to the schema, and any required changes to data results in time-consuming schema updates, making app updates challenging.

In contrast, a NoSQL database stores data as JSON documents, eliminating the need for a schema and allowing developers to change the database on demand as app requirements evolve. Additionally, NoSQL databases are distributed, meaning they can be deployed across multiple nodes, providing superior performance and reliability for applications.

In general, because of their distributed nature and data model flexibility, NoSQL databases are ideally suited for mobile apps because of their speed and reliability.

Cloud Database

In a cloud database model, mobile and IoT apps use a database that runs in the cloud.

The cloud database model offers a quick on-ramp to a standardized and distributed infrastructure that provides scale, elasticity and flexibility for mobile apps.

The problem is that the model depends on the internet, which is inherently unreliable. If the internet slows, so do the apps that depend on it. And if the internet goes down, apps stop working altogether, frustrating users and costing business downtime.

Because of internet dependencies, the cloud database model presents challenges in meeting mobile app users’ expectations. When they go into areas with poor network connectivity, such as a subway station, airplane or tunnel, their apps become unreliable at best and useless at worst.

To guarantee a fast and reliable mobile app experience, you need to eliminate internet dependencies.

Embedded Database

Embedded database technology such as SQLite is another option for mobile app development. This is where the database runs within the application installed on the mobile device. By embedding the database in the app itself, you completely remove the need for a network connection while gaining the highest guarantees of speed and availability.

Using an embedded database can be great for apps that are standalone in nature and that have data that rarely changes, but their lack of connectivity presents challenges for multiuser apps, where data changes frequently and must be shared with other users. With an embedded database, developers either have to build in data-sharing capabilities in their embedded apps or do without.

Mobile Database

The mobile database model is a merging of the cloud and embedded database models, combining the best aspects of each into an architecture that powers offline-first apps impervious to internet slowness and outages.

The model consists of a central cloud database and an embedded database running on mobile clients that share data via automatic synchronization — the embedded databases sync data between the cloud database and other embedded devices as it is captured or modified. When a network connection isn’t available, data is stored and processed locally, and when the connection is restored, sync resumes automatically.

Mobile databases also offer a peer-to-peer feature, allowing multiple embedded devices in close proximity to sync data using private area networks such as Bluetooth, enabling collaboration in a disconnected environment.

The mobile database model is able to meet the expectations of mobile app users by providing the fast and reliable experience they demand. Embedded local data processing ensures real-time responsiveness and high availability regardless of internet connectivity, and cloud-to-edge sync ensures that the user experience is always current and consistent.

The Couchbase Mobile Database

Couchbase provides a mobile database that brings the power and flexibility of a cloud NoSQL database to the edge.

The Couchbase mobile stack includes:

  • Couchbase Capella — A fully managed cloud NoSQL Database-as-a-Service (DBaaS) with support for SQL, search, analytics and eventing.
  • Capella App Services — Fully managed services for bidirectional sync, authentication and access control for mobile and edge apps.
  • Couchbase Lite — An embedded mobile database with broad mobile platform support.

A Fortune 500 and one of the world’s largest oilfield services companies, Halliburton uses Couchbase’s mobile database technology to automate various processes and workflows aiming to achieve new business opportunities and efficiencies across well sites and drilling operations. With our unique mobile and data synchronization capabilities, Halliburton can sync data across devices with limited to no internet connectivity, increasing efficiency for field workers by preventing both data duplication and redundancy of efforts.

Test drive Couchbase Capella and App Services for free.

Group
Created with Sketch.

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Presentation: Building and Scaling Developer Environments at Stripe

MMS Founder
MMS Soam Vasani

Article originally posted on InfoQ. Visit InfoQ

Transcript

Vasani: My name is Soam Vasani. I work in the Developer Environments team at Stripe. I’m going to talk about building and scaling developer environments. Stripe is building payments infrastructure for the internet. Millions of businesses worldwide use Stripe to accept payments, do payouts, and manage their business. Last year, more than half of UK adults bought something on Stripe. In terms of engineering, the software powering all of this is built by on the order of thousands of engineers who are also distributed across the world. This is millions of lines of code.

What Do We Aim For in Our Dev Environment?

Something to think about is that Stripe’s software is extremely critical to its users, because we process their payments, everything that we ship is very business critical to them. We ask the question in developer productivity, how does that translate to requirements for our developer tools? One thing we talk about is accuracy. This is in other words, the DevOps idea of shifting left. In other words, it’s much better to find a problem before it hits production than after. If there’s a code change that would break something in production, how likely are we to catch it in general in the software lifecycle, but specifically in the dev environment itself? How well is a potential bug caught in dev, and vice versa? How well do problems caught in dev represent the problems that you would face in production? That’s accuracy. We get a whole lot about fast feedback. This has all kinds of advantages. Of course, having fast feedback means that you go through the iterations of making code changes, testing them faster, and therefore you get faster at shipping features. It also means that, for example, developers stay in their flow state as they are iterating through their code changes. Of course, fast feedback means that you’re faster at fixing problems, so if there’s any breakage or incident, the developer environment shouldn’t be getting in the way of you fixing that. Finally, maybe a less obvious point is that we want our tools to help our users become experts at the software they’re working with. This is both because Stripe is growing, and there are lots of new people, but also, the set of software is quite large, and you might be working on something unfamiliar on any given day. How do the tools help you comprehend better the software that you’re working with? This is the idea of building expertise.

These are some big goals. I want to share a quick story about small beginnings. Way back when Stripe was much smaller, and there wasn’t much of a dev productivity organization, the dev environment consisted of something very low tech. Essentially, there was a set of EC2 instances that people would SSH into. They would find some way to get their code changes in there, start the services that they need, do whatever builds they need to, and test everything manually. These were pretty big instances, so they were shared across a lot of people in the company. We were coordinated using Slack channels. There was a Slack channel per box, and you went to the box number five Slack channel and said, “I want to test the API server. Is anyone else using it?” Someone else said, “No, hold on, wait for it some time,” and so on. It was very low tech. Obviously, Stripe grew out of it very quickly. I just want to emphasize that when you’re small, it’s perfectly good and fine to start very low tech. If it solves the problems that you have, then do it, and then think about building the next things.

Sorbet

I’m going to fast forward a little bit from that story to Sorbet. Stripe uses a lot of Ruby, the majority of Stripe source code is Ruby. In 2019, Stripe open sourced a type checker for Ruby called Sorbet. I’m not going to go into a whole lot of depth on Sorbet because there are other talks about it, go to sorbet.org, and check them out if you’re interested. It’s also open source on GitHub. Since we’re going to talk a bit about dev environments here, the other bits of Sorbet are quite interesting. Sorbet isn’t just a type checker, it also has a server mode. This is a language server that essentially makes editors smart about the Ruby source code that you’re working on. It gives you features like jump to definition, find references, it can even do simple refactorings for you. We’re going to go a little bit into this.

Dev Environment Infrastructure

To recap, we talked a little bit about Stripe, and what we’re looking for abstractly from a dev environment. We looked at Sorbet. Really, what we want to spend the bulk of time talking about is one layer below that, that’s the infrastructure that runs Sorbet editors, tools, other tools that are needed. Essentially, how do we scale up that inner loop of development? I’m going to start this progression with the infrastructure that existed as of about a year ago, and then talk about our evolution through the year. Every developer gets an EC2 instance assigned to them. This instance works in concert with their laptop. We call this EC2 instance a devbox. Roughly speaking, the partitioning is as follows. The laptop contains the source code repo, editor. Of course, the browser and whatever CLIs or tools they might be using to run client tools they might be using. The devbox runs the Sorbet server we just spoke about. It has a full copy of the source code that’s rsynced from the laptop. You can start various backend services on this devbox. It runs a database instance that’s preloaded with some test data. Finally, there is infrastructure to manage all of these. There’s one laptop and one devbox per developer, and there’s infrastructure to hand these out and to manage their lifecycle, and so on.

Laptop + EC2 Instance

Let’s talk with a little bit more detail about how the laptop coordinates with the devbox. The left side is the laptop, the right side is the devbox. Let’s start from the bottom of the picture and go upwards. The source code on a laptop, you do a regular Git clone, and you get your repo, and you start the client side of our tools. This finds the devbox, makes a connection to it, and does an rsync. When devboxes are new, they’re brought up with a copy of source code, so you generally don’t have to rsync a whole lot, just recent changes. On the devbox, there’s a dev service runner, which looks at the source code and runs the services that you’ve configured that you want running. Coming back to the left side, the editor makes changes to the source code. We have a tool continuously watching these files on the laptop side and calling rsync. Again, there’s an rsync. The service runner on the devbox side sees the change to the files and restart services as needed. Perhaps there’s a build in the middle, it depends on the exact languages and frameworks being used. To close the loop, the user can use whatever tools they use to hit the APIs of those backend services. Maybe they’re using a test copy of the Stripe dashboard, and makes API requests over the web into this devbox. Or they may be using something like Postman, which makes HTTP requests, or they’re using some kind of gRPC client, and so on. Of course, the Sorbet server runs on the devbox, and there’s a protocol that the editor can use to talk to the Sorbet server and ask it questions like, where is so and so method defined? Then the Sorbet server sends the response back and the editor can navigate to that spot. That’s a simplified picture of the laptop and devbox coordination.

What Worked Well

That’s our dev environments as of a year or so ago, and largely a lot of that picture has remained working well. Let’s look at what worked well. We talked about accuracy, this idea of how well do devs mimic production. Devboxes are much more accurate in predicting production problems than laptops would be, because the operating system is the same. Also, because there’s all these other frameworks that our services depend on like configuration, feature flags, secrets, and so on. We can make devboxes mimic those systems much more easily than laptops. In terms of feedback speed, this system works pretty well. There’s lots of available CPU and memory, so Sorbet, for example, can consume it when it needs to. The services that need to be run also have, again, lots of CPU and memory available to them, so they can respond quickly and they can restart quickly if they need to. One thing that’s really nice is that these boxes are stateful, so you can, at the end of the day, disconnect your laptop, switch it off, walk away. The next morning when you reconnect, everything is exactly where you left it. The test data is in the same shape. The services that you started are still running, and so on. Finally, these are all isolated from each other, so if I break something horribly on my devbox, it doesn’t affect anybody else’s devbox. That’s great, because you want to be able to work without fear of disrupting something.

What Did Not Work Well

What didn’t work well? If you think about this model of syncing source code, it works really well when there are small changes. Think about what happens when you do a Git checkout to a branch, or worse, you’re working on two branches in the same day, and you’re making changes in both of them so you switch repeatedly between these branches. That triggers the worst case behavior of sync, because you have to sync a whole lot of files across the network to get up and running. Because there’s a File Watcher pointed at the source code, when a big branch is synced to it, that File Watcher notices a lot of code changes, and it restarts a whole lot of services. You take a pretty big interruption if you’re multitasking. Generally people who like to multitask a lot and have three or four branches that they work on every day, these people are pretty unhappy with these interruptions.

Identifying a Goal

What did we do about it? We looked at this problem and said, we do want to keep devboxes. We’re getting a lot out of them, but the usage model is not quite right. The old model was that one developer gets one devbox, they’re long-lived and the developer maintains them. They rsync source code from the laptop. We decided we want to switch to a new model, one that’s much more ephemeral. A devbox is per branch instead of per developer, so a developer can work on as many as they want at the same time. These devboxes, we want them to be short-lived, so they are more tied to the lifecycle of a branch. We wanted to eliminate the idea of rsyncing completely, because as we’ll see in a bit, we can’t just have editors directly edit code on devboxes directly. Essentially, the idea of remote dev. Old model is one devbox per dev, long-lived, rsynced from laptops. The new model is much more ephemeral, tied to branches, and eliminates syncing.

Towards Per-Branch, Ephemeral, Remote

That’s a pretty big complex change. How do we get there? This is a problem that any infrastructure software team faces when they have a big platform that lots of people are already using. It’s one thing to come up with ambitious goals, but it’s another to be able to iterate on them and deliver value, while you’re making progress towards those ambitious goals, so we needed a concrete roadmap.

1 of 4: Multiple Devboxes per Developer

I’m going to talk a little bit about how we divided this plan into four steps, and how each of those delivered a little bit of value to users, and how we finally ended up with remote dev. The first one is to simply replicate the picture and allow developers to have more than one devbox. This isn’t a big change in the usage model, you still have a long-lived devbox. It isn’t per branch. The user has to decide which devbox they’ll use for which branch. In fact, they have multiple copies, multiple working trees of source code on their laptop, because rsync cares about things like timestamps and stuff on the laptop, so you have a separate checkout. Once you get this set up correctly, it’s a bit tricky, but you can have two editor windows, you can simply command tab between them, and you have two concurrent dev experiences. This was a pretty good win. What it did for our long term goal was that it broke that one is to one constraint between developers and devboxes. We had to change the routing things here and there. There’s infrastructure things that we had to change to make this work. It shipped. It works. It’s used by the power users of devboxes within Stripe.

2 of 4: Preview Devboxes

Next, we wanted to break that constraint that devboxes must be tied to laptops. Recall that we’re trying to go towards this goal where editors running on the laptop can directly edit code on devboxes. We want there to be a way for a devbox to exist without a laptop. One really valuable feature that we built is the ability to build a devbox that follows a pull request. We call these preview devboxes, and we’ve integrated them into the pull request flow. When you open the pull request, to some frontend change to the dashboard, you can make a comment that triggers a webhook. This triggers our DevOps infrastructure to do a Git pull of that branch in the pull request. That’s the bottom of the picture here. The rest of the infrastructure is the same. The service runner looks at the source code. It runs the services you’ve requested. Users can use their browser, other clients to talk to those services. Similarly, as the user pushes changes to that branch on GitHub, we use webhooks from GitHub to call the devbox infrastructure. That causes the devbox to go pull a new branch. Essentially, this preview always follows the latest state of the pull request. A reviewer can use this devbox to look at the services as they would be after that pull request is merged. There’s a couple of nice advantages to this for users. One is of course, they get preview functionality. The other is that they can non-disruptively look at somebody’s code review. It’s pretty common especially in the frontend world for people to check out somebody else’s branch while they’re reviewing and set it up on their own devbox, click around through the UI, and then say, “Ok, ship it. That interaction looks good to me.” With this, they can avoid disrupting their own workflow. It makes reviews much smoother, less disruptive, and ultimately faster. That’s preview devboxes.

3 of 4: Stateless Devboxes

The third one is very much an infrastructural thing. There isn’t a whole lot of change in the user visible model here. We realized that if we are going from a world where one developer has one devbox, to a world where one developer might have five devboxes, we would like to do it without multiplying our cost by that many, by whatever number of devbox is our average. We figured that we want to take out the stateful parts of the devbox and put them on a volume, on a persistent EBS Volume in this case. This allows us to switch devboxes off. If you look at this picture, this is when a user is actually using it, and you can simply switch it off, the instance, but keep the EBS Volume. When the user wants to work with this branch again, they simply switch back on and we reattach a volume to that user’s new instance. There’s a bit of tracking of volumes and instances and users here that we need to do. What we gain is the ability to give users much more in terms of devboxes, without essentially spending that much more. The EBS Volume adds some cost, but we can also save money by switching devboxes off on weekends and stuff like that. There’s a good savings here. There isn’t a whole lot of user visible benefit, other than small things like the volume can grow independently of instance size, so if your test dataset grows very large, we can grow the volume without thinking about what exact instance size we need, and all that. That’s stateless devboxes.

4 of 4: Remote Dev

Now we come to the part that gets us to the final step, which is remote development. Recall that in the first picture, we had the source code on both sides, the laptop and the devbox side. We used rsync and file watching to make a copy that was always in sync. Here, the idea is that the editor simply edits the files directly on the devbox. It does that generally by using SSH. There’s support in editors for doing this. VS Code has pretty good remote dev support. It’s a little more complicated than just editing files, because VS Code has extensions. I haven’t drawn the Sorbet server in this picture, but there’s also a Sorbet extension, which is also open source. That extension runs in something called an extension host, which also runs on the devbox. There’s a little more complexity for remote dev than what’s shown here. The general idea is that the source of truth for the source code moves from being on the laptop to being on the devbox. This also means that the box has to be able to actually access Git, which is something we had to solve. That’s remote dev.

To recap, when we have all of this, we get devboxes that are ephemeral, we can switch them off. The state of source code remains on the volume, which means it’s now cost acceptable to give users lots of devboxes. Because we’re not syncing anymore, we don’t have to think about the tricky branch switching problem. We didn’t optimize it, we just eliminated it. You don’t branch switch anymore, you simply spin up a new devbox and you delete the one that you’re done with. On the way we also get people preview devboxes.

Where We Are Right Now

Where are we right now? Multiple devboxes have been in use for a while in Stripe. Because they’re a bit tricky to use, they tend to be used by power users, but those users do use them a lot. There’s a small contingent of frequent users. Preview devboxes are very popular with frontend and full stack teams because that review flow is just more useful when you’re doing frontend code. Stateless devboxes are shipped and in use. Again, there’s not a whole lot of user facing value, but it allows us to keep our budget within limits. Remote dev, we’re at the early stages of a beta. Everyone’s very excited about them. It hasn’t rolled out completely yet, so we’re still on the multiple preview rsynced devboxes world, but it’s in progress.

What we’re working on Next

I want to talk a bit about what the dev environment team is working on next besides finishing the remote dev and rolling that out. One thing I didn’t cover much is that Stripe also has a shared test environment. This is one environment that the company uses, and that you can deploy software into. It isn’t a dev environment, there’s no inner loop of development. You have to merge a change, use the deploy tooling. There are ad hoc integrations of the dev environment with this test environment, and we’re working on making it much more systematic. The Envoy proxy is used widely throughout Stripe. We’re using the same mechanisms of the service mesh to integrate the dev environment there. We’re also working on helping developers configure the production service mesh, to configure it better by surfacing errors that are more config related in the dev environment itself.

Secondly, we’re working on improving accuracy. We said that devboxes look a lot like the production environment when you compare them to laptops, but they look quite a bit different from the production environment, when you compare it in absolutes. For example, the resource usage is quite different. The available CPU and memory can depend on what else you’re running on the devbox, and so on. We’re working on all these ideas, and on making the compute platform of the dev environment be more production like. The third one is related to Stripe scaling as a company, which is that, in general, we’re thinking much more of the dev environment as a platform to run services on. How do we empower users to make their services run well in that platform? How can they observe how their services are doing on the dev environment, make them more reliable, and so on. We also encountered this problem that there are small teams that want custom their experiences, either for a new language or a framework, and so on, and we can’t always prioritize them. We want to think about what are the extension points of the dev environment, and can a team use those extension points to do just enough work and to build a custom dev experience for their user?

Scaling Dev Environments with Stripe

Finally, I want to zoom out and talk about a process that you can follow to make big changes, to execute on ambitious big roadmaps in the dev tools team. I’ve pasted one of my favorite bits of feedback after shipping something. It says this is a great sign that Stripe is quickly addressing the dev productivity feedback. The process I’d like to recommend is a very simple one. You start by listening to your users. Surveys and user interviews are a good way or a good inexpensive thing to do. You can sample your set of users, send them a simple Google form, and that’s a good start. You can also interview them on a regular cadence. Something that’s much more impactful I’ve found is to actually embed in a team. Find the team that has the most pain in using your tools, either through metrics, or by talking to them, and spend a couple of weeks doing the tasks, doing their day-to-day work using your tools. The lessons you learn from that are invaluable. Next, take those lessons and make ambitious plans. Figure out what are the really big things that you could change. If you had infinite time and resources, what would you do? Make optimistic plans. Then, and this is the crucial part, execute incrementally on those plans. Your users want to see change. It’s just much better to have a regular cadence of small improvements than it is to have a very irregular rare cadence of huge improvements. Listen, learn ambitiously, and execute incrementally.

Questions and Answers

Synodinos: You talked about Sorbet, the open source server. All the work that Stripe is doing with the devbox, is some of that also open source? Are you using some other open source tools to put it together?

Vasani: None of that is open source. Unfortunately, a lot of it ties into other Stripe infrastructure bits, so it’s really hard to extract out and make it open source. I love to attempt that someday, though.

Synodinos: For teams that would like to build similar infrastructures, what tools should they be looking at?

Vasani: I talked about Sorbet. That’s one of the big reasons we have large CPU and memory requirements from these devboxes. I think if you’re not using a language like that, and for example, if these language servers are local to users, you can have different infrastructures for running your backend services. We do actually run both containers and non-containerized services in these machines, and we also talk to stuff outside the machine.

What tools would you use if you wanted to build infra like this? There are some open source tools we’re using. We’re using rsync and Watchman. These are like age old tools. Somebody else has built a modern rsync, which is more configurable. Yes, tools like that, which help you sync files. If you are still in that file syncing model, it makes sense. If you’re on remote dev, and I glossed over this, but VS Code is the editor with really good remote dev support. If you are using other IDEs, they don’t necessarily have the same support. I know that IntelliJ IDEA IDEs are working on this, but it’s still very early for them. You’ll have to make sure your IDE supports whatever infra you build for this.

Synodinos: You also talked about incremental execution. Not necessarily all attendees work in organizations that have the size of an engineering team, as big as Stripe’s. Having gone through that evolution, and learning for some of the mistakes that you might have done in the past, what would be the optimal evolution path for an organization that is currently growing and evolving? Is there a Pareto rule, like you can get 80% of the benefit if you really focus on some basic thing? This has come up on a few discussions with attendees that were coming from smaller companies where they didn’t necessarily have the budget that Stripe would have to build everything. What will be a minimal version?

Vasani: I think some of our oldest infrastructure is the minimal version. To be clear, it took Stripe to a pretty good size. Our team is only less than 2 years old. Stripe is much older than that. The developer environment was built on the side by a few people in the dev productivity team. They were busy with various other things. The core idea of syncing a repo and having a quick little service supervisor on the dev side is, you can do this incrementally. I’d say that’s the minimal version. You end up with some pretty rough edges around branch switching, as we talked about. You can live with them if you don’t want to invest too much in that.

Synodinos: What additions are the power users clamoring for?

Vasani: This is something we’ve been working on for the last few months, which is just better control over how you run a service mesh, and what services are in dev. We actually have a shared environment that you can deploy to, so that’s deployment. That’s slow. That goes to CI, and it’s a shared environment. This is our QA, staging, whatever you call it, the non-production environment. You can deploy into that. The feature of that is that it’s slower to deploy to, but it’s more production like. The feature of development is that it’s really fast. You edit a file, and it’s there in seconds. The service restarts quickly. Now users actually have to choose what services we have, because you typically don’t want to run every single service in your graph in one machine. You mostly just can’t. Somewhat, this story has so far grown incrementally at Stripe and it’s very messy for users to configure this. This is what we’re working on, just a better way of dealing with a big graph of services. That’s something that’s top of mind for the last couple months, something we’re addressing right now.

When using the remote devbox scenario, do devs face UI latency in a typical interaction?

No. This is where it matters what IDE you use. If you’re using VS Code remote dev, there the IDE actually hides the latency. There is a local buffer going on, and that buffer is asynchronously synced over SSH to the remote end, which is running VS Code on the thing automatically. In other words, VS Code SSHs and runs its stuff on the other end of SSH. All this is hidden from the user, even from the administrator. VS Code just needs a config file, and then it does all that. If you’re not using VS Code, like I tried this with Emacs, and Emacs has something called TRAMP, which is a way to edit files over SSH. There, yes, you see the latency, absolutely. It’s quite annoying. We’re thinking about ways to fix this. The important thing about remote dev is that the source of truth is remote, is on the devbox. It doesn’t mean that every file has to only live there. You could imagine some virtual file system that exposes those remote files locally, nearer to your IDE, under some sync. TBD, but we’re exploring some file system based solution there to reduce latency for editors that don’t support remote natively.

Synodinos: I remember in the past people were using things like macFUSE.

Vasani: There is some churn in the world of macFUSE. Because as I understand it, macOS is trying to deprecate the APIs that FUSE depends on, on Mac. NFS still exists, so the inverse protocol can be used for exposing arbitrary file systems. That may be a future area. This is all very hand wavy, and very researchy work that we need to make some progress on someday. That’s the stage that it’s at right now.

Synodinos: Would you like to elaborate a little bit on the complexities? You briefly mentioned complexities that come with the fact that you have many services, you cannot have everything in the devbox, instead of a script behind where the devboxes talk to it. You probably have hundreds, thousands of services that you need to worry about?

Vasani: We do need to worry about a lot of services. That order of magnitude sounds right. The general complexity, first of all, is resources. There is some limit to how much budget we want to spend per developer, whatever it may be. It may be different for each org. There is generally some budget and you don’t want to explode that into just running every service for every developer. This comes to the second point, which is you don’t really need to. Most developers are changing something very local, and you want to be able to locally reason about that. The testing difficulty comes from the fact that there is some complex graph. What’s happening in the dev environment is not just testing, but also comprehending and understanding of your own software. You’re often changing code in an area where you’re not an expert, or you’re trying to become an expert. You don’t know exactly how to invoke your service if it’s deep in the graph of services. We see this commonly. People say, I want to run the API gateway and this API service and that thing. Finally, when that whole graph is set up, then my service gets called. If your service is pretty far downstream, you don’t necessarily know the exact dance to get it into the state that you want.

The question is, if you’re using a shared environment, and there are all these poor user environments, we can’t really have the shared environment call into the producer environment without some kind of per service routing. I know Jake from Lyft talked about per service routing. That’s one interesting area. The other is that, for efficiency purposes, you just want to mock certain services, and they also just don’t make sense. If you have a fairly complex authorization service, and you’re testing something completely unrelated to authorization, you don’t need to run that service, you just want to return true or something. You want very minimal mocks in certain cases. We want the ability to add the service mesh layer, add a fake, which is something Google has written a lot about in their software engineering book. It’s something I’m very interested in, and we’re looking at that too as well.

Synodinos: How do you keep your mocks up to date when APIs change?

Vasani: I’m running a little bit ahead of myself, because we haven’t actually put these in production yet. When I say in production, I mean among our users internally. I don’t have a good answer there other than, the tests need tests. You need to be able to know when the mocks are out of date. We’re looking at being able to generate mocks from some record-replay solution, maybe. Then you’ll version control those just like any other. They might have some rudimentary smoke tests of their own, and when they break, you’ll have to regenerate them. Again, super handy wavy answer. It hasn’t been borne out by actual use.

See more presentations with transcripts

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


MongoDB Inc. (NASDAQ: MDB) Is A Chance For Risk-Tolerant Investors

MMS Founder
MMS RSS

Posted on mongodb google news. Visit mongodb google news

MongoDB Inc. (NASDAQ:MDB)’s traded shares stood at 1.26 million during the last session, with the company’s beta value hitting 1.08. At the close of trading, the stock’s price was $194.82, to imply a decrease of -3.22% or -$6.49 in intraday trading. The MDB share’s 52-week high remains $590.00, putting it -202.84% down since that peak but still an impressive 3.41% since price per share fell to its 52-week low of $188.17. The company has a valuation of $13.62B, with an average of 1.92 million shares in intraday trading volume over the past 10 days and average of 1.66 million shares over the past 3 months.

Analysts have given a consensus recommendation of an Overweight for MongoDB Inc. (MDB), translating to a mean rating of 2.00. Of 23 analyst(s) looking at the stock, 1 analyst(s) give MDB a Sell rating. 2 of those analysts rate the stock as Overweight while 5 advise Hold as 15 recommend it as a Buy. 0 analyst(s) have given it an Underweight rating. Estimates put the company’s current-quarter earnings per share at -$0.28.

After registering a -3.22% downside in the last session, MongoDB Inc. (MDB) has traded red over the past five days. The stock hit a weekly high of 203.68 this Thursday, 09/29/22, dropping -3.22% in its intraday price action. The 5-day price performance for the stock is -1.71%, and -41.09% over 30 days. With these gigs, the year-to-date price performance is -63.20%. Short interest in MongoDB Inc. (NASDAQ:MDB) saw shorts transact 3.87 million shares and set a 2.34 days time to cover.

Analysts on Wall Street suggest a consensus price target of $353.50, implying an increase of 44.89% to the stock’s current value. The extremes give us $210.00 and $445.00 for target low and target high price respectively. As such, MDB has been trading -128.42% off suggested target high and -7.79% from its likely low.

MongoDB Inc. (MDB) estimates and forecasts

Looking at statistics comparing MongoDB Inc. share performance against respective industry, we note that the company has outperformed competitors. MongoDB Inc. (MDB) shares are -54.72% down over the last 6 months, with its year-to-date growth rate higher than industry average at 45.76% against 1.90%. Revenue is forecast to shrink -16.70% this quarter before falling -27.30% for the next one. The rating firms project that company’s revenue will grow 36.40% compared to the previous financial year.

Revenue forecast for the current quarter as set by 16 analysts is $282.4 million. Meanwhile, for the quarter ending Oct 2022, a total of 16 analyst(s) estimate revenue growth to $294.85 million.

MDB Dividends

MongoDB Inc. has its next earnings report out between December 05 and December 09. However, it is important to take into account that this dividend yield ratio is just an indicator to only serve the purpose of guidance. Investors interested to invest in the stock should ponder company’s other fundamental and operations related aspects too. MongoDB Inc. has a forward dividend ratio of 0, with the share yield ticking at 0.00% to continue the rising pattern observed over the past year. The company’s average dividend yield trailing the past 5-year period is 0.00%.

MongoDB Inc. (NASDAQ:MDB)’s Major holders

MongoDB Inc. insiders hold 3.68% of total outstanding shares, with institutional holders owning 90.86% of the shares at 94.33% float percentage. In total, 90.86% institutions holds shares in the company, led by Price (T.Rowe) Associates Inc. As of Mar 30, 2022, the company held over 8.23 million shares (or 12.09% of shares), all amounting to roughly $3.65 billion.

The next major institution holding the largest number of shares is Capital World Investors with 6.45 million shares, or about 9.46% of shares outstanding. As of the market price on Mar 30, 2022, these shares were worth $2.86 billion.

We also have Growth Fund Of America Inc and Vanguard Total Stock Market Index Fund as the top two Mutual Funds with the largest holdings of the MongoDB Inc. (MDB) shares. Going by data provided on Jun 29, 2022, Growth Fund Of America Inc holds roughly 4.62 million shares. This is just over 6.78% of the total shares, with a market valuation of $1.2 billion. Data from the same date shows that the other fund manager holds a little less at 1.83 million, or 2.69% of the shares, all valued at about 812.81 million.

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

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Presentation: 5 Behaviours to Become an Effective Staff-Plus Engineer

MMS Founder
MMS Blanca Garcia Gil

Article originally posted on InfoQ. Visit InfoQ

Transcript

Gil: Are you already a senior engineer who is looking to progress their career but not take management responsibilities? Or perhaps you’re thinking or trying to get a role that goes beyond senior engineer, and you’re exploring what it means to be a principal engineer, a staff engineer, and what are the common things amongst those roles? Or maybe you’re here because you’re managing senior engineers, and you are looking to gain a better understanding of the roles and progressions, you can coach them to grow their careers further. We’re going to be exploring what are the five key behaviors that will make you a more effective staff-plus engineer.

Why Did I Want To Become a Principal Engineer?

The first thing, we’re going to start with my story and what was my motivation to become a principal engineer. The last organization I worked for was the BBC, the British Broadcasting Corporation. It’s quite a huge place to work at. It has 20,000 staff around the world. Of those 20,000 people, 3000 are in the engineering division. My journey there began as a senior software engineer, and I worked across a variety of teams. One of those teams was the internal data platform. I was there for three years, when something happened. There was a business decision higher up that we’re going to migrate our analytics provider. This impacted many areas of the business, but our team was on the critical path, because we ingested, we cleaned, we modeled, we stored, and we also managed the internal access to that analytics dataset. This was a huge opportunity for our team to migrate away from a legacy architecture, which had become very problematic, because it basically had Big Ben style operational issues. Troubleshooting these issues left ourselves very demoralized, because they took a long time to investigate. Sometimes we just didn’t have enough time to dig into needle in the haystack type of problems, and also, it left the business without data needed to inform critical decisions. It also happens that I have a background in tech support. Throughout my career, I have been on-call for many years in a variety of products. One of the things I found was a lot of the times, across those organizations I worked for, we were missing the learnings from those life issues, and we were not really applying them. This meant that we were constantly solving the same problems, all these issues were slowing down our delivery of new features.

Going back to our story, I was very excited because I saw this as a golden opportunity to apply those lessons learned. Also, I was in a team who was rebuilding and having that opportunity to make the decisions about the next version of our data platform. Our team had also suffered a high churn, so there weren’t many people in my position who understood that context. We knew that it was key to avoid going through the same pains all over again. I also felt that I had a lot to say. I wanted to jump at the opportunity to frame those lessons into questions for everyone in the team. Our team was quite big. We were almost 25 people, and we organized ourselves into squads. We were each of us working in different problems of the areas. One of the key things was that together, we were going to come up with the solutions and decide the technologies which would avoid altogether or at least be able to mitigate the issues we had been coming across in the past.

I took on leadership of one of the squads, who was developing something which we had never had before, which is a data lineage store. This is used in data platforms sometimes to be able to keep a record of all the data that is flowing through your systems. It can help you to troubleshoot issues and understand historical context of things. This data lineage store over time became a critical part of our system because it helped us not only to be able to isolate the failures while we were investigating them, but also keep track of metrics such as service level agreements and also measure the processing latency of the dataset. At that time, my former title was senior software engineer. Looking back, I saw this as the time that I took a leap. I had a lot of people supporting me on this, and set myself on the path to become a principal engineer. When a former role opened a few months later, I really went for it. In summary, my motivation and my reasons, it wasn’t about knowing all the answers, or wanting to make all the decisions by myself. I wanted to be able to take a step back, understand the wider picture of the problems that we were dealing with. Think things through and apply those lessons learned, and work with our teams to build something together which we could own and evolve over the longer term.

Outline

We’re going to be going through, what is a staff-plus engineer? What is the definition of that? What are the different flavors of it, because it can vary a lot? We’ll see the different areas that it can vary. Then we’ll jump into the main focus of this talk, which is the five behaviors. I’ve highlighted in the agenda the five behaviors, so there’s going to be no surprises, but I will be explaining situations, and how and why you will apply those behaviors. Then we’ll summarize all the content together.

What Is a Staff-Plus Engineer?

What is a staff-plus engineer? Do you know what it means, this pretty new term? Essentially, it’s the technical roles that come after senior engineer. How did this term come about? In 2019, Pat Kua who’s a seasoned engineer leader, and he used to be, amongst many other things, the CTO at N26. He wrote a blog post talking about the three paths of career development for software engineers. In a typical company, a software engineer is considered to be on the individual contributor path. Most people would really think, a principal engineer to be on that same track, but Pat Kua thinks a bit differently. He says that the responsibilities of a principal engineer or a lead developer span beyond contributing as an individual person. Instead, that individual contributor path is reserved for people who are domain experts. This could be people such as a database specialist, or someone who is a performance tuning specialist, and so on. Then there is this new path called the technical leadership track, and that is made up of people who have technical skills, and use them to lead others.

Then fast forward one year later to that in 2020, and Will Larson who is the CTO at Calm, he found out that he didn’t have a great understanding of the responsibilities of staff engineers in his team, and neither did they. He set himself a task to understand and document what were those different experiences from staff engineers across different companies. From there kind of draw those common areas amongst them all. He turned that into a book called, “Staff Engineer.” That book has been really useful for myself and many other people to gain understanding of the roles and manage their careers more effectively. It also happens that Tanya Reilly wrote the foreword for that book. She wrote a blog post ages ago called Being Glue. I met her virtually last year because we got to go host a virtual conference focused on staff-plus engineers, together. She’s also currently writing a book to help other staff engineers navigate their careers. There are a few chapters available which you can read already. Also, if you can’t wait, there are many posts in her own blog that provide many resources for staff engineers.

Role Responsibilities

I’m going to start first with the role responsibilities, and we’re going to be going through a few of them. The first one that everyone asked about is, do you still code? It’s almost like we measure whether we are still engineers or not because we are still coding. In this role or roles, you will find yourself you might be writing code at various times. It can be code for prototyping or exploring some problem spaces. You might be doing code reviews and contributing to certain areas of the code base. Most people would say that in order to remain that technical, you have to code, but in my experience, as I spent more time in a principal engineer role, I found that I took a step back off coding. I was more involved perhaps in code reviews. I was also more focused in mentoring and coaching engineers. There’s time and space for coding as well.

The second responsibility is technical direction. What this means is gaining understanding and solving the real needs of the organization. It’s not just about deciding a programming language or a technology that you’re going to be using, and you perhaps find exciting. It’s more focused on the business. Think that in these positions you are accountable to the business first. Setting the technical direction is about owning an area. Then, for example, thinking back about my experience, I took ownership of data storage within our data platform. Then I worked on setting the vision and moved people in that direction. In my case, it was a new problem space for me when I started the role. What I did was I engaged with a supplier, so we work with a third party, in this case, it was Amazon. I also worked with the architect that we had in our team and our product manager, and then the squad. We explored the problem space, and then the possible solutions, because they were quite severe performance issues at the time. We had to take some time first to understand and solve the immediate issue, and then think about that longer term, of what we wanted to get to.

The third responsibility is about mentorship and sponsorship. This key thing is what will differentiate you from maybe more of a senior engineer. This is because you’re leading others, and you have to spend time in those around you, because you will have a far greater impact than you could ever achieve independently. Also, a way to create change that lasts is actually by investing in others. What this means is that, just take time to share the experiences and the advice that you have, and build the relationships with the engineers that you’re working with. Understanding where people want to get to, and help them on that journey. There’s an extra step that mentoring is about maybe helping people, but then the sponsoring thing. Sponsoring is about giving people opportunities to grow, and advocating for them. For example, if there’s someone in your team that you know wants to progress their career in a certain direction, and you know there’s an opportunity, for example, for them to give a presentation amongst a new group and they would be really excited to do that. You actually give that opportunity to them. You support them along that. These kind of opportunities get people visibility, and also get them to see the impact of the work, and also helps them grow in a way that feels very supportive. Also, that you’re not really spoon feeding them, they’re doing the work themselves. This will have a twofold benefit. One of them is them growing, obviously. The other one is that because you’ve believed in them, and you’ve given them these opportunities, your relationship with them will become a lot stronger. That is something that feels even better than actually committing your own code, sometimes.

The fourth responsibility is about providing engineering context. This is about wealth. Think that every organization has processes for decision making, and to make making those decisions earlier. This process usually entail asking people to provide perspective for different areas, and make sure that the necessary context to make that decision is shared. In this role, you will be one of the people who are asked to provide context and you’ll be in the rooms virtually or in person where these decisions are taking place. This is the time that you can create a huge impact. In my past experience, when it came to rearchitect our analytics ingestion pipeline, I took some time to reframe those past pains. Also, I was engaged in other working groups that were making decisions for where our data platform was going to be going a few years down the line. I was asked to explain the types of issues to a group of technical leaders, and to give them that context of the experience I had had operating and maintaining the previous architecture. That context was taken into the principles for the data platform that we’re working with. Then, for future technology decisions, it was also documented. Why is this important? Because if we don’t hear and we don’t document those decisions, one of the issues that generally happens in teams is that you make decisions without really understanding maybe some of the possible caveats and some of the issues that you can have down the line. Getting on board people, it doesn’t really slow you down, seeing that is an investment in avoiding future pains.

Then the last but not least of the behaviors is about getting involved in strategic value projects. Sometimes you are going to be spending time working on projects and making sure that they get done, because they are very important for the business, and you’re going to be leading others along. Sometimes these projects don’t feel like they are very shiny because of the tech, but this is something that is ok. This is where I recommend a talk from Tanya Reilly, called Being Glue. Staff engineers provide that glue. It’s about doing sometimes the behind the scenes work, that it doesn’t sound that glamorous, but you’re making sure that the work is getting done.

These five responsibilities are very wide ranging. It can sound a bit unsettling to some people thinking, is this everything, I have to just manage all of these things on my day-to-day as a staff-plus engineer? Not every day, all of them. You will focus on different ones at different times. The good thing about the role is that it can be a bit about figuring out, what are the most important things for you right now? One of the common things of the role is that, overall, you’re going to be working to longer timeframes. I’m highlighting this because it is one of the hardest things to get used to when you transition to a staff-plus role. When you develop software, and you’re writing code, and you’re writing your tests, and you have automation to do your build and deploy, your feedback loops are very short. You’re very used to getting that feedback very quickly. This is very rewarding, because you’re moving quite fast.

Then, once you move to a staff-plus role, your feedback loops are not that tight. You’re working with people and you are not all the time working directly with the code base. People take a much longer time to give you feedback, and for you to also wait for changes to take effect before you can understand what needs adjusting. You have to learn to be a bit more patient through those longer timeframes. Also, those means that you’re actually going to be working in things that have a higher impact. Reframe that and keep reminding yourself that you just have to work through things. One of the good things that I find about these roles is that these role responsibilities, they vary with time. If you like variety like me, you’re going to have a lot of joy. I linked there Will Larson’s post, which is where I have borrowed these five main role responsibilities.

Different Flavors

We’re going to move on to the different flavors of the role. We’ve seen there’s a variety of responsibilities, but how do you know which ones are the ones for you at a given point? How do you figure out what is needed in the context that you’re working on? We’re going to go and see the variations. Also, we’re going to see within the role and within different companies, what are those variations and what they look like? The first flavor of the role is called a tech lead. This is quite self-explanatory. The tech lead guides the approach and the execution of a particular team. They partner closely with a single manager but sometimes they got partnered with a few managers within a focus area. Then there’s the architect who is responsible for the direction, the quality in a certain area. They have in-depth knowledge and they also understand the technical constraints and the user needs, and certain organization leadership and navigating that organization. The third one is called the solver. This is a flavor that digs deep into certain problem areas, and he finds the appropriate path forward. Sometimes they focus on a given area for long periods, and sometimes they can bounce between different hotspots as the priorities change in the organization. Then the last one is called the right hand. The right hand is a role that extends a senior leaders attention, and borrows some of the responsibilities. This is a role that you can see at very complex organizations. They provide more bandwidth for senior leaders.

I’ve actually had the opportunity to work, for example, in my role. I worked with an architect and a right hand. The BBC is a very complex place to work at. The role when I was a principal engineer, I can see that I was a tech lead for given periods, and I was also a solver when I jumped into some crisis, for example, with the performance of a data warehouse. As part of my role, I did a lot of internal presentations at different levels to help people understand the problem space and the context for decisions for our data warehouse infrastructure. Because this was a critical part of the data storage. Then the role that I had, for example, was quite targeted within the problem space, which was data platforms. When I worked with the right hand, the right hand had a much wider scope, which was across entire departments.

Next, I’m showing you a slide, which is, what are the flavors across different companies? This is a diagram that I borrowed from a site that is called levels.fyi. Levels FYI is a site that is focused on transparency for tech roles, and salaries. I borrowed data for a few of the bigger tech companies, which is Google, Microsoft, Netflix, and Apple. What I want to do is not to compare salaries, but to compare the different levels that the principal engineers are working at. I have highlighted in dotted lines the three different principal engineers in the career ladders that are in three of those companies, and you find that they are at different levels in the journey. They probably have slightly different responsibilities and slightly different scope. Then there’s a couple of them who are Netflix and Apple, that actually don’t have the name of principal engineer highlighting them, they still have very senior engineers, but they might have just different names, or just different scopes in Netflix. The senior engineer path is very long. This is for you to actually understand, what is the differences? Also, if you’re applying to the roles, be able to draw parallels between the pain that you have, or the company that you’re coming from and where you want to get to.

Key Things about Staff-Plus Engineers

To summarize this part, what is the key thing about staff-plus engineers, generally? You have to understand the responsibilities and you also have to understand the levels. I am not wanting to give you a lesson in salary negotiation. It’s more about the growth in the role, and does it match your career goals, what you’re looking to learn, the types of problems you want to engage with? Also, what is the level of autonomy? Depending on the level of seniority, you will be more tied to a team or more floating between different teams and different areas. Also, what is your ability to influence the outcomes that you want? If a role is too embedded in a team, you might not be able to influence those big decisions that you’re looking for. If you are one of the people who is looking to land your next staff-plus role, there is a talk in this same track by Nicky Wrightson, who’s going to give you advice on how to learn that role.

Five Behaviors of a Successful Staff-Plus: Communicating and Listening

We’re going to jump into the core of this talk which are the five behaviors of a successful staff-plus engineer. The first one is communicating and listening. The reason I’m highlighting this as the first one is pretty obvious. This is a behavior that is a foundation skill that you will most likely have been working throughout your career. As you progress, it becomes a key skill. It is an underrated skill. Normally, we will not be adding this to our career paths, but it’s critical for you to think about it, and develop it intentionally. One of the ways that you will be applying it is presenting internally and externally. In order to be effective, you have to learn to navigate through different levels of abstraction. Sometimes you have to be talking very low about the code, and sometimes you have to just talk about maybe principles. Also, while you’re presenting, sometimes you’re going to be asked to explain to people what the technical strategy means for them and the team they’re working in. Also, one of the things that we sometimes forget about communicating is that you are going to spend time writing things. You can be writing blog posts. You can be writing emails. You can be writing requests for comments, which are documents where you want to make decisions, and you actually ask people to feed into those documents. They serve as a way to facilitate sometimes in-person meetings, sometimes asynchronous conversations. One of the things that is the main responsibility of your role is that you are one of the people that can be in charge of driving decision making. This doesn’t mean that you are the one who’s making the decisions, but you have to get people together, and you have to develop a process for people to make those decisions together.

Technical Strategy

The second behavior is technical strategy. First, we’re going to take a step back and explain, what is technical strategy, because a lot of people don’t really maybe understand what it is? Essentially, it is how we use the tech to achieve something, and how do you measure it being effective? This is in the context of a business at our organization. What is this business plan made of? It’s made of principles. It’s made of objectives, and it’s made of tactics. A good technical strategy is focused on outcomes, because the teams and the engineers are the ones who should own how to get to the objectives that the organization sets. Why is it useful? You might be asking. As the organizations grow and become really big, you need a shared context. This type of strategy should be providing that shared context, so that people can draw decisions and derive decisions from a similar understanding. Also, it states the priorities, so priorities across different projects, and different goals. It also creates alignment, because if everyone understands where they want to get to, and also what things can be for others, then it makes it easier to align with other teams and collaborate with other people. A good strategy should also inspire you. Why do I say inspire? Because if it’s saying what is the problem space and what things you would want to improve, and how they would look good, then you would have ideas as a result of what areas of your products you would improve to be able to achieve those goals. That’s what I call inspiring, because you want to feel that you have something to say and you have something to contribute, not just be told all the steps to get to the place.

In a role of staff-plus engineer, how are you going to be contributing or providing that technical strategy? First, you’re going to be understanding the systems that you work with and how they connect between each other. You’re going to be providing technical context to discussions. Another thing you’re going to be doing is you’re going to have to learn fairly quickly unfamiliar things. Not just the systems that you’re used to working with, but understand architectures, also code bases, and also technical decisions, and be able to contribute to them. One of the things about stepping into new areas is that in this role, even though you have a lot of experience, you also have to not be afraid to ask questions that you think are very simple. One of the really important things is that in this role while you’re explaining things and if you want to make proposals to change things, you have to learn to quantify and draw some data from the systems that you’re working with. Because sometimes in order to be able to convince people, you’re going to have to show them, for example, the hidden costs of projects or the benefits of stopping doing something. That is by getting some data, and then also understanding what the data means. That being able to quantify, that will add a lot of weight to the proposals that you have, because you’re showing that it’s just not your own personal interests. You’re actually speaking on behalf of your team, or sometimes your entire department. It’s something that you have to be very aware of that you have to base what you are speaking about, not just on your own experience, but you have to be speaking to engineers across the teams that you’re working with.

Networking and Influencing

The third behavior is networking and influencing. Now is when we all think, this dreaded work. Why networking? It is because of one big reason. In this role, you are an enabler. This is not just about you solving the problem by yourself. People are going to come to ask you questions and you’re not going to know the answers, and you’re not expected to. You can be very helpful and you can unlock people by knowing who can help them with that. How do you know who can help others? You have to work on building up your network. This network is going to help your team but also you’re going to help your network because they will draw on your experience to help the team. It’s like a win-win situation. It’s very important that you spend time developing your network. What are the smaller tasks that you will do as part of networking and influencing? You have to learn how to navigate an organization. What this means is, who makes decisions? How do the internal processes work? What are the different competing priorities? How are, for example, build versus buy decisions made? How do you create a business case, to move change and drive things forward?

Building your network means that you speak to engineers, but you also speak to people who are not in engineering roles. People who are at different levels. Sometimes you’re going to have to need some help to learn, who is the person that you should be speaking to? For example, I’ve used a lot of introductions, people introducing me to other people, so that perhaps they would give me sometimes, and we could just introduce each other and learn what the other person did. Because it is very important that to build trust, you need to be able to speak to people, one-on-one. It doesn’t need to be very long meetings, but be able to have that one-on-one focus time. Because that’s when you listen to them, and you really get to know them, and they listen to you. That way, you have a more successful relationship for the future. The last thing about networking and influencing is that, in these roles, you’re usually not managing people. Sometimes we think that we don’t have much power. There is an informal power that comes with the role. You have to be very careful about the words that you use when you’re speaking to people, and also your behaviors, because people are going to draw those. They’re going to see, and they’re going to watch very closely what your actions are. I’m going to summarize the networking and influencing with, use your influence for good. Use that to create good change. I have seen a lot of maybe unintended consequences of people or me sometimes not realizing that a word out of context could really give people a lot of pain.

Technical Leadership

The fourth behavior is technical leadership. I personally quite like this, because it is about getting engineers to buy into an idea, not necessarily yours, but bringing people together, creating opportunities for cross team collaboration. This is a very rewarding part of the role for me. Also, to get people to collaborate together, you have to create that psychological safety. You have to then create the trust in groups. Not only one on ones, when you’re networking, but also in the groups that are working together. How do you do that? Guide yourself with your values. Use your differences to bring people together. We sometimes forget that tech is very rich culturally, we work with many different nationalities from all over the world. Our differences can bring us closer if we have the space to share them and get to understand each other. In the role of a staff-plus engineer, you’re going to be sometimes spinning up teams quite frequently, and you have to be able to create that trust and get them to almost hit the ground running. This is a way that you’re going to be amplifying your impact, because you’re going to be coaching them, you’re going to be delegating them. You have to learn to break the behaviors, break the work into smaller pieces, so your team can then take responsibilities and get the work done. Also, remind yourself that you have to manage your energy, because people will always take a lot of that. It’s more about mentoring and sponsor engineers, it’s not necessarily about you doing all the work. The technical leadership is helping others grow, and helping people grow on their own path to staff-plus roles. Because at the end of the day, what you are in this role is a force multiplier for other people and your teams.

Managing Career

The last behavior which is a bit of a bonus here is about managing your career. This is something that you might be thinking, how on earth am I going to find time to balance my own career while I’m doing everything else that we’ve spoken about? It’s about managing your energy, knowing where to flow, and setting time aside to be able to work on the different types of work that you’re going to be doing. Some types of work are kind of more meetings, but then there’s these other types of work that you need to be very focused on your own, which is what we call deep work. You have to really organize your agenda accordingly and sit down with yourself, write your goals, because this is going to be your way of knowing what you should be focusing on. It should be broad enough, align to the organizational goals. They’re going to have quite long timelines. This is going to give you time to actually reflect. I reflect usually every week or every couple of weeks, and I know many senior engineers do. Just reflect and understand, what have you accomplished? Are you still on track with those goals? What things have changed? Adapt as you go along.

Also, your goals help you understand when you have so many things on your plate, what is the top priority thing? What do you need to focus on? Why are you doing something? Also, there will be some things that come to you that you don’t necessarily have to do. It’s not about doing everything, it’s about knowing what to focus on. The rest, you have to either delegate. You discuss with your manager, you discuss with your team, but it’s not for you to be doing. The very important thing is to ask for feedback in your role, how you’re doing. Have those conversations regularly. One of the things about giving feedback is that you have to also become better and more effective about giving feedback. Because remember, you’re growing other people around you, and you’re also becoming a better communicator, so you’re slipping bits of feedback into different areas, not just doing a once a year performance review, because small bits of feedback more frequently will help you more than a big document every so often.

In order to grow, you will need mentors yourself, but the people who will really grow your career significantly will be sponsors. Be always on the lookout for sponsors. If you can have a formal sponsor who you can liaise with regularly, that’s even better, but not everyone has a formal sponsor. Spend time talking to people outside your organization, to keep an eye where things are. Go to conferences, such as this one. Also, have that group of people that can cheer you on when you have days that you feel that you don’t accomplish anything, but then can also challenge you and make you take a step back. Think things twice before you decide where to go with something. Take care of yourself, because if you try to do everything, you’re going to end up burnt out. This is something that can catch you without you even realizing. It’s very important that when you take time to reflect in this role, that you know where you’re going towards. You also know what motivates you, and what is driving you. You realize that you are actually spending time on those things, because those goals help you sustain that motivation and create the discipline to keep growing in the role. The summary in this case for managing your career is setting the goals, tracking them, and reflecting.

Conclusion

Understand what level you’re working at, and what the expectations of the role are. This is the first thing to start on a good foot on the role. Apply these five behaviors intentionally, depending on the situation that you’re in. Then remember and remind yourself that this role is on the technical leadership path.

Questions and Answers

Nardon: How do you balance the time expended in mentoring and teaching others with the time that you need to use for doing your own work? How do you manage to do that?

Gil: I think for me, it involves a lot of blocking out the slots in my calendar. At the end of every week, I used to have my little reflection time that was like 5, 10 minutes. I would also look at the week back and see, what meetings have I been in? Where have I spent my time? Then, almost set goals like how much time can I or do I want to spend mentoring people, and just allocate the time in the week intentionally. I found that in the role, if you wait to have free time, that just doesn’t happen, there’s always something else. There’s always something urgent, someone that needs something in the time. For me, it was about planning, and about also offering to people. If I had some space for mentoring, then maybe I would share it with sometimes the managers, and say, “I have a bit of time because someone I was mentoring doesn’t need that any more. If you think someone else could benefit from time with me, just please put me forward for that.” It’s about allocating time, and then almost planning. It doesn’t happen that much on the spot these days.

Nardon: How do you keep motivated when you are working on initiatives that don’t involve shiny things, but that do have high organization value?

Gil: I’m a very curious person, by nature. I’ve spent about 16 years in tech. At first, I wanted to work on all the shiny new tech. Then, over time, I realized that usually the nitty-gritty problems involve the not very shiny stuff. In order to motivate myself, I try to always think, what is it for me to learn in this situation? What are the takeaways? Also tell myself that it wasn’t forever. I almost put a timeframe, because there were some jobs that actually I have to admit that I resigned because I was not mature enough to think that that wasn’t forever. I thought, my career is going down the drain with this. That can be a very common thing. What I did in the last couple of years, especially when I was working on the data warehouse problems that was not very shiny at all, but speak to my manager regularly. There was a point that I said to them, I think I’ve had enough of this. We set some goals to almost make myself redundant from that problem space and figure out what people or team would be happy to learn about it. It was me selling a bit the problem space, because what is something that you have learned and you might have gotten bored. It might be something that is a learning opportunity for someone else. It’s not forever, and also hand over before it gets too late. Then you’re like, “I am dead tired of this. I don’t want to do this anymore.”

Nardon: Do you recall a tech strategy that stood out to you as particularly successful?

Gil: If you remember or you know the tech strategy at least in your department or the organization that you work with, that means it’s already successful. Most people don’t know what that tech strategy is. I used to know the strategy in my department, but I remember doing an exercise with my manager, because I was asking them, how do you link this up in the organization? How can I have bigger influence on these problems that we’re facing? I realized I had no idea how the tech strategy linked. That’s when I realized, this tech strategy is not really very successful, because if I don’t know, then my team doesn’t know either. Success means that you know it.

Nardon: What approach do you use to quantify data that’s hard to quantify? Data about usage, revenue are easier. Something like comparing the cost benefits of different technical pivots sometimes aren’t obvious.

Gil: My experience with working with data is, especially when you’re at the start of maybe importing a dataset, which is what we did in the data analytics platform. Spend some time setting up the metrics for that data, and see whether those metrics can be achieved with the dataset that you have or not. Also, ask yourself, why do you need those metrics? What are the decisions that you want to be able to derive on them? Because I have seen that we went in my team from almost having no metrics to too many. Then people just get bogged down by so much data, and no one really looks at them anymore. Going back to your question about, how do you create those metrics? The earlier you do it, the easier it is going to be.

Nardon: Could you provide some examples of goals for becoming staff developer or growing as a staff developer?

Gil: The quick path, figure out from these behaviors, do you find any areas particularly difficult, or are there any gaps? If you don’t know, ask for feedback, not just your manager, but your peers. If you know people, you can just say, “I’m trying to grow further in my career, and it would really help me if you gave me a bit of insight into what was the recent experience we had working in this project together.” Don’t say the word feedback. A lot of people get really shaky about it, and they feel that it’s like a big responsibility. You just want a bit of insight into how they perceive working with you. I found that people were very constructive, and it really helped me and it kept me motivated, because then people saw that I was trying to improve. That helped me then go and sit by myself and then sit with my manager and say, “This is the feedback I’ve collected, and these are the goals that I think I need to work on.” Then my manager would also contribute and maybe give me some feedback, but it was always driven by me. My manager in that case gave me a bit of room with that, because I think they saw that I was very invested in improving, so they just left me to figure out things.

See more presentations with transcripts

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Truist Securities Initiates Coverage on MongoDB With Buy Rating, $300 Price Target

MMS Founder
MMS RSS

Posted on mongodb google news. Visit mongodb google news

09/30/2022 | 09:10am EDT

© MT Newswires 2022

All news about MONGODB, INC.

Analyst Recommendations on MONGODB, INC.

Financials (USD)

Sales 2023 1 208 M

Net income 2023 -422 M

Net cash 2023 721 M

P/E ratio 2023 -33,0x
Yield 2023
Capitalization 13 642 M
13 642 M
EV / Sales 2023 10,7x
EV / Sales 2024 8,31x
Nbr of Employees 4 240
Free-Float 96,2%

Chart MONGODB, INC.

Duration :


Period :

MongoDB, Inc. Technical Analysis Chart | MarketScreener

Technical analysis trends MONGODB, INC.

Short Term Mid-Term Long Term
Trends Bearish Bearish Bearish

Income Statement Evolution

Please enable JavaScript in your browser’s settings to use dynamic charts.

Sell

Buy

Mean consensus OUTPERFORM
Number of Analysts 25
Last Close Price 198,56 $
Average target price 360,55 $
Spread / Average Target 81,6%

EPS Revisions

Please enable JavaScript in your browser’s settings to use dynamic charts.

Managers and Directors

Sector and Competitors

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

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Why MongoDB Stock Popped Today | The Motley Fool

MMS Founder
MMS RSS

Posted on mongodb google news. Visit mongodb google news

What happened

Shares of MongoDB (MDB 1.92%) were moving higher Friday after the cloud software stock received a bullish analyst note from Truist. As of 1:43 p.m. ET, the stock was up 5.4%.

So what

Truist analyst Miller Jump initiated coverage on MongoDB Friday morning with a buy rating and a price target of $300, implying an upside of more than 50% from the stock’s closing price Thursday. Jump argued that the provider of NoSQL database software is at the crossroads of several converging database markets, and said Wall Street was underestimating its revenue growth potential over the next decade. He also believes the stock will attract a wider investor pool once the company reaches profitability.

Like many software-as-a-service (SaaS) stocks, MongoDB shares have fallen sharply this year as valuations in the sector have compressed due to rising interest rates, fears of a recession, and concerns about a lack of profitability among cloud companies.

MongoDB stock is now down by nearly two-thirds from its late 2021 peak, and the stock plunged following its most recent earnings report as concerns about ongoing losses trumped its strong revenue growth.

Now what

MongoDB has been spending aggressively on sales and marketing to drive adoption of Atlas, its cloud-based database product. In its second quarter, which ended July 31, revenue from Atlas jumped 73% and accounted for 64% of the company’s $303.7 million in revenue.

Management remains confident in its long-term growth opportunity, and said in its recent earnings call that even with the macroeconomic headwinds, it has seen no changes in its sales cycle, indicating strong demand for its products.

Though an analyst upgrade isn’t going to change the trajectory for the stock, the bull case for MongoDB remains sound despite the shift in investor sentiment.

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

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


MongoDB (NASDAQ:MDB) Now Covered by Analysts at Truist Financial – MarketBeat

MMS Founder
MMS RSS

Posted on mongodb google news. Visit mongodb google news

Equities research analysts at Truist Financial started coverage on shares of MongoDB (NASDAQ:MDBGet Rating) in a report issued on Friday, The Fly reports. The brokerage set a “buy” rating and a $300.00 price target on the stock. Truist Financial’s price target points to a potential upside of 53.99% from the stock’s previous close.

A number of other research analysts also recently issued reports on MDB. Robert W. Baird decreased their target price on shares of MongoDB from $360.00 to $330.00 and set an “outperform” rating for the company in a research report on Thursday, September 1st. Morgan Stanley decreased their price objective on shares of MongoDB from $378.00 to $368.00 and set an “overweight” rating for the company in a research report on Thursday, June 2nd. Barclays decreased their price objective on shares of MongoDB from $438.00 to $360.00 and set an “overweight” rating for the company in a research report on Thursday, September 1st. Needham & Company LLC decreased their price objective on shares of MongoDB from $350.00 to $330.00 and set a “buy” rating for the company in a research report on Thursday, September 1st. Finally, Canaccord Genuity Group upped their price objective on shares of MongoDB from $300.00 to $360.00 and gave the stock a “buy” rating in a research report on Thursday, September 1st. One investment analyst has rated the stock with a sell rating and nineteen have assigned a buy rating to the stock. According to MarketBeat, MongoDB has an average rating of “Moderate Buy” and an average target price of $382.26.

MongoDB Trading Down 3.2 %

NASDAQ MDB opened at $194.82 on Friday. The company has a market capitalization of $13.39 billion, a PE ratio of -36.35 and a beta of 0.95. The company has a fifty day moving average of $291.43 and a 200 day moving average of $311.53. MongoDB has a 1 year low of $188.17 and a 1 year high of $590.00. The company has a debt-to-equity ratio of 1.70, a current ratio of 4.02 and a quick ratio of 4.02.

MongoDB (NASDAQ:MDBGet Rating) last posted its earnings results on Wednesday, August 31st. The company reported ($1.69) earnings per share (EPS) for the quarter, missing analysts’ consensus estimates of ($1.52) by ($0.17). The business had revenue of $303.66 million for the quarter, compared to analyst estimates of $282.31 million. MongoDB had a negative net margin of 33.43% and a negative return on equity of 52.05%. The company’s revenue for the quarter was up 52.8% on a year-over-year basis. During the same quarter in the prior year, the firm earned ($1.15) earnings per share. Research analysts forecast that MongoDB will post -5.36 earnings per share for the current year.

Insider Activity at MongoDB

In related news, CRO Cedric Pech sold 350 shares of the company’s stock in a transaction dated Tuesday, July 5th. The shares were sold at an average price of $264.46, for a total transaction of $92,561.00. Following the completion of the sale, the executive now owns 45,785 shares of the company’s stock, valued at approximately $12,108,301.10. The sale was disclosed in a filing with the SEC, which can be accessed through this hyperlink. In other MongoDB news, CFO Michael Lawrence Gordon sold 2,704 shares of the business’s stock in a transaction dated Tuesday, July 5th. The shares were sold at an average price of $264.47, for a total value of $715,126.88. Following the transaction, the chief financial officer now directly owns 93,132 shares in the company, valued at approximately $24,630,620.04. The transaction was disclosed in a document filed with the Securities & Exchange Commission, which is accessible through the SEC website. Also, CRO Cedric Pech sold 350 shares of the business’s stock in a transaction dated Tuesday, July 5th. The shares were sold at an average price of $264.46, for a total transaction of $92,561.00. Following the completion of the transaction, the executive now owns 45,785 shares in the company, valued at $12,108,301.10. The disclosure for this sale can be found here. In the last quarter, insiders sold 55,160 shares of company stock valued at $15,050,095. Corporate insiders own 5.70% of the company’s stock.

Hedge Funds Weigh In On MongoDB

Several institutional investors and hedge funds have recently bought and sold shares of the company. Price T Rowe Associates Inc. MD boosted its holdings in MongoDB by 0.3% in the 2nd quarter. Price T Rowe Associates Inc. MD now owns 8,258,298 shares of the company’s stock valued at $2,143,029,000 after purchasing an additional 24,197 shares during the last quarter. Vanguard Group Inc. lifted its holdings in shares of MongoDB by 2.1% in the 1st quarter. Vanguard Group Inc. now owns 5,970,224 shares of the company’s stock worth $2,648,332,000 after acquiring an additional 121,201 shares during the last quarter. Franklin Resources Inc. lifted its holdings in shares of MongoDB by 10.1% in the 2nd quarter. Franklin Resources Inc. now owns 1,346,625 shares of the company’s stock worth $349,449,000 after acquiring an additional 123,431 shares during the last quarter. State Street Corp lifted its holdings in shares of MongoDB by 0.6% in the 1st quarter. State Street Corp now owns 1,343,657 shares of the company’s stock worth $596,033,000 after acquiring an additional 7,389 shares during the last quarter. Finally, 1832 Asset Management L.P. lifted its holdings in shares of MongoDB by 19.3% in the 1st quarter. 1832 Asset Management L.P. now owns 1,028,400 shares of the company’s stock worth $450,095,000 after acquiring an additional 166,400 shares during the last quarter. 89.85% of the stock is currently owned by institutional investors and hedge funds.

About MongoDB

(Get Rating)

MongoDB, Inc provides general purpose database platform worldwide. The company offers MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premise, or in a hybrid environment; MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; 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

The Fly logo

Analyst Recommendations for MongoDB (NASDAQ:MDB)

This instant news alert was generated by narrative science technology and financial data from MarketBeat in order to provide readers with the fastest and most accurate reporting. This story was reviewed by MarketBeat’s editorial team prior to publication. Please send any questions or comments about this story to contact@marketbeat.com.

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

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

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


NPM Package Masquerading as Popular Material Tailwind Library To Install Malicious Code

MMS Founder
MMS Sergio De Simone

Article originally posted on InfoQ. Visit InfoQ

Researchers at ReversingLabs discovered a malicious npm package masquerading as the Material Tailwind library. Their finding highlights a new trend for threat actors to install malicious code, dubbed impostor packages, say the researchers.

According to the researchers, the Material Tailwind attack is only the latest example of packages that aim to disguise as legitimate packages:

These types of software supply chain attacks can be spotted almost daily now. In most of these cases, the malware in question is fairly simple JavaScript code that is rarely even obfuscated.

The Material Tailwind impostor, though, showed a rather high level of sophistication, including the usage of code obfuscation and other techniques to complicate reverse engineering, and a two-stage pipeline to download and install the actual malware, let alone a full set of features that made it an actually useful tool.

To discover the threat, the researchers used their Titanium Platform to identify the presence of obfuscated code in a JavaScript file. To make things look more suspicious, the file was listed in package.json as a post-install script.

Post-install scripts get executed immediately after package installation. This is why they are a quite popular mechanism for achieving code execution among threat actors. From the perspective of a threat researcher: an obfuscated script that is set to run immediately after installation is a (big) red flag.

Inspecting the deobfuscated code, the team found it able to send a POST to a specific IP address and download a zipped file using a specially crafted URL that included an identifier of the victim. ZIP compression was likely used to bypass basic antivirus checks, say the researchers. The ZIP file contained an executable which deployed a number of techniques to evading security checks, including a custom runtime packer using high precision math, long sleep delays while running, and contacting legitimate sites, such as Google, to check for internet access and ensure it is not running in a sandbox.

Downloading and unpacking the ZIP is only the first stage of the attack, though, ensuring a PowerShell script is run daily.

At stage 2, the malware fetches a XOR encrypted and base64 encoded file from a public Google Drive link.

This encoded file includes the IP address of the command and control server which then sends encrypted instructions using a dedicated socket connection.

After reporting it to npm, the malicious package was quickly removed but not replaced with a security holder version. This gave the attackers a chance to publish new versions of the package to target macOS in addition to Windows systems. On macOS, the malware used curl to to fetch a shell script that was then piped into sh.

If you want to know more about the level of sophistication of this attack, do not miss ReversingLabs analysis, which includes the deobfuscated malicious code and a discussion of the indicators of compromise (IOCs) that should never be ignored.

About the Author

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Podcast: Genuine Recognition as a Motivating Driver

MMS Founder
MMS Dr Natalie Baumgartner

Article originally posted on InfoQ. Visit InfoQ

Subscribe on:






Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I’m sitting down with Dr. Natalie Baumgartner from the Achievers Workforce Institute. Dr. Natalie, welcome. Thanks for taking the time to talk to us today.

Dr. Natalie Baumgartner: Thanks so much for having me, Shane. Happy to be here.

Shane Hastie: Probably a useful starting point is, who are you?

Introductions [00:27]

Dr. Natalie Baumgartner: Well, you heard the doctor in my name. So I am a business psychologist, and I have spent my whole career focusing on the world of the employee experience. So working with organizations from entrepreneurial startups to Fortune 500 organizations, really focused on what are the factors that allow organizations to provide a great experience for their employees? My PhD’s in clinical psychology, but I really focus on strength-based psychology and all the things that make workplaces great places to be at. And as you mentioned, I work with Achievers.

So Achievers is an employee experience platform that provides a number of technological resources that help organizations truly engage their people. And the Workforce Institute within Achievers is the research and science arm. So we are a bunch of, I like to say, engagement nerds, I myself am a self professed nerd, who really focuses on ensuring that everything that we do at Achievers, from the technology we develop to the thought leadership we share, is rooted in science that is focused on changing the way the world works, which is our mission.

Shane Hastie: Thank you very much. And that certainly aligns well with a lot of the work we do here in the culture and methods team on InfoQ, so I’m excited, I’m interested. Possibly a starting point is the state of recognition report that was recently released. Tell us about that.

The State of Recognition report [01:48]

Dr. Natalie Baumgartner: Yeah, happy to. We have four quarterly research reports that come out of the Achievers Workforce Institute each year. And this was our Q2 report, was the state of recognition report. Our focus was really on understanding the sea change that has occurred in the business arena. I don’t think anyone lacks a window into the reality that employees have really by and large around the entire globe re-evaluated what work means for them and where they find meaning and value in work, how and when they want to work. And part of our focus was on why are people voting with their feet and leaving organizations, and what is it they really want and need in their work life and their work experience? And so this report really is empowering, we believe, change in the new world of work.

Shane Hastie: What is it that people are looking for?

Dr. Natalie Baumgartner: Great question. I’ve worked in this arena for a couple of decades now, and I would say this is both the most interesting and inspiring period of that time that I’ve focused on the employee experience. Because employees, rather than beating the drum only or mostly around compensation or benefits, perhaps promotion in their career and so on, the focus has really been on the importance of having a deep sense of belonging and fulfilment at work and having sustainable work-life integration, and of course then continuing to progress in their career.

So we found that one of the single most powerful tools that’s really driving this experience of connection and belonging at work and purpose that employees are really mandating from their organizations is the tool of recognition. And one of the sharpest findings we found is that from recognition frequency to what makes recognition meaningful, that we have some insight, more than we ever have had before, about how leaders can create a culture of recognition and belonging in the workplace to drive engagement and productivity and job commitment.

Shane Hastie: Let’s go right down to first principles. What do we mean when we say recognition?

Recognition matters [03:46]

Dr. Natalie Baumgartner:  I think as humans, we can all pause and think about a time when someone has really seen us and appreciated us as a unique individual and for doing something that’s really meaningful that has stood out. And so that’s what we refer to when we use the term recognition. It’s really what many of us think about as appreciation or even gratitude. And Shane, you and I were just chatting before we started talking on this podcast about how it feels when someone really sees the great contribution you’ve made and acknowledges it, and even more powerfully, acknowledges it in a meaningful way, and even better, in a public way, so that you really feel like the hard work you’re doing, the effort you’re putting in is truly having an impact.

Shane Hastie: If I think of a lot of our audience, we are the technologists, we’re stereotypically a little bit introverted, going to be a little bit uncomfortable even with some of this, certainly the public recognition, aren’t we?

Dr. Natalie Baumgartner: Yes. And that’s something that we dove into a little bit, because before we were really gathering this kind of rigorous data, I too was a little dubious around whether the concept of public was so critical in terms of the impact that recognition can have. And when I say public, what I really mean is that it is powerful for one to hear appreciation or recognition from one’s direct manager in a meeting when they’re operating solo. And if we take that same appreciation and amplify it by sharing it in a newsletter or sharing it on a recognition platform, when we ask employees, regardless of wiring or personality or role type or industry, we find that employees say it felt really good. It felt good to be appreciated in that way. And to have it not be shouted from the rooftops literally, in a way that might be quite embarrassing, but just shared with one’s cohort and colleagues, and especially if it’s something that feels really true and meaningful.

Shane Hastie: There’s something important there, the really true and meaningful. How do we prevent this from being, dare I say, lip service?

The need for sincerity and genuine recognition [06:03]

Dr. Natalie Baumgartner: I’m so glad you asked about that, because one of our objectives in this particular research report was to dive in a little bit more deeply to understand what makes the recognition meaningful for employees. So, we actually for many years had some assumptions, I mean some criteria that we thought were the right ones to provide an experience where someone would hear a recognition and say, “Oh yeah, that feels really good to me, it feels really meaningful.” But we challenged ourselves and said, let’s ask employees. And what we found is 64% of employees said, first of all, that they would prefer more meaningful recognition as opposed to more frequent. The majority of employees said, I’d rather get fewer recognitions, but have them be really meaningful than mere lip surface, to use your word, Shane. And in addition, we found, we identified a few factors that employees rallied around in terms of what makes a recognition meaningful.

Factors that make recognition meaningful and real [06:54]

So the top three factors that were identified were that the recognition was about something specific that I did. So not, “Thanks, Shane, for doing a great podcast,” but, “Thanks for creating this really interesting conversation in your podcast about this topic of recognition and really bringing insightful lens to the conversation.” Two, that it was something about me as an individual or about something I value. So in this case, I love getting the opportunity to give you some recognition change in real time. So, “Shane, the way that you have such a comfortable conversational style clearly put your interview at ease and your sense of humor also really came through.” And then three is that it’s about the way in which I made a difference to the person who sent me the recognition.

So it could be, “And I’m so glad that you have this podcast on recognition because for me as a manager, I’m a new manager, I’m really trying to understand what are the most important things for me to do to help my team members feel valued and to have a great sense of engagement at work. And so this has really helped me become a better manager.” So something specific, something about me as an individual, and some way in which I made a difference to you.

Shane Hastie: And I feel it. Thank you. From personal experience and that conversation, I do feel more engaged, more motivated. So it works. Who would’ve thought it?

Dr. Natalie Baumgartner: Powerful. It’s powerful. Do you know that 75% of employees who are recognized at work would recommend their manager to others? And I share that because even for me, when I moved into this area of understanding this aspect of engagement recognition, many years ago now, I thought, how powerful can it really be? This is about saying thank you. And it gives us some insight into who we are as humans that we really value it, that it really feeds and fuels us. And so even if you feel sceptical as a manager about the importance of doing this, or you feel uncomfortable, and so you’re like, I think I’m going to go put that over to the side of my desk and do some things that I know I’m good at that don’t make me sort of hesitate and feel like I’m not going to be able to deliver.

I would encourage you to put it back in the middle of your desk and give it a try, because employees who are recognized at work not only have higher levels of engagement, are much more likely to stay in their job, are more productive, but they also recommend their manager to others. They find they have a stronger and more powerful and more positive relationship with the person that leads them.

Shane Hastie: A lot of direct benefits there to the employee-manager relationship. What about to the employee-company relationship?

Recognition helps with retention [09:33]

Dr. Natalie Baumgartner: Right. Well, I think one of the things that’s top of mind right now for organizations is both retention and finances. So we know that individuals that are recognized weekly are twice as likely as average to have strong job commitment and five times more likely than those never recognized to say that they rarely think about job hunting. Those are some pretty powerful stats when you’re thinking about how to retain your workforce or attract a workforce. And two thirds of respondents say that feeling recognized actually reduces their desire to job hunt. In addition, on the financial side, and we know that a lot of organizations are focusing on tightening their belts right now and being concerned about a global downturn economically, 52% of employees say feeling recognized for their work would reduce the negative impact of a salary freeze. And on top of that, employees rank social recognition as most important, 42%, before low monetary recognition and infrequent high monetary recognition.

What does that mean In a nutshell? It means that it’s so powerful that employees who feel well-recognized are willing to perhaps kind of sit where they are at in terms of salary and to continue to stay inside their organization. But if finances are an issue to such an extent that there isn’t money in the bank to make recognition a monetary feature in your organization, social recognition, which is simply recognizing for the sake of recognizing, is actually more important even to employees than receiving that gift card with that recognition. So it’s actually something that organizations can do with very little budget and resource and it has a massive outsize impact on their ability to retain employees.

Shane Hastie: What’s the disconnect between what HR policies and… What we think we’re doing and what we are actually achieving?

The disconnect between what HR thinks and what is actually happening [11:24]

Dr. Natalie Baumgartner: One of the interesting findings we have surfaced in several, actually, of our recent research studies on recognition, on wellbeing, on diversity and inclusion, is that we’re continuing to see a disconnect between how HR leaders feel they’re doing, or their organization is doing in providing the supports and nurturing that employees need versus how employees feel like they’re doing and receiving it. So HR leaders are, I think, really well-intended, but tend to think, “We’re doing okay,” and employees are saying, “I’m not really feeling it.” And so that’s something just to be aware of. We have seen that several times now in our research and it has caused us to encourage organizations to not assume that just because they have practices that are in place to help and support employees, that they’re the right ones or that they’re landing in the right way with their employees. So this is my opportunity to remind organizations, you need to ask employees, how are you doing?

Whether you’re using a voice of employee tool or you’re doing focus groups or having your managers have one-on-one conversations, you need to be asking and you need to not assume. In addition, when it comes to recognition specifically, we know that regular training on how to recognize well, so recognition best practices, is really crucial, and for developing and nurturing a culture of recognition. It’s not complicated, it just requires understanding a few basic principles. And the data in this research report showed a disconnect between leaders and employees on that training.

And what I mean by that is 9 out of 10 HR leaders said that they provide recognition training to their staff, at least once, about how do you recognize what are the ground rules? And meanwhile, less than half, 41% of employees said they have received any training at all. So we know 90% and 41% are pretty different numbers, and it tells us that we have a little ways to go as organizations in terms of ensuring that we’re not only providing the opportunity for our leaders and managers to recognize by providing budget or resource, but we really need to make sure that we’re providing training that feels really effective to our managers on how to do it well.

Shane Hastie: Going a little bit wider, if we may, thinking of a fair percentage of our audience, these are relatively new managers, promoted often from a technical background. How do we support these people to become better leaders?

Advice for new leaders [13:51]

Dr. Natalie Baumgartner: Well, we know that so often really successful employees are promoted into positions of leadership with very little to none, often, training around what are the most important factors to focus on? How do you become a really great manager? So I encourage a few things. One, we have actually a manager empowerment model at the Achievers Workforce Institute that we focus on. And we know that to keep it really simple, that there are just a few things that if managers focus on, have the most powerful impact on their team members’ experience. So one is contact, and that became so clear during the pandemic, that simply having that one on one time with your team member, whether it’s in person or remote, can’t be replaced by any other factor. It is the most important factor for managers to be committing to and delivering and having real conversations. Secondly, when you’re having that conversation, asking your team member what they need. What they need in terms of development, what they need in terms of support. Again, it’s really important not to guess.

And so that actually in a way makes your job easier. You don’t have to be a mind reader as a manager. You simply need to ask the question around how can I help you get to where you want to be, develop in the way that you want to develop? And certainly, recognizing. We know that if you are going to have one takeaway from this conversation, it would be that providing a meaningful recognition once a month at the minimum to each member of your team has a tremendous impact on how your team’s going to feel in their job, how they’re going to feel about you, and the likelihood that they’ll stay and continue to do a great job for you. So focusing on those factors keeps it simple. None of those require some massive amount of extensive, expensive training. It’s really about making the time, having the contact, asking people what they need, doing your best to deliver on it or to get them in touch with someone who can, and then recognizing them for what they’re doing well.

Shane Hastie: Sounds such a simple formula, and yet so often we get it wrong.

Managers experience pressures from all directions [15:57]

Dr. Natalie Baumgartner: Well, I think it’s very easy to become overwhelmed as a manager. During the pandemic, we found, and this is certainly not exclusive to the pandemic, but in the height of the pandemic, we found that managers were really the meat in the sandwich. They’re getting pulled in both directions. They’re needing to provide support and resource to their employees and also deliver to the people above them. And so it is challenging, especially to be a new manager, and especially to be a new manager without much training or development on how to do it. It’s very challenging to do oftentimes your day job still, the job that you were doing before you became a manager or some aspect of it, plus nurturing and supporting the people beneath you.

I think having a lot of empathy for that challenge is really important, but keeping it simple. So that’s why I referenced, if you’re having contact, if you’re helping to develop and provide feedback, and if you’re recognizing your employees, even each of those just a little bit has a tremendous effect on how your team is going to function. And all that comes back to you then, because then you’ll feel that in return, and then what develops is a really positive cycle.

Shane Hastie: Something that sits in my mind is, we know this as managers dealing with operational people and direct reports. Do we forget it as we rise through the hierarchy? It feels like it.

The lack of effective management and leadership training [17:18]

Dr. Natalie Baumgartner: I think often it’s that the job or the task, the list of responsibilities, the pressure, it’s not that it’s not significant at every level, but it gets heftier and weightier as we move up in the ranks of an organization. So I think that’s one factor, is that often it gets pushed to the bottom of the list because there are so many things that have risen above it, that we know in reality they’re not more important, but they oftentimes have more energy behind them, especially from the people above us. And so that’s one factor, I think, that’s really real. And I think it’s also true that especially for most of us who don’t have training on how to do this well, as the to-do list gets bigger, it is human nature to naturally gravitate towards the things that we really know how to solve, either because we have expertise in it or because it’s very straightforward or it’s not uncomfortable, there isn’t emotion attached to it. And that is natural.

It is typical of us as humans that we do that. And so it’s easier to check off the box on something that we either know how to do or that’s very straightforward, black and white. And that means that the softer but equally powerful, in terms of their impact on business performance, softer factors don’t get the attention that they really need. And that builds and results in what ends up being actually an incredibly negative impact on organizational performance. My experience is if we can give our managers just some support, some direction, keep it straightforward, don’t overcomplicate what’s most important, that’s a great service. In my decades of working with leaders and managers, I have met very few who show up at work each day intending to disengage their people. Nobody wants that. That’s not anyone’s intent. And so we can make it easy for managers to be able to support the people beneath them, that we see it happen, but we do have to empower them. We do have to support them.

Shane Hastie: A lot of really interesting and powerful stuff there. Dr. Natalie, if people want to continue the conversation, where do they find you?

Dr. Natalie Baumgartner: Please. I would love for you to reach out. I am on LinkedIn, so Natalie Baumgartner. I’m on Twitter, ask_dr_nat. And of course, I really would encourage you to check out the Achievers website. On there, you’ll see a link to the Workforce Institute, and there you can access our research reports and other thought leadership we have and other ways to get in touch with us and to become a member of the Workforce, which is no cost, no strings attached. We’re, like I said, a bunch of nerdy scientists who are dedicated to using research and data to change the way the world works.

Shane Hastie: Wonderful. Thank you so much. And I’ll make sure we include those links.

Dr. Natalie Baumgartner: It was a pleasure talking with you. Thanks very much, Shane.

Mentioned

About the Author

.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.


Truist initiates coverage on MongoDB, Confluent, HashiCorp, JFrog with buy ratings

MMS Founder
MMS RSS

Posted on mongodb google news. Visit mongodb google news

cloud computing. The data transfer and storage concept consists of a white polygonal interconnected structure within it. Dark blue background with small padlocks scattered on the background.

TU IS

Investment firm Truist initiated coverage on cloud computing companies MongoDB (NASDAQ:MDB), Confluent (NASDAQ:CFLT), HashiCorp (NASDAQ:HCP) and JFrog (NASDAQ:FROG) on Friday, giving all four buy ratings for different reasons.

MongoDB: Jump gave a buy rating and a $300 price target to MongoDB (MDB), pointing out the company is “at the crossroads of the data revolution,” as it have significant prospects in both applications and data.

“Given the significant growth in both applications and data that we stand on the cusp of through the remainder of the decade, we believe that the market expectations for MongoDB are underestimating both the strength and durability of their revenue growth potential,” Jump wrote.

The analyst added that once the company reaches breakeven profitability, additional investors may come in and provide stability for the stock.

Confluent: Analyst Miller Jump started coverage on Confluent (CFLT) with a buy rating and $35 price target, noting the company is a “leader” in data-in-motion and has positioned themselves in the enterprise tech stack as a piece of growing importance.

“As data volumes grow, we see Confluent as positioned to benefit via above market-growth rates and operating leverage,” Jump wrote in a note to clients.

He added that he believes Wall Street likely underestimates the durability of tailwinds Confluent (CFLT) has and its technological advantage.

HashiCorp: Jump started coverage on HashiCorp (HCP) with a buy and $40 price target, noting the company has “developed a foothold” inside the core cloud IT stack and its familiarity with the developer community via open source offerings should help them.

“We believe that the cloud transition will support an avenue for durable growth into the future and that the business model will see leverage on the bottom line as the company matures, driving results that are ahead of current expectations,” Jump penned.

JFrog: Jump also gave a buy rating to JFrog (FROG), along with a $30 price target, noting it is the leader in binary management and has demonstrated a “robust value proposition” at the core of software deployment.

“In our view, the company has built out a compelling suite of products and will benefit from upsell opportunities for years to come,” Jump wrote, adding the company’s “balanced approach to growth and profitability” is likely to be viewed favorably, given the current climate of the market.

Earlier this month, investment firm Monness, Crespi, Hardt stayed cautious on MongoDB (MDB), despite the company reporting better-than-expected results and guidance.

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

Subscribe for MMS Newsletter

By signing up, you will receive updates about our latest information.

  • This field is for validation purposes and should be left unchanged.