So, thank you all for hopping on the webinar.
I think we, you know, we picked a pretty good topic this week that hopefully will be pretty valuable to those that are really hands on involved with running dev efforts and just product development efforts overall.
So, the title that we decided on for this session of ENO8 answers is seven strategies for keeping your developers happy.
And you know, there’s, there’s various people on the team.
I think one of the things kind of interesting about building products is that people underestimate how much of a collaborative effort it is.
They always think about developers.
But you know, they’re usually the biggest number of resource types on a particular team.
So I thought we’d start with this one and we, you know, depend on how this goes.
We may come back and do a similar session on other types of team members that are involved in the team.
So, but today we’re gonna kind of focus in on developers.
Just a little bit of quick information about me if you if you don’t know me already.
My name is Jeff Francis.
I’m one of the co-founders of N 08.
We’re in 5000 innovation studio based here in Dallas, Texas.
I’ve personally helped over you know, 100 new products get launched the market and that’s a mix of startups and larger companies too.
And so been around this a lot, seen a lot.
So hopefully I can share some experiences here, you guys can get some value out of.
So when we talk about like, like, why, why we should worry about having happy developers, right?
A couple of thoughts I had in mind here.
you know, one is we’ll cover like, what do we really mean when we say happy?
The other one is that I kind of think a lot of times the developers are sort of the unsung or underappreciated heroes on, on project efforts.
And then a little bit about the cost of unhappy developers versus the gain from, you know, satisfied development team members.
And then just how does this kind of like, like help you when it comes to a competitive job market?
So when we say happiness, we, we mean it as an umbrella term to include, engaged, fulfilled, empowered.
and you know, continually learning, I think that’s a, that’s a common thread that I see as well.
Developers are often unappreciated heroes of the product team.
and they, they, they often bear a huge load for developing because they’re bringing someone else’s vision to life and they’re often thought of sometimes as, as replaceable or they end up being kind of invisible within the organization.
And I think even in large organizations, this happens a little bit more where executives are interfacing more with maybe product managers or the people who are sort of managing an effort, maybe project managers, but they don’t see down to the developers that are actually like working on the development effort and understanding sort of the the type of effort and and contribution that they’re making, right?
And then you know, what, what’s the difference between, you know, happy developer, unhappy developer in terms of like its impact?
it’s actually really massive, you know, you talk about product or project cost of, you know, developer turnover or you know, kind of shoddy unhappy developer work versus those who are fulfilled and engaged.
You know, I, I’ve, I’ve, I’ve, I’ve heard some folks talk about that, you know, that the difference between an engaged and satisfied and a developer t up for success versus one that’s not it, it can be 10 X, right, in terms of what their output and impact is and that kind of ties into the job market, right?
So the job market’s been so uncertain and volatile, especially over the last couple of years and that can affect the the the software product effort, right?
a lack of familiarity with the product, organizational goals, the solutions in place and those that might be need, et cetera affects sort of the annuity and growth of the product.
So the best case scenario is to hire a phenomenal team and then pour into them so that they stay and they thrive and they’re engaged and productive and, and really a big contributor to the product effort, right?
So the sort of the case of why what we’ve done in terms of breaking this down on how we’re gonna kind of look at all these different seven items, we kind of broken it down like this, a root problem, a new perspective to consider and then action steps.
So we believe that that change is easier when the problem is clearly understood and explained from all sides.
So this allows for a little bit better empathy, right, or understanding in this case, the empathy for the for for from the developer experience, which, you know, I think if we can do that, it makes a perspective shift possible, right?
When we allow ourselves to sort of see things from a different person’s point of view, then we get insights that may not have been there before.
When a when a new perspective is available, you know, it makes taking action and making an impact much easier and you know, more natural.
So that’s how we’ll approach the seven strategies for today.
So let’s start with the first one here.
So I’ll just read these that we had, they’re a little bit wordy, but I think I want to really kind of capture, you know, what, what is sort of this problem look like when it’s showing up.
So when developers are used in the wrong roles in an attempt to save money or time the product and the development suffer, right?
So you think about when a project timeline is off track or there is reworks during a development project, developers are often the first ones to get blamed, right?
And however, product owners or executives sometimes try to save money by not spending on some of the more costly niche resources.
Some examples of that could be, you know, you know, proper solution architects or even design strategist, some of these roles that may be harder to find, they can be more expensive.
Sometimes they’re hard to keep really busy on a a product team.
One of the challenges I see with that is that hiring AAA bona fide design strategist or a solutions architect that’s really got the depth of experience needed.
It’s sometimes hard to keep them fully utilized at a product company of a certain size.
And so what they’ll do is they’ll, they’ll use developers to try to cover for that, right.
So instead of having AAA true solution architect, they’ll have a developer that’s pretty senior and give them a lot of responsibilities that come with sort of sort of planning and designing architecture.
And so that’s not great, you know, although the experience and exposure can be good, sometimes it sets them up for failure, right?
So if we look at like the perspective, right, let, let’s use the right people for the right roles.
So this is sort of the time to be honest about who’s doing what and if it’s fair, if it’s effective and if it’s ideal.
So during planning, ask yourself and your team, do I have all the resources I need to design and build a successful product, right?
Is it not being really honest if you’re in DEV, then ask our developers spending time on things that should have been handled by someone else who’s more suited to the task, right?
So if, for example, from the developer perspective, if they find themselves getting out sort of over their skis doing something that’s not really within their strength or what their experience is, then it’s important to identify.
So, you know, and in other ways, it say is it is a developer who’s maybe more skilled in execution, like like moving tickets, having, you know, the problem solve or validate or think through flow problems or maybe some technical issues that may not be a good place for the developer to be spending their time and maybe somebody better suited for that.
So the developer stays focused, So here’s an action, find solutions to fill the necessary roles, easier said than done, right?
So sometimes you could be creative to fulfill all the roles that are needed.
Some suggestions could be, you know, hiring fractional experts, or con like part time contractors.
You could partner with a development company or a studio.
You could potentially share resources with other organizations or departments.
You know, by the way, if you’re considering outsourcing or you’re trying to figure out, you know, what should I use an offshore model or onshore model or near shore?
We’ve got a really good video on how to really like, think through that and what might be best in different situations.
So if you’re interested in that, drop me a note and someone from my team will, will send you a link to that video in case you’re interested.
But there’s a lot of different ways here to be kind of creative, especially for the really niche skill sets.
Oftentimes you can have some success by finding people who are interested in just part time work.
And usually I’ve found that that fits pretty well for those needs.
So, and then if you have a consistent need for somebody more dedicated, you could look at hiring a dedicated sort of contract resource for a period of time and you’d usually need that for like several or more to make that model work really well.
or, you know, if it’s gonna be more than that, maybe looking at that, can you really, make a business case for hiring full time in that case?
Right.
So that’s number one, let’s move on to number two.
the problem and I’m gonna have to pick up the pace, I think because I want to try to get done in about 30 35 minutes.
So I’m gonna try to go faster.
Developers often have to work crazy hours or weekends to get a poorly road map product on track.
I’ve seen this over and over and over again, projects not planned properly.
Usually scope is the culprit or some sort of technical or U X design issue hasn’t really been properly out.
And the end result is we try to put more development hours in, in an effort to overcome poor planning, right?
And this is not fair, right?
And it, and it’s not good, it’s not a good way to, to operate to, to really treat really good development team members, right?
So sometimes they, they bear the the the the burden of poor planning.
So I think we can tee them up for better success by, you know, recognizing that, you know, just working harder, doesn’t usually solve most of these problems, having good planning, having good clarity and having people do the right roles will usually be the best solution to that.
So I kind of skipped over some of these bullet points, but just let me recap to just see if there’s anything else I wanted to comment.
So there wasn’t enough clarity we talked about that.
The road map wasn’t clear, you know, so that’s, that’s more about like, you know, beyond like kind of what’s in the near term.
But what is our, our sort of staged approach to building the product?
The next was the timeline was, was designated or created by someone without experience, right?
Goals were unrealistic organizational culture, prizes, speed over quality execution.
I think if you plan well, you can prioritize both, but we can talk more about that later.
No time was padded for mistakes, reworks changes or challenges.
I’ll, I’ll touch on that one briefly too because I’ve seen a lot of plans where nobody has that, that people don’t have any planned time for feedback from like user acceptance testing or just running into problems, right?
Everything’s planned, assuming everything goes perfectly and that just never happens when you’re building a new digital product.
So you have to have some kind of an allocation in there that makes sense for the unknown for rework, for unexpected things that come up.
So if you don’t have that in your plan, you’re already gonna miss your timeline, probably your budget too.
So the perspective here, I kind of touched on this, it isn’t fair that a poorly thought out scope or wrong allocation of resources must be solved by burning out the developers, right.
So action check assumptions about the project scope and how many resources should be allocated if it’s too late, then own it.
So, being thorough during the planning phase may be may mean going slower at the start, but the path to completion is faster and less scramble later on.
developers who face challenging yet reasonable goals for sprints are usually more inspired by the wins and the pace, right?
They don’t want to get stuck either.
It’s kind of defeating one way to make sure that the goals are on track is to involve the developers in the road map and timeline, like get them involved in the planning phase that gives them a lot of ownership.
So, you know, who knows better, how long a feature is gonna take than the developers that are gonna have to build it, right?
And so if planning is done and it’s, and, and it’s clear the timeline cannot be adhered to without sort of, you know, leaning too hard on the developers time, I think you need to consider reworking your timeline and being realistic.
And a lot of people avoid that because sometimes that avoids a lot of hard conversations.
But when you see that being honest to yourself about it and figuring out how to back up and you know, actually address it and communicate it to everybody.
I think it’s the best path and you know, think about, think about this in terms of like launch dates, right?
So sometimes there’s a next launch date for some reason.
So if that can’t be pushed, then at a minimum on what happened, acknowledge the developers sacrifices that they’re making and the time they’ve spent, you know, weekends nights extending themselves, that kind of thing and make sure they get, you know, some appreciation for that, you know, in front of the right people, right?
And so at the very minimum, I think that’s something that, that can help.
Let’s move on to the next problem.
Developers are not having enough time to code.
So most of the best developers that I’ve worked with on product efforts, they want to spend most of their time writing code, that’s what they enjoy doing.
And if they’re really talented at it, sort of their unique ability.
And so that’s what we spent most of their time doing, but it’s really easy to slip into like a, a scenario where they’re spending a lot of time in meetings, they’re spending a lot of time talking about things, debating things, trying to plan things.
and they’re not spending that much time coding, right?
So if we shift to the perspective, like set developers up to be coding as much as possible, right?
Like I said, this is our sweet spot, this is their unique ability, that’s what we want them doing most of their time on anyway, Right.
So the, the other part of it is that I think they’re really good developers, they take a lot of pride in getting things done and, you know, moving tickets, right?
And that’s sort of one of the questions I go to is like, are we moving tickets?
That’s a good indicator, you know, at sort of a micro level on, you know, is the effort moving forward.
And so set them up to, to fill and, and be successful.
And one small thing that can kind of be a step for that is making sure that most of their time is focused on actually working on tickets and getting things moved.
So some of the actions here, I’ll kind of read through these, so see if it works.
So developers know exactly what they need to do with their time and they can do it.
give them tickets to knock out, which I just mentioned, conduct clear backlog, grooming, product planning and sprint planning.
These are important, right?
If you’re, if you’re not following a process, typically, what happens, you’ll burn a whole lot more time having to do the things that you should have done in sort of proper like ceremony management.
And so if you’re skipping backlog grooming or if you’re not doing your your product planning or your sprint planning meetings, and you’re trying to figure that out on ad hoc calls, you’re gonna drive people crazy.
So I think sticking to those ceremonies and making sure that, that those are getting done the right people are involved with it.
And then by the time that the tickets get teed up for a sprint, they’re groomed, they’re estimated they’re reasonable.
And, you know, I’ll go into some more details about other things that you want in there, but make it easy for the developer to pick it up, know what to do and move it and they get a good boost, you know, they feel good for moving.
There’s something mental about ticking things off of your list or moving tickets over.
So another one here and sure tickets are always estimated.
I just mentioned that that’s a big mess.
I see that all the time where people plan sprints and the tickets don’t even have effort estimated on it, right?
And then they, you know, they’re, they’re they’re unhappy with the developers because work’s not getting done well, if you don’t have tickets that are estimated, you can’t say that work is not getting done because you have no concept of how to quantify the work, right?
So you need to have a clear picture of how much in terms of points or hours that you’re expecting a developer to to complete each week and all those tickets need to be estimated, right?
So that way you have some way to evaluate that using real data, right?
And then one that I see here too.
Is that, that, that, that Devs will, will get asked to do things that don’t have a ticket.
Right.
Or they work off of a ticket, they’ll start on 11 item and they’ll veer off into something else might be related, but it’s not defined in the ticket.
So, one of the rules that I like to have down is developers have the authority that if you don’t have a ticket, you don’t work on it, right?
And that forces the process to get followed, at least for getting work on their plate, right?
The other thing about no ticket, no work is what good is it to a developer to do the work?
If there’s not a ticket that demonstrates what they have actually been working on or completed?
Right?
So always make sure they have a ticket.
next problem, retrospectives aren’t conducted or developers are left out of them.
you know, especially in smaller product teams, you know, small medium-sized companies.
So, you know, let’s say product efforts that are, you know, five people to maybe 15, maybe 20.
One thing that happens a lot is people will skip retrospectives like we don’t have time for those is what I will commonly hear.
And I understand that I understand that logic sometimes maybe you don’t do retrospectives every single time, every, every single sprint, but you have to have some kind of regular cadence to those, right?
So And, and in other words, the pro the essence of the problem here is that developers don’t have a opportunity to be able to raise concerns or feedback or suggestions.
So there not getting heard.
And there, there are some of the the best sources for understanding what’s really going on in the project.
So here’s a perspective, retrospectives enable faster, better future work.
And developers have a con have key contributions to make.
So the the whole, the whole premise behind making sure that you do your retrospective is that it’s, it’s really an investment in velocity improvements in the future.
So if you get good feedback, you have good conversations, you document it, you put it into action, the next sprint, you get faster and better and you also have happier developers.
So the action here would be do retrospectives with the entire team at the end of every sprint or at least every few sprints.
So even if you can’t make it work because it schedules.
and, and the amount of meeting time, the whole team is doing every sprint at least get it in maybe every other sprint or every third sprint at the very, very best.
All right.
Next problem, developers miss out on the payoff of showing casing what they felt very often someone else is demoing.
I think, I think again, if I a lot of my thoughts on these slides are stitched together from thinking through, like, what are some of the best developers that I’ve worked with over my career?
And the ones that I think like another common element that, that, that I’ve thought about is that they, they, they like one or two things they like seeing their, their work actually out in the wild.
So if they built something and it’s live and it’s in production, it’s getting used.
They take a lot of pride in that.
The other one is being able to show off what they built, right?
So think within the process of building and launching a new product, if they have that opportunity to be able to demo that and showcase off their work, a couple of things will happen.
I’ll talk about that next.
So so in terms of the perspective, demos, display the results better than status reports and updates and the best people to do demos of their work are the developers.
So if you’re doing, you know, if you’re doing sort of basic process, you probably got some kind of status reporting cadence up to stakeholders.
And you know, those can say a lot of things, usually they’re, they’re talking about like what we call it, the triple constraints, it’s budget scope and timeline, right?
And sort of, you know, what’s the health of those three elements.
But in, in my experience, nothing lets you know what’s going on better than seeing working software or not working software, but it’s better to demo it, right.
So I like to demo at the least every sprint sometimes.
More often than that if needed.
But, but different people will demo a lot of times.
So a lot of times the demos are done by maybe a product person or A Q A person.
But I’m a pretty big fan of letting developers demo their work.
So that kind of leads us to the action, do demos and whenever possible, let the developers do it, they just, you know, they take a lot of pride in showing off their work.
The other positive byproduct of doing this, I think is that if a developer knows they’re the ones that are gonna be demoing in front of the group or an audience, there’s more, there’s a higher level of accountability there to really make sure that what they’ve built works well and it’s not gonna have issues, right?
So demos go smoother.
So I’m a big fan of letting developers demo for lots of different reasons and you know what, when it works well, they get a lot of public recognition for their work and appreciation for what they’re doing.
So next problem Q A hasn’t properly detailed out what are the acceptance criteria for work items or tickets leaving developers with unclear expectations for approval.
In short, the tickets aren’t baked out, right?
So one of the important things is when you’re creating, you know, we I I refer to them as tickets.
But when we’re talking about like stories or features or task, whatever your organization refers to them as that whatever is in your ticket, it’s got to define what the scope is.
But, but one of the elements that’s really important to get from your Q A team is making sure that the tickets all have clear acceptance criteria.
So in other words, when the developer’s done and they send it to Q A, how, what, how do they know what steps the Q A resource is gonna take in order to determine whether it passes or fails?
And so another one here that gets overlooked, people get in a hurry, they’re just putting titles on the tickets, maybe they get lucky and there’s some description but that’s not good enough, you gotta go further, you gotta make sure that it’s really detailed out.
You gotta make sure it’s got accept its criteria in the ticket.
So here’s a perspective, clear success parameters, help developers spend their time wisely on what matters and lead to a smoother project and better product, right?
And, and having acceptance criteria is one way to really contribute to that effort.
The another great benefit of this is if you’re seeing a lot of back and forth where where tickets are going from developer to Q A and getting rejected and going back to the developer and then going back to Q A getting rejected and you’re seeing a lot of that back and forth stuff.
It’s probably because you don’t have acceptance criteria in your tickets.
So if you tighten that up, that will really help make sure that that pass rate when a developer is handing it off to Q A goes up a whole lot.
So, so actually, you know, like I, like I just mentioned, developers hate seeing tickets come back because a lot of times it’s a pride thing.
The developer passes the ticket on to Q A, it gets failed and it kind of looks negative on them, right?
It doesn’t feel good, it doesn’t feel like you’re being set up for success internally.
So get your tickets queued up with good acceptance criteria.
You’ll see your acceptance rate go up, you’ll also see developers feel better about making sure things pass the first time.
And also Q A is gonna feel better because they’re not gonna get frustrated by continuing to have to retest things repeatedly.
Let’s see.
Next one is developers are thrown into working with technology, they don’t know or aren’t given proper ramp up time to learn new technology.
Let’s be really honest how many people have seen this or even done this?
I I’ve, I’ve fallen victim to this, right where I think the technology is close enough and somebody has experience and you, you know, you try to make it work, right?
And so I think you gotta be really careful with that.
So the perspective is a developer knowing one technology and this is one example, right?
So a developer knowing one technology, for example, React doesn’t mean they can instantly pick up a similar technology or framework like angular in this example.
So you know, put the developers on what they know and give them adequate time or give them give them adequate time to ramp up, right?
So either make sure they’ve got the experience, they’ve got the knowledge and they can jump in and there’s not going to be some sort of a, a learning curve or if there is a situation where you’re having to res skill, a resource or you’re having to ramp up a resource on a new technology.
You, you gotta make you plan for that, right?
So as an example, if you’re expecting like let, let’s just say you’re expect the, the way you measure output per week is story points and you’re expecting like a a mid-level dev to complete 15 points a week, right?
If you’re putting them on something that’s AAA varying technology from what their core is, let’s say that you’re taking somebody and you’re trying to get them familiar with react when they’ve been working on angular, right?
Yeah, those are both javascript framework, but that, that doesn’t mean there’s going to be able will like be as effective on one versus the other immediately.
So you just got to plan like, you know, how many sprints.
Am I gonna need to build in some learning curve time there for them to get up to speed?
And the other element of this is the human element of making sure that if a developer is taking on a new technology, is it something that they understand and that they want to do?
So, this isn’t really on the slides, but now that I’m talking about, I think this is a really important element.
You don’t want to just give that to them and, and, and, and, and sort of like create a situation where they’re doing it, even if they don’t want to do it, you need to make sure you have a good conversation to understand what their career goals are, their interest within the technologies they’re familiar with and, and try to create alignment there to make sure that they’re getting up to speed on something that they feel like is a good investment for their career, right?
So in action, I probably talked through some of these make sure developers are working on technologies they have experience with or if they’re re skilling or learning a new skill plan to accommodate the learning curve.
One of the way to support them is, is there any kind of continuing education, any mentoring from other people on your team that you can connect them with like buddy system that works really well.
Invest in them.
I, I think if you’re gonna get them to res skill or you’re gonna get them to take on a new technology, have reasonable expectations about their output and figure out ways that they can feel supported in ways of education and peers that can really help them kind of get up to speed on that.
And, and if you do that, I think they’ll be really excited about it.
That’s been my experience.
And so, you know, that gives a, you know, the last thing here is just make sure you’re being reasonable about like sort of the learning curve.
OK, I think we’ve pretty much made it 27 minutes so far is what I’m showing.
So, how about this Q and A, if you guys have any questions, can you all throw that into the the Q and A window or the chat window and I can take a couple of questions while we’re waiting to see if anybody has any.
I’ve got, I’ve got one that our team had that somebody had submitted beforehand, so I can kind of talk about that one.
But if you guys have a question or even just feedback or a comment, love to hear some perspectives on this.
So throw that in the chat.
So the question I had here that was submitted earlier was how do you determine when to invest in a developer and when that investment won’t be, won’t, won’t be well spent.
So, I I, the way I’m interpreting this question is investing in a developer kind of on the, the previous slides we were talking about on, you know, re skilling or getting them up to speed on a, a stack or a technology they’re not real experienced on.
So how do you determine when to invest in a developer and when that investment won’t be well spent?
I mean, generally speaking, if you’re not willing to invest in the developer, I think you need to take a good look at that, right?
Especially if these are people that are part of your permanent full time team.
If you’re not investing in them, they’re gonna go somewhere where someone will invest in them.
And the best developers, you know, thinking back like what I said earlier about thinking of some of the best developers that I’ve worked with another common thread is that they’re always wanting to learn, right?
And they would do it whether you, you, you make that mandatory for your organization or not.
And so I think you have to think of this as like, what’s the investment, but what’s also the potential cost of not investing in them.
You know, in terms of, you know, purely sizing up like an investment in the example.
Like we talked about like getting a developer to try to pick up something they haven’t really worked on before.
I think, I think you have to look at in terms of the cost of time, like, what’s the learning curve for somebody to really be productive on that versus the alternatives?
And the alternatives could be hire someone else, get a contract resource, get a partner for that piece of it.
Those are alternatives that I think you have to weigh against kind of, training or re skilling somebody.
, the other, the other cost could be potentially if the person really doesn’t want to do it.
I’ve seen that a lot before too.
They’re not interested in it, right?
Especially if it’s viewed as sort of re skilling on an older technology, right?
So if somebody’s got experience in something and they’ve moved on to a little bit more modern technology and they’re getting asked to work on something that’s sort of viewed as going backwards in time.
They’re not gonna like that.
And I’d be really careful about that because that could have a really high cost in terms of the person, you know, not being happy in, in the role.
So, I hope that helps.
let’s see, there’s another question here.
Yeah.
let’s see.
How do you fight?
Let’s see.
Thanks Jeff, great topic.
Good to see you again.
Hey, it’s been a while, man.
Thanks for joining in in addition to keeping developers happy and motivated.
How do you fight attrition and retain them despite 100% heights offered by bigger companies to attract them and natural to go after it.
Yeah, I mean, you know, this is, this one hits close to home you because especially over the last year or two, the, the, the compensation market for developers has been bananas especially in offshore teams, I mean, in the US too, but like kind of all over.
But I, I, I think because we have a lot of team members in India and I think, you know, seeing what, what’s happening there with costs and, you know, another thing that I think is happening in the marketplace is that, you know, sort of during COVID when everybody went to a little bit more of a remote or distributed team model across the board, especially in development teams.
a lot of us companies are working with people directly, in, in places like India, and elsewhere.
And so that I think that impacted rates pretty significantly for a while.
But what I have seen over the last few months is I have seen a lot of that starting to correct.
Right.
Those, those, those rates and salaries I, I, I believe are gonna start to normalize and I don’t expect that we’ll continue to see these sort of like 100% hikes, that maybe we saw there for a little while.
So I really think that in hindsight once things settle down a little bit that that’ll be viewed as sort of a spike or a temporary spike and it’ll normalize.
But in terms of back to, you know, keeping developers happy and motivated the reality is it’s a super competitive market.
And I think that you have to, to build an optimized team based on the budget that you have to work with.
And so for example, a really common mistake that I think people make is they want, I want all senior devs as an example, right?
And that’d be great, right?
Like, you know, if you can stock a team full of senior devs, but you may not have the budget to do that.
And even if you had the budget, it may not be the most efficient and optimized way to create an effective team.
So I think maybe evaluating what the right mix of skill levels and expertise is for the team could help, you know, maybe optimize the team that, that if you lose people, you’re, you’re losing it according to sort of your plan design.
And it’s good for you and it’s probably good for them too.
If they don’t fit into that, it’s better for them to move into a situation.
It’s gonna be a better fit for them and their career also, right?
I think if there’s anything else on that, how do you find nutrition and everything?
Culture is the other big piece of it, right?
You know, there’s a really well known saying and it’s by no means anything that I made up.
But, you know, culture, each strategy for breakfast.
And I think that, that, that at N O A, the more we’ve made culture a focus, the better success we’ve had at, at retaining and keeping developers.
And even when it comes to some of these tough conversations about, you know, what’s happening in the market, that kind of things, we’ve had a lot of success doing that.
And I think that’s probably largely in part of the culture.
And I’ll give a shout out to my business partner Rishi.
That’s something he’s really focused on a lot over the last couple of years.
And, you know, I think that, that we’ve done a good job on that and, you know, culture is one of those kind of things that’s sort of hard to define, but you, you kind of know it when you see it, but some certain elements of it that, that I think are, have been important to us is acknowledgement and finding ways to make sure that people get recognized for things very regularly in real time.
being included in the conversation.
And we do a monthly town hall, we invite everybody to be there and we have like sort of open session where people can ask any questions and we include them and understanding the vision of the business and where we’re trying to go.
I think that really enrolls people in sort of our mission at what, what we’re trying to accomplish.
The other one that we put in place that I think has been pretty effective is paying for continuing education.
So we actually pay for that for, for our developers to be able to continue to learn and develop new skills.
So, yeah, I think those are a handful of things off, off the top of my head.
I hope that I hope that helps on.
Good to see you.
Thanks for joining me in today.
Let’s see here.
Give it another minute or two to see if anybody has anything.
While I’m waiting to see if there any other questions come in.
I will just kind of remind you guys if we got, we got a couple of things that, that we, we’ve gotten really good feedback on if you’re interested, we’ve got a, a weekly email that goes out.
It’s not a, it’s not a marketing I email, it’s, it’s really just education information and we talk about all things digital innovation.
So it’s very focused around building products that people love products that really make an impact and it touches on a variety of topics that sort of surround that theme.
So, we usually send those out about once a week.
Promise not to spam you.
So, if you’re interested, There’s no link on linkedin, send me a direct message with your email address, we’ll get you added there.
We also have a newsletter that goes out once a month.
It’s got some good stuff in it.
and a handful of other things like we’re really working hard to try to bring a lot of content.
So would love to get you guys included in that.
And if I’m not connecting you on linkedin, you know, please reach out, love to connect that way.
Great, cool.
Yeah, thanks.
ok, guys, I think that covers it.
if I don’t let me check again and see if there’s any last minute questions, if there’s not, I think we’ll wrap up.
We were just a few minutes long, but would love to hear some feedback from you on the topic.
So, if you have a chance to drop me a note, or send us an email, let us know what you think.
Or if you have other, topic ideas that would be valuable in the future, we would love to hear about that again.
Thanks guys.
I know we’re getting kind of close to Christmas.
So happy holidays, everybody and, appreciate you joining in today or watching the replay of the video if that’s how you’re checking us out.
Thanks, everybody. Talk again soon.
