In this session, Sagi Rodin, our CEO, will talk about the do’s and don’ts in the effort of overcoming the developer fatigue, and how to keep innovating under pressure
So welcome, everyone. We’re happy to have you. I see a lot of new people tuning in, and that is awesome. Feel free to engage with us in the chat. Tell us where you’re coming from. Ask lots of good questions and watch out for Tomer who’s in the chat and will be assisting getting those questions answered and those discussions moving forward as Sagi is presenting. So thank you, everyone, for joining us.
And over to you, sir.
Thank you very much, Elle. So I would like you to imagine a scary thing. Imagine that in your workplace, every developer just goes home and don’t come back. That’s a scary thought, right?
So, wow, wow, wow. We don’t want that to happen. So today we’re going to talk about how we’re going to keep our developers happy because there’s a lot of fatigue happening and a lot of churn, and it’s hard to retain engineers and developers. So let’s talk how we can do that even under the great pressure of working in a modern workplace.
Before that, a bit about me. So I’m Sagi. I’ve been developing full-stack since I was 15, before it was too popular to do that. I managed R&D in startups.
I developed high-scale applications and modern applications at larger organizations like Check Point, largest cybersecurity company in Israel. And I’m the founder of Frontegg. Frontegg is a next-generation user management platform that allows organizations to go to market much faster by integrating essential self-serve capabilities into their products.
And I also love playing the piano, as you can see back here. Yeah, sometimes I get some time to touch that thing. So let’s move forward. Developers are probably, yeah, the most important asset in your company.
Let’s touch on a few stats. So 22% of growth rate, and I assume it’s going to be higher than that, and that’s only in 10 years.
That’s a huge growth rate in this occupation, comparing to other occupations out there, which are only about 8%, right? So it means that there’s going to be more need of developers. And if you think of it, it only makes sense. There are more tools and frameworks.
There’s much more money deployed into high-tech. Almost any profession you are going to study and any education you’re going to get, let’s face it, you’re probably going to do software or at least work closely with someone who does. Now look at these numbers. It’s crazy, right?
Developers are hard to get, but they are also hard to retain. And as a matter of fact, your best friend at work, a developer that sits right next to you, is probably entertaining another offer from another great company just as we speak. That’s a scary thought, right?
So you can call them and just ask them if they do. Maybe they’ll take you with them. No, I’m just kidding. Now, according to TechRepublic, there are almost no good developers available at the market. So you see only 6%. Now, 64% of HR professionals believe that it is going to be their biggest challenge in the year ahead getting software developers, right?
So others have ambitious recruitment targets, right? So 14.4% say they plan to hire 50 to 100 employees last year. So that’s crazy numbers. Everybody wants to hire developers. And, well, that’s your HR scratching their heads trying to understand how to deal with this information.
Now, what makes developers want to stay at their jobs? So we went and conducted the research among more than 200 software developers. And the second-best thing that came up is coding.
They love coding. Isn’t it a surprise? By the way, you can guess what was number one. But most developers remain detached from the core business. So we like to look at this problem from the developer’s standpoint.
So according to the survey we conducted, approximately 60% of them testified they spend up to 10 hours a week only on improving and building features that are in the core offering of the companies they work for.
And we think that developers need to be involved. Not only does it improve the quality of code, but it also helps the developer retention, right? So how are the employed developers spending their time? What are they doing in the rest of the days? Well, most of their time is spent dealing with meeting, fixing bugs, writing documentation, and security.
Not to say that all these things are not important and are not part of the job, but only one day goes to building core capabilities. So you can just imagine that when a PR goes out telling about a huge product release or about the funding raise or other exciting stuff about the company, most of the developers feel that they are disconnected from these endeavors.
And this is, I think, very, very disappointing. So how we bring the developers from this fatigue to being happy? Let’s see a few guidelines that worked for us and see how we try to deploy it in our organizations and how, from discussions with other companies, we saw them deploy the different tactics.
So first of all, it’s about discussion. We want to make sure that everybody in the organization understands and aligned with the notion of spending more time dealing with the business, dealing with the customers, understanding what’s the core value of the company, and, well, what brings the money.
The second thing is measure. We want to deploy some tools to be able to measure the level of involvement of developers in dealing with development of core capabilities. We want to make sure that we define where we’re at today and where we going to go.
So, for example, if today developers are spending x amount of time, like we saw, approximately 10 hours on average in a week dealing and developing these cool features of the company, maybe we want to be at a 2x place by the end of the year.
So have them spend much more time doing cool stuff. And the last thing is leverage tools and best practices. So let’s try to make sure that they don’t try to reinvent the wheel every time and just utilize some amazing, great tools that we have out there today to avoid dealing with stuff that are just infrastructure and repetitive and already been solved several times.
So let’s walk through some of these topics and see how we do it. The first thing we want to do is to talk to your developers and their managers and understand their view on this.
Do they even see a problem of not connecting enough with the business, with the product, with the marketing, with the go-to-market? Do they wish they would put more time into dealing with core business as opposed to building infrastructure, participating in meetings, solving bugs, dealing with security? The second thing is that if there’s a problem, and I guess that your developers will say that they do want to be much more involved, awareness is key.
Everyone at your organization should understand that it’s important for you to lead a change by making sure engineering is going to be much more connected to the business side of things. They’re not here to only make cool technology, they’re here to make the business. And the last but not least, and maybe much very important step in getting things done is bringing the management on board because, well, nothing will move unless the management is up for it and aligned towards the mission.
In a Medium article I did back in 2018, wow, that’s already, like, almost four years ago, that was called “Lead by Connecting,” I suggested an alternative to the famous lead-by-example method for heads of engineering and engineering managers out there. And there were a few points there on how we can lead by connecting, how we can connect our developers to the business.
So the first thing as a small team, you know, that everybody can apply tomorrow, share market analysis. You already have all this information within your organization. You just need to find a path and an interface on how to share it. Maybe monthly or biweekly meetings where you present some data about the market. Talk about the deals that fell through, right?
So the sales can come and present several deals that we just weren’t able to make and see what happened there, hear a bit from the customers, and even show some recordings of sales stocks and customer feedback. Very important for the developers to hear the customers.
Field weeks. Again, another method that is fairly easy, although let’s remember engaging the management, right? You have to have the management engaged, and there has to be budgets for it. So the previous organization I worked, almost each developer goes out once in a year or two to a field week meeting with customers abroad.
And the company is investing a lot of money into making it happen because they understood that it’s very important. Talk to customers, right? Again, so we think it’s very, very important to actually bring the customers in. So there’s a lot of ways to do that. You can do some meetups with customers.
You can bring developers and their managers to sales kickoff, and many more methods to achieve that. And meetups with other employees, right? So if you pick up some meetup about the industry and let your developers hang with other developers from other companies, it could also benefit a lot.
Second thing after the awareness is measuring, right? So if we want to improve, we have to measure. So what we do at Frontegg and did in my previous organizations is start by labeling tasks. So basically you’ll be surprised how easy it is to label tasks and see what are the type of developer tasks that your team is dealing with.
And then you can use the tools built into Jira or other tools on tracking time and seeing, you know, the actual metrics that you have today to see later how you want to improve there. So we have a small illustration here on tracking times.
You can do that by groups, by users, by type of features, and so on and so forth. And define. So if you want to improve, you have to define.
So you can define some KPIs and OKRs. So we actually define a KPI around how much time developers deal with solving bugs, dealing with infrastructure, dealing with security, writing documentation, as opposed to building core functionality.
You need to see where are you at right now, right? So what is the status? Is it good? Is it bad? Compare it with different benchmarks from other colleagues in your industry. And decide what’s the level of involvement that you want to get. So, for example, if you’re leading the engineering, you can decide whether the team leaders will be the ones who lead this initiative or you want to have the developer advocate within your company to lead that.
Also, popular and happens sometimes. And, of course, that brings to the resources. So there will be resources involved, budget that needs to be assigned. You have to get the management involved and make sure that it’s important for everybody and make it happen. So this is what we managed to do in a year, jump from 24% to 37% of core task development.
And this jump happened in one year. Imagine how much impact and improvement like that has over your organizations. The developers feel that they’re much more connected to the core business that you’re developing.
They understand the needs, they understand the product, they understand the end user who’s using the product, and feel much more involved. The second thing is, we jumped from 12 hours on average to 4.5 hours on average of meeting times.
So there are a lot of methodologies today around how to make meetings much more efficient. And you can see methodologies by Amazon on this. There are a lot of organizations that are publishing their own take and methods around that. So some of the staff would be sending agenda, pre-meeting, setting the default time for a meeting to half an hour instead of an hour.
Try that tomorrow within your organization. Believe me, it works. And it’s great. You can achieve so much in 30 minutes. Most of the meetings could be finished within 30 minutes actually. So that’s the reduction that we got. Jumping from 34% to 88% of building versus buying, right, of, sorry, buying versus building.
So we are going to touch that in the next few slides, but we believe that if there’s something out there that is repetitive, already been solved by others, why we need to reinvent the wheel and build it all over again.
And it’s easy for organizations to say, “Yeah, we believe in buying when it’s possible, getting out-of-the-box solutions.” But when it comes to the decision points, sometimes, you know, they just don’t follow because they need the control, they need the customization. There’s data security, data privacy involved, and it’s hard to really decide that you’re going to embrace out-of-the-box solutions as opposed to building in-house, right?
But think of a developer that needs to build some kind of feature that, you know, they can just get from an open source or just, you know, spend some money and buy. It makes them feel, you know, not special at all. So we feel it’s important. We’re going to touch that soon.
And, you know, by basically measuring the happiness score of developers and the whole team, we feel a jump here. At the end of the day, this is, you know, the most important metric. How happy are developers within your company? And it’s really easy to measure. So, you know, that’s a great jump.
So let’s talk a few minutes about the concept of buying versus building, right? So competency in third-party integrations. You know, you should consider buying features that are close to impossible to build yourself, right? A lot of stuff around security, around billing, sending data in high scale, and so on and so forth.
The cost. You know, you would think that buying is more expensive, but actually, almost always we allocate at least 50% more than expected when it comes to developing capabilities within your application.
And focus. Is this issue at the core of the problem your product is meant to solve? Is it really worth the lose of focus from your organization? Can you really do it better than a company whose sole purpose, for example, is building this feature, or a lot of developers that gathered together and contributed to open source to solve a specific problem?
So what is it that we can buy versus build? User management, for example, data import, webhooks, right, sending hooks at scale, billing. So, you know, of course, obviously you have the payment gateways and implementing billing within your product.
It’s already a solved problem. Some of the stuff you can do like the payment gateway and actually scanning the credit card, but some of the experiences out there for tier management has already been solved, and no reason why you should build it from scratch. Reporting.
So sending out weekly reports, presenting reports within your product. Doing integrations. There’s a lot of integration platforms as a service out there that provide out-of-the-box integrations you can integrate immediately within your product. Walkthroughs, right? Appcues and other companies that provide great work through architecture.
Documentation. So there are great solutions out there where you can decide, I’m not going to build documentation in my product on my own. I can just use something out of the box, and it’s probably going to be fast, efficient. And, you know, developers won’t have to build a documentation infrastructure.
And notifications. So, you know, you want to deliver notifications to different channels, to Slack, to mobile phones. There are already solutions out there that solve that for you. And believe me, developers don’t want to build foundations like that within your company. Audit logs and compliance controls are more things that are becoming very popular today, especially due to the increase of popularity in compliance like SOC 2, or GDPR, or CCPA, and others.
So let’s summarize. What do we have so far? Developers are getting harder to get, right? There is a shortage of developers. Everybody needs developers.
The result is that everybody is just stealing developers one from another, and it’s a total chaos, right? It cannot…it’s not scalable, it cannot work this way over time. They are more prone to leave their jobs, right? So the retention of developers is really difficult. And we see that, you know, almost 50% of developers will leave their workplace, switch workplace during this year.
So we see around two or three years max of a developer staying in one company. Developers want to be much more involved in core business. So actually today they spend approximately 10 hours, only, a week delivering core functionality of your products.
That’s a shame. And the main guidelines that we saw. So first of all, bring it to the attention within your organization. I really urge for you to go tomorrow to your team and say, “Listen, let’s see, what are the developers in our company doing along the day, along the week? What are they dealing with? How much time they’re spending on meetings, how much time they’re spending on writing security and fixing bugs, doing documentation? Let’s see if we can make some change.”
The second thing is to measure what we want to improve, right? So at the first step, we get defining, but now we need to put that in numbers. And today there are a lot of tools that are making it really easy to put metrics on these initiatives. And the third is define goals.
Once you have the metrics, you want to define goals where you want to go. And the fourth thing is try to map, look at your code, look at your infrastructure, and try to map what kind of stuff within your code are repetitive functionalities that already exist out of the box through open source or other paid solutions and see how much time you spend in it.
Then map your roadmap towards the next year and see where you can utilize out-of-the-box solution as opposed to building it from scratch. I hope it was clear. I had a lot of fun. I’m Sagi, and you can ping me on sagi@frontegg.com.
You can also visit us, of course, at frontegg.com, and at our booth after the presentation. And obviously, I’m also open to questions following the presentation. Thank you very much, everybody.
The Complete Guide to SaaS Multi-Tenant Architecture
