devopsy.kinsta.cloud

Category: DevOps Culture

Will Devs Return to the Office?

Charlene O’Hanlon and Michael Davis, CRO at Rollbar, discuss findings from a recent developer survey exploring how devs feel about the return to the workplace. The video is below, followed by a transcript of the conversation.

Announcer: This is Digital Anarchist.

Charlene O’Hanlon: Hey, everybody. Welcome back to TechStrong TV. I’m Charlene O’Hanlon, and I’m here now with Michael Davis, who is the CRO at Rollbar. Michael, thank you so much for joining me. I appreciate it.

Michael Davis: Thank you, Charlene. Great to be here.

O’Hanlon: Well it’s great to have you here. I am really fascinated about a recent developer survey that you guys came out with regarding their attitudes toward going back into the office, and that’s always a hot topic among organizations no matter what they do. A lot of companies are grappling with just the aftermath, if you will, of the pandemic and the return to the workplace. If you rewind about 12 months ago, we were hearing stories about companies deciding that they were never going to have their employees come back and they were going to work remotely 100 percent all the time.

And a lot of organizations, or a lot of employees I should say, kind of took those cues and decided that they just were going to go and move wherever they wanted to. And so now a year later companies are saying, “Well maybe we should come back into the office at least part time.”

Davis: Yeah. Right.

O’Hanlon: So there have been a lot of kind of ping-ponging I guess, for lack of a better term, and I truly believe that the rest of this year there’s going to be a lot of fallout from organizations dealing with employees who are no longer able to come into the office because of their location. But I’m interested in finding out what you guys found in your survey regarding that and some of the other findings that maybe surprised you.

Davis: Yeah. That’s a great intro, although I might push us back even before COVID. I think this is especially relevant for a lot of the software development teams that we work with. If you go back before COVID, we had customers where their entire teams of developers didn’t even own a laptop. They were literally in the office all the time, every day. And so not only are companies now wrestling with this transition post COVID, but they had a huge transition they went through pre COVID, right? And that certainly put a lot of stress and strain on the companies, but more importantly on the actual developers themselves.

And so here we are now coming to the end of this, as you’re describing, and we’re going through another transition. And I agree, I think what the survey starts to show is that this is not going to be black or white type of thing. It’s not going to be all of one or the other for many of the reasons you already mentioned. The survey was very clear in that first off it said 77 percent of developers were definitely significantly impacted by COVID and what this meant for them, and now as you start to interview folks and do the surveys you find that it’s a real mixed bag. You have folks who’ve enjoyed the freedom, enjoyed that flexibility, and have started to adjust to that to some extent.

But I think one of the most interesting findings is that they’re missing that face-to-face component of their work. And if you think about developers and what they do, this is a team sport, right?

O’Hanlon: Right, right.

Davis: They’re really missing that day-to-day, face-to-face interaction, and especially given the sort of raised stakes, which is another thing that came out of this survey. What we found was sort of this external pressure on development was even raised higher. Why? Well, because customers are needing to interact with companies through software. So there’s even more pressure on building more software faster. So these are some interesting things that we saw sort of pulling against each other.

O’Hanlon: So what do you think is the answer here? I understand that developers crave that face-to-face. I also see people who are now dealing with a level of social anxiety that maybe they never had dealt with before in their life. If you’re a year away from somebody or large groups of people it can be tough to reintegrate yourself into that environment. And as much as we all say I can’t wait for things to get back the way that they used to, we can go to concerts, we can go shopping and not have to worry about wearing a mask or whatever, you put people in some of these situations and it’s difficult for them. Some more than others.

Some are just like, yeah, whatever, you know, let’s just go back and it’ll be fine the way that it was. But I’m not sure when people say I want to work with all these people, I want to get back into the scrum, I want to do this and do that, I’m just not sure when they actually do it that that’s really what they wanted. Do you think that there’s going to be maybe buyer’s remorse if you know what I mean?

Davis: Yeah, there could be. My guess – and again, it’s based on some of the survey data we’re seeing – you do have this mixed feeling about your sort of life balance isn’t necessarily all you thought it would be by being home all the time. But I think you’re going to see the same thing. If we went back full time in the office people would be feeling that same kind of pressure around the commute and the things that go with that. So my gut says that now that companies have adjusted and people have adjusted more to being away, we’re going to see this hybrid environment.

You’re going to see more of an environment where people are going to be in the office at certain times, but they’re going to have the ability to work from home at certain times, which again, carries its own set of things. We’ve seen lots of investment in tools, Zoom being one of them we’re on right now, but there’s a long way to go. Because the other thing the survey showed was that by having these distances it’s harder to get those answers, let’s say, as a developer that you might need in the moment. When someone’s not two cubicles away from you, you have to hope that they’re on Slack. And if they’re not, then you’ve got a delay and a problem.

So I think the next thing we’re seeing is we’re seeing more investment in additional tools, in additional types of processes that help this hybrid environment more.

O’Hanlon: Do you think that we’re going to see an increase in these distributed workforces on a full-time basis either as a direct result of the mass exodus during the pandemic or just because they can, that they’re recognizing that maybe we don’t have to be in the office all the time? Or Joe left and he can do it full time, so I’m going to do the same thing and what are they going to do?

Davis: Right.[Laughs]

O’Hanlon: Take away my birthday? It’s going to be one of these – I think there’s going to be this push-pull. And so I’m wondering do you agree with me? Is this something that very might happen? And what do you kind of see? How can organizations – how do you expect them to react to that?

Davis: Yeah. And I would add to the points you made one other thing, which is companies I think have learned that once you remove this need for everyone to be in the office all the time this also starts to free up your ability to recruit more broadly and it gives you flexibility to bring on the type of people you want wherever they sit, right?

O’Hanlon: Right.

Davis: So I think that’s going to play in as well, and that’s why I think it really will be this hybrid environment. So what can they do about it? Well, they’ve got to be really mindful about how people work and they’ve got to be investing. Companies have to be investing in the right kind of tools. I’ll toot our horn a little bit here. Rollbar is about this sort of platform that gives you visibility across your teams on specific errors that you have in your code.

That’s one example. If companies have tools like that in place, now you don’t have to be sitting two cubicles away. You’ve got the data you need right in front of you, real time, to be able to make those kind of decisions. That’s one example. There’s many, many more, but it’s going to be thinking about these workflows somewhat differently and making sure you have the right processes and data so people can operate more efficiently.

O’Hanlon: Yeah. It’s going to be an interesting year I think as we do kind of transition back to life post COVID or even the final throes of COVID, because so much happened over the last 12 years and it was a lot for all of us to process. And now for us to kind of quote/unquote go back to the way things were I just don’t think it’s ever going to happen. I don’t think that we’re ever going to be back the way things were before COVID, and so that means a lot of changes within organizations and among employees and their understanding of work and how they approach it on a day-to-day basis. I think there’s going to have to be a lot of giving in, if you will for companies, that they’re going to have to take a brand new tack when it comes to hiring and retaining their employees.

But employees also need to kind of understand that at the end of the day there’s a job that needs to be done and sometimes the best way to go about doing that job is to maybe be in the office or be face to face. So there is no one-size-fits-all solution here. Michael, great results. Were there any other things that popped out of the survey regarding developers and how they view work or work/life balance or salary or anything like that that you guys covered in this survey?

Davis: We didn’t really touch on salary so much. I think the big takeaway points were just how pervasive the impact was on developers and what they were trying to do. That was the first thing. The second thing then was this notion that a lot of that sort of stress and strain that was associated with this was, one, just a normal transition, but also this higher demand for software, which I don’t think necessarily any of us really predicted, and that is added to what’s already software in the world. Every company is a software company kind of thing, right? So that’s the challenge, and that’s the challenge that Rollbar and other companies are working to help this community with, because it’s tough. It’s a tough job.

O’Hanlon: Yeah. And to your point, I don’t think anybody expected it, but do you think that it’s going to be sustainable? I mean, is this something that’s going to be kind of the new normal, if you will? At least not may necessarily from a product – well, even from a productivity standpoint, but do you think the demand is going to remain as high as it has been over the last 18 months or so?

Davis: I just have no doubt about that. I mean, there was already an incredible pressure on the system. These teams are already feeling lots of external pressure about being able to deliver features and functionality faster, right? We’re all hearing about iteration speed. And so I don’t have any question now that – again, I think companies have learned that maybe they don’t need the same kind of retail presence to serve their customer base. Which again, puts just more pressure on the need for software.

So yeah, this all feeds into I think even a more challenging environment, but certainly a rewarding environment because these people are at the center of the epicenter right now of everything.

O’Hanlon: Yeah. But I do worry about burnout. I do worry about the fact that – I think a lot of people really rose to the occasion at the beginning of the pandemic and all throughout it because they did recognize that there was a value to it. They could actually see how their work was impacting their company. And I’m not sure that once we go back to kind of whatever, whatever we’re going to call it, that that is going to sustain, and it’s really going to give developers and other employees for that matter kind of the push that they need. And it does concern me that we may very well see mass burnout among developers, and that could be bad for everybody.

Davis: You’ve given me a great transition to one thing I wanted to mention, which is the next thing we’re going to be working on is some analysis around developer productivity. So I think you’re right on, spot on. I think that’s the next concern. I mean, it’s already a concern, but now it’s even more accentuated. DevOps was already a mixed bag in terms of developer productivity. I won’t spill anything, but we’re going to do a deep dive there and hopefully we’ll have some more great data for you.

O’Hanlon: Well, come back and have the conversation with me when that’s ready, because I would love to continue this conversation. There’s a lot going on in the space right now and it’s got so much more to do with just business, the business side of things. There’s a real human element to all of this and I think it’s very important that organizations keep that in mind at the end of the day and so much more. But Michael, thanks for talking to me about this survey and the results of this one.

Fascinating stuff, and it’ll be interesting to see how the rest of the year plays out in terms of everything that we’ve discussed today. So thanks again for your time. I appreciate you being here.

Davis: Thank you. Thanks for the chance to talk to you. Bye-bye.

O’Hanlon: Alright. Alright, everybody. Please stick around. We’ve got lots more TechStrong TV coming up, so stay tuned.

[End of Audio]

February 15, 2022
DevOps for Customer Experience

Charlene O’Hanlon and Amy Hudson of Cyara discuss the concept of DevOps for customer experience, which takes DevOps methodology and focuses it on CX software. But there are pitfalls DevOps teams face when dealing with customer experience software. The video is below followed by a complete transcript of the conversation.

Announcer: This is Digital Anarchist.

O’Hanlon: Hey, everybody, welcome back to Tech Strong TV. I’m Charlene O’Hanlon, and I’m here now with Amy Hudson, who is the VP of Global Center of Excellence at Cyara. Amy, thank you so much for taking a couple minutes and talking with me today—I really appreciate it.

Hudson: I’m happy to be here.

O’Hanlon: Great, great. So, Amy, tell me a little bit about Cyara to start off.

Hudson: Oh, absolutely. Cyara has been around for about 10 years at this point, but we really focus on what we call customer experience assurance. Companies spend a lot of money in designing the right customer experience and all the technology that supports it, and Cyara is in the business of making sure that you are getting the experience you’ve invested in. And if you are, how do we help you continue to innovate and double down? And if you’re not, how do we help you fix it very quickly so you can stay ahead?

O’Hanlon: Alright. That sounds great, and I imagine your business has been booming over the last year or so, because customer really came to the forefront for a lot of organizations as they kinda had to double down on their digital transformation efforts just to stay alive over the pandemic, over the last year and a half or so. And some of them have done it really well and others have not done as well.

So, what are you guys seeing in the market right now as far as customer is experience is going?

Hudson: Yeah, no, that’s a great question, because it has changed a lot in the last year, with the pandemic. I mean, listen, customers have historically always been demanding, right? That’s in our nature as customers. But now, with their hands on the technology, customers have very high expectations right now. And switching costs are low. So, if a customer doesn’t get what they’re looking for out of an experience, you may lose them.

And so, the importance of having a good customer experience and staying ahead of it is at an all-time high from our perspective.

O’Hanlon: So, we’ve been, obviously, you know, through DevOps.com, we focus on the benefits of going with a, kind of a DevOps methodology and mindset and culture shift and all that good stuff. And we’ve seen kind of that whole premise of DevOps kind of shifted to other parts of an organization as they recognize the benefits of kind of blending two different maybe mindsets and areas of an organization together to kind of streamline operations and actually build a better product in the long run.

I imagine customer service is not—has not been left out of the conversation when we’re talking about organizations adopting those DevOps principles for customer experience.

Hudson: Yeah, that’s right. It’s interesting. So, about four or five years ago at Cyara, we started seeing DevOps fold into the contact center/customer experience space, but it was a little bit more of a rarity then. DevOps hadn’t necessarily intersected with customer experience yet at that point, but over the last three couple years or so, we’ve really seen DevOps become much more commonplace in the customer experience space. Which I think is a good thing, because, exactly what I mentioned before—you need to stay ahead. You need to be able to innovate quickly for customer experience, and I think these companies are starting to see that.

So, we’re starting to see DevOps adopted almost universally. Either somebody has started it or is halfway through or a little more mature, but it’s in the conversation with almost everybody we talk to these days in terms of customer experience.

O’Hanlon: That’s great. That’s really great to hear, because there are certainly a lot of benefits to DevOps in the customer experience space, you know, not the least of which is being able to service the customer much more effectively and quickly.

But it’s not kind of a one to one adjustment, though. You know, it seems like, especially since, when we’re talking about DevOps, we recognize that each DevOps implementation and each DevOps experience, if you will, is different. You know, everyone is kind of a snowflake.

So, how does that equate to the customer experience and how might that actually kinda trip up organizations if they’re looking to kind of add DevOps to their customer experience?

Hudson: Yeah, absolutely. So, when I first started at Cyara, I led a very small strategic consulting group, and we worked with customers on how Cyara can help them through any major transformation. And because of the shift of the industry, it ended up being a lot of DevOps transformations. And so, we’ve seen customers at multiple different points in the journey, and the struggles that they’ve bumped into. And I think there are a number of different kind of pitfalls if you will, or lessons learned from that.

And, you know, one of the first things—and we can go into as many of these that are of interest, but one of the first things and most important that pops out at us is that leadership level cultural shift. I think, so frequently—and I’m leading with this because if you don’t get this part right, it’s really gonna hold you up. But so frequently, DevOps is viewed as a technical or process change and so, it happens at the day to day level. But really, it is a mind shift, cultural shift, has to be top down, has to be embedded in the culture, and it has to be leadership driven.

O’Hanlon: Mm-hmm, yeah. I agree, agree, and that goes across an entire organization, no matter where they’re implementing DevOps, whether it’s in IT or if it’s in the back office or marketing. Because we’re seeing this blending of so many different disciplines in an organization these days as ways to advance and accelerate just their ways of doing business.

But to your point, if we don’t have, or if an organization doesn’t have that buy-in from the top, no matter where they’re implementing DevOps in an organization, it’s doomed to failure.

Hudson: That’s right, that’s right. And it’s, you know, and it’s not just the kickoff, it’s not just somebody at the C level saying “rah rah” at the beginning.

O’Hanlon: Right.

Hudson: This is, like, through the process, embedding into how you motivate, incentivize, how you reward people, how you—you know, in your regular cadences. It’s everywhere. It needs to be treated as a cultural shift.

O’Hanlon: Yeah, yeah. I totally agree. Now, what about, you know, beyond kind of that initial, as organizations start to kind of adopt this mindset and these principles, what are some of the things that maybe we call it kinda DevOps Phase Two or DevOps 2.0, the Second Day DevOps—what are some of the things that you guys are seeing that organizations need to be very mindful of to make sure that they are successful?

Hudson: Yeah, another thing that we’re kinda bumping into at more of the kind of operational level is, as you know, the importance of flow in DevOps, right?

O’Hanlon: Right.

Hudson: You don’t wanna disrupt the flow. And to do that well, you have to think about automation, right? It’s just—it’s a no-brainer. It’s a pillar, right? And to me, when I think about automation, there’s a lot of different pockets you can automate. But for me, I think primarily around deployment automation and testing automation.

We did an interview—or I did an interview with a consulting, one of the big four consultants with the DevOps expertise and a customer. And both of them agreed that automating the testing, while it’s not always completely simple or straightforward, it is, they would almost consider it the low hanging fruit, right? Get the testing automated so you can just kind of plug and play that part of it, don’t disrupt the flow.

From a deployment perspective, there’s a number of different environments, right, to get something into production. So, the more you can automate from that perspective, the more you can continue to push things out and learn fast and fail fast, if you will.

And so, finding those pockets of automation and having a strategy on how you can automate as much as possible as to not disrupt the flow is something that we’re really recommending to folks to realize the total benefit of the transformation.

O’Hanlon: What about from a people perspective? You know, DevOps is as much about culture, as we know, as it is about the processes and the technologies. So, are there ways that organizations—maybe they’re not thinking about particular things when it comes to culture and people in their adoption of DevOps specifically for customer experience?

Hudson: Yeah, sure. So, I would answer that a couple different ways. The first one I would talk about is essentially around—this is, again, it’s a culture thing. One of the pillars of DevOps is to create an environment that encourages learning and a safe place to fail. And so, you want your teams to be encouraged to fail if they have to and learn from it and get better the next time and feel safe doing that. So, that’s one from a person perspective.

The other thing I would mention is just around measuring, key performance indicators, right? You can’t know if you’re successful without measuring, right?

O’Hanlon: Mm-hmm.

Hudson: And then publishing those KPIs so they’re transparent. Transparency is really important, so everybody is charging towards the same goal, and everybody feels like they are part of achieving that goal. So, let’s get the performance indicators out there, let’s be clear what we’re trying to achieve, let’s make people feel safe in that process. And, you know, that’s kinda the culture you wanna build around it.

O’Hanlon: So, when we’re talking about customer service applications and software versus, say, an internal process or internal DevOps process or an internal application that is being advanced by these DevOps processes, what is the difference when we’re looking at what may be what those KPIs are or what the service level objectives are, things like that? Are there certain things that an organization needs to be more mindful of when they’re working on a customer experience type software rather than maybe more internal focused or maybe other customer that’s not maybe customer facing, end user customer facing?

Hudson: Yeah, I think that’s a great question. And what we’re trying to do within our industry is create this mind shift where you are thinking about the end customer all the time—not just in the production environment, you are always thinking about the end customer experience through every step of the journey.

And I’ll give you an example of what I mean by that. Traditionally, the contact center space, how they would monitor things in testing or production is kind of server loads or capacities, right? If it’s reached capacity, it’ll set off an alarm and that’s a problem, right? You don’t want it to be at capacity.

Great, but you might not know what the customer experience is if that server is at capacity, right?

O’Hanlon: Mm-hmm.

Hudson: And so, at Cyara, what we’re trying to do is say—absolutely, that server might be at capacity and that’s a problem, but what is the customer experiencing in the moment right now in production? But we also wanna test in Dev and QA and UAT and performance testing, what the customer experience would be. So, if there’s an issue that comes up, you know it could be a pretty serious one, it could be calls being disconnected. If, in your revenue generating phone lines or chat windows, customers can’t get through—you wanna know that before it gets into production.

O’Hanlon: Mm-hmm.

Hudson: You don’t wanna know necessarily that—or it may be less helpful to know if a certain piece of technology is at capacity. What’s most valuable is to know what the customer would experience in that moment, even before it gets into production, if you can do that.

O’Hanlon: Interesting. You know, it’s really fascinating to have the conversation about DevOps in different vertical markets, because everybody’s got something different that they’re really, really focusing their efforts on, but at the end of the day, it really is all about just making sure that the end user experience is the best it can be, and that the application is working as advertised and certainly that there’s a level of security as well within that application.

So, I do imagine that security is also a big part of the equation, especially with the customer experience and the amount of sensitive data that a lot of contact centers, to your point, that they’re dealing with on a regular basis. So, heavy emphasis on Sec on DevSecOps?

Hudson: Oh, absolutely. And that’s really from two ends. One is that customer data, right? There’s—you have to protect that. There are sensitivities, and those need to be protected, and we need to invest in those, and you need to be able to test that in production or prior to that if possible, right?

But the other side of it, too, is around the regulatory requirements, right? Customers will—our customers, large companies—will get fined if certain requirements aren’t met, right? And so, from a pure business perspective, you’re motivated to make sure the customer is experiencing that requirement. But then from their own protective perspective, you’re also motivated.

And so, DevSecOps, we really encourage people to fold security in very early in the discussions. It’s often one of the last things to come up—“Oh, wait, did we talk about security, did we bring in that team?” Fold them in early, complete transparency, get the conversations in and weave them into the process, because it’s critical.

O’Hanlon: Excellent, excellent. Amy, this has been a great conversation. I’ve really, really enjoyed it, and would definitely love to have future conversations with you about other topics related to DevOps and the customer experience, because I really think that this is something that is—it’s not gonna be a one and done conversation. It’s like DevOps. Customer is an evolving conversation.

But for now, thank you so much for taking the time and having the conversation with me. I do appreciate it.

Hudson: Thanks for having me. It’s a privilege to be here.

O’Hanlon: Alright, great. Alright, everybody, please stick around. We’ve got lots more Tech Strong TV coming up, so stay tuned.

[End of Audio]

February 14, 2022
Great Resignation Spurs Interest in Tech Certifications
It has been almost a year since the phenomenon known as the Great Resignation started appearing in national news. The reports showed millions of U.S. workers leaving their jobs each month to look for something better. This trend, according to the latest news, is not going away.

While labor experts have provided a steady stream of speculation about why people are leaving their jobs, from frustration with pay to fear of COVID-19 to a desire to find positions that are more meaningful, they have yet to arrive at a consensus as to what those who are now out of work are doing with their time.

In the world of IT and tech, it appears that those who joined the Great Resignation are spending their spare time growing their skills and improving their resumes by pursuing tech certifications.

Tech Courses Surge in Popularity in 2021

According to Class Central, a search engine and review site for free online courses, the top online courses for 2021 were tech courses, many of which are offered by Google and provide the type of certifications that look great on a resume. Here are some examples of the top courses:
- Foundations of User Experience (UX) Design, which is the first in a series of seven courses on the topic.
- Data Analysis With R Programming, which provides training on how to “clean, organize, analyze, visualize and report data in new and more powerful ways.”
- AWS Cloud Technical Essentials, which presents the fundamentals of AWS.
- AWS Cloud Practitioner Essentials, which explores “fundamental AWS Cloud concepts to help you gain confidence to contribute to your organization’s cloud initiatives.”
Certifications That Pay Dividends

In general, certifications provide a boost to job seekers. They communicate a commitment to professional development as well as provide a reliable catalog of the skills that one will bring to a position. For those looking to stand out, certifications can definitely increase the chances that you’ll get an interview.

However, it is critical to think of the opportunity cost of an individual’s time. While we love free certifications, many of the free certifications are unlikely to help someone start their career. In many cases, after the person spends months achieving these free certifications, they will need to spend additional time getting new certifications to ensure that they have the specific certifications that employers desire. When you consider the salaries some of these tech positions command, spending months on the wrong free certifications can cost someone tens of thousands of dollars in lost earnings.

While the following certifications may be more difficult to achieve and might not be available for free, they definitely make a difference in terms of preparing IT workers for the most desirable jobs:
- Networking – Cisco Certified Internet Expert (CCIE) and Cisco Certified Networking Professional
- Cloud Computing – Azure Expert, AWS Certified Solution Architect Professional and Google Professional Cloud Architect
- Security – Certified Information System Security Professional, Certified Information Security Manager, Certified in Risk and Information Security Control, or CRISC (Note: these certifications required documented experience)
- Cloud DevOps – AWS DevOps Engineer Professional
Adding Soft Skills to Certifications

The certification process can provide the technical skills for which many IT employers are looking. And promoting certifications on your resume can significantly increase the chances that you’ll be called in for an interview. However, in my experience, landing the job is one thing; thriving in it requires a different set of skills that fall outside the realm of IT certifications.

Soft skills are not the skills that allow you to do your job, like coding or engineering. They are the skills that define how you do your job. They include people skills like networking, communication and conflict resolution, as well as creative thinking and time management. When applied to the world of IT, I like to think of them as “certifications plus.”

While IT workers often overlook the value of soft skills, I can assure you that IT employers definitely do not. With the fierce competition that exists for IT work, IT providers need every advantage they can get to acquire and retain clients. If their workers do not have people skills to pair with their tech skills, companies lose that advantage.

For those looking to boost their appeal to employers by acquiring certifications, take some time to get certified in soft skills. The courses exist and they will pay you great dividends both before and after you land the job.

Bringing an End to the Great Resignation

For IT companies, the growing popularity of certification courses may offer some insight on how to bring an end to the Great Resignation, at least within the IT sector.

Recent research showed that IT “resigners” are wrestling with many of the same employment issues as those in other industries, including frustrations with salary and the desire to have more work flexibility. However, tech workers also cited some issues that indicate that certification training, provided before employees resign, might be enough to keep them at their desks.

For example, the top reason cited by workers at tech, IT and software development companies for wanting to leave their job, other than salary and benefits, was limited career progression. In addition, nine out of 10 said they “would like to get more learning and development opportunities from their company.”

For tech workers looking for a job, “skills development” was the second-highest criteria they considered behind salary and benefits when selecting a company. More than 60% also reported that “more learning and training opportunities would make them more motivated at work” and 75% felt that their companies focused more on attracting new employees than they did on investing in existing employees.

Could it be that retaining IT employees and filling the positions left open by the Great Resignation is as simple as making certification training available to employees?
February 14, 2022
The DevOps Journey: Continuous Mindset Starts With Cultural Change
DevOps is not just about technology. In many ways, the technology aspect of DevOps is finite but the people, organizational and cultural aspects are infinite. We see many clients get so focused on the tools and technology that they forget about the impact beyond the technology. An important part of building a world-class DevOps process is understanding the cultural and organizational changes that are required to be successful and making those a priority, as well.

Many organizations have still either not started their DevOps journey or are in the first generation of DevOps, which is creating a greater gap between elite and low performers. The business changes and delivery cycles are coming faster than ever, making it critical to use world-class DevOps. Pushing toward continuous flow requires technical, process, people and cultural evolution to keep pace. To achieve continuous flow, we need a continuous mindset. A continuous mindset requires new skills, new ways of thinking, new cultural norms and new responsibilities.

Continuous Mindset, Continuous Flow

Most companies don’t realize the cultural impact a fully automated pipeline and continuous flow will have on development and operations (and beyond). Change can be difficult and organizations are often met with FUD: Fear (automation brings fear that jobs will be automated away), uncertainty (the unknown creates anxiety) and doubt (needing to employ new skills and new ways of thinking can create doubt about whether resources can adjust).

The rapid pace of business change requires more nimble, flexible and lean approaches to DevOps to meet tomorrow’s demands. This requires changes to structures, interactions, control, processes and expectations. All of these impact the culture and connections within the organization.

Let’s start by defining a few terms:

Continuous integration: The practice of merging all developers’ working copies to a shared mainline several times a day. Grady Booch first proposed the term in 1991, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day—perhaps as many as 10 or more times per day. Common continuous integration practices include maintaining a code repository, automating the build, making the build self-testing, testing in a clone of the production environment and more.

Continuous Delivery: The official definition is, “A software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing and releasing software with greater speed and frequency. The approach helps reduce the cost, time and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.”

Continuous Deployment: A strategy for software releases wherein any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software’s users. The logical next step after continuous delivery: Automatically deploy the product into production whenever it passes required validations.

Continuous mindset is intertwined throughout all three of the above approaches. To reach the maximum value in each area, a continuous mindset needs to be enabled, matured and applied to disciplines in other DevOps areas. The changes are across people, processes, technology and culture. Like DevOps, gaining a continuous mindset is a journey that will take time, many steps and constant learning.
Continuous mindset changes the way people achieve outcomes for your business. This requires an emphasis on changing the way people think at every level of the organization, the way people are connected and the way they work. Achieving true continuous mindset ROI requires significant cultural adoption and collaboration. A key component is leveraging strong organizational change management (OCM). Six OCM steps to achieving the cultural shift to a continuous mindset include:

Change management and readiness: Share with internal stakeholders where we are going and how we are going to get there. Set expectations.

Sponsorship: Create clear alignment and engagement at the executive level.

Stakeholder engagement: Get everyone on board. Identify who is impacted as well as who is responsible and accountable. Understand reactions and resistance and provide support.

Communication: Get the right information to the right people at the right time. Move stakeholders from awareness to buy-in, commitment and readiness. Communicate messages to multiple levels of the organization.

Capability development: Provide the education and training needed to be successful in the new culture.

Organizational alignment: Align roles, structure, processes, policies and systems with changes and desired business outcomes.
Shifting Responsibilities

Ultimately, a continuous mindset changes the organizational engagement model and requires organizations to align on how and when they will work together. This requires shifting responsibilities and empowering teams/individuals to contribute to the improvement of DevOps capabilities. Learning and knowledge transition is an important element to enabling the team long-term.

The organization will need coaching as they begin to understand the concepts and adjust the way they work. Different approaches can be used depending on the overall needs. This purposeful DevOps learning approach will provide DevOps coaches to engage with teams along with DevOps subject matter experts to provide input in the preparation activities. Another option is to provide less formal DevOps coaching to engage with targeted teams. This approach is less structured and primarily relies on direct engagement with less focus on the training and scaling project approach.

Transparency is Fundamental to a Continuous Mindset

Part of creating a continuous mindset involves an environment where transparency is fundamental; where everyone feels committed to the results takes ownership and responsibility for improving them. Successful DevOps transformation requires a holistic approach that includes people, processes, technology and culture. Working in cross-functional agile teams; working with small batches; working in sprints; communicating and collaborating all provide the strong foundation necessary to create a solid continuous mindset. If done correctly, breaking cultural changes down into smaller changes can ensure a certain level of quality in the long term.
February 14, 2022
Irreconcilable Differences: DevOps Grapples With Issues

DevOps issues can be a thorny subject. The coming together in harmony of Dev (developer) and Ops (operations) represents an arranged marriage of sorts that, for some, will never have a ‘happily ever after’ ending as both parties ultimately grapple with irreconcilable differences.

But despite the naysayers, the very existence of DevOps as a portmanteau (and perhaps sister labels like DevSecOps, to form a security sandwich) is, in many ways, a validation of the need to form a bond of tighter unity and harmony between two factions that have often been at odds with each other over the years.

Even with the popularization, extrapolation and democratization that DevOps has enjoyed through the last decade, not everyone will be convinced of its worth and/or its effectiveness—some even doubt its very existence. Some say that DevOps already existed without a formalized label if you look at the software development practices IBM championed a quarter-century ago.

One thing we can be certain of is that DevOps almost always throws up a few meaty bones of contention. Let’s take a closer look at these issues in the hope that we can harness some of the angst and turn it into positive energy for a DevOps-enriched future. If we are to analyze the most contentious and sensitive DevOps issues in this space, what should we be aware of and how do the big issues break down?

Is it a Bird? Is it a Plane?

Arguably, the biggest problem DevOps faces is categorizing it. Some call it a methodology for software application development. Proponents of ‘classic’ software methodologies disagree with this idea as, for the purists, a software methodology can only be Agile, waterfall, extreme, rapid, joint or Scrum.

These semantics mean that many people would prefer DevOps to be classified as a culture, a workplace ethic, a technique, a culture and/or a mindset or, perhaps in the vaguest terms, an approach. To be truly successful with DevOps you must take a holistic approach and look at the entire development cycle from beginning to end. Closely evaluate the processes that go into development to find bottlenecks and roadblocks to productivity. By finding the areas where your current processes come up short, you will be able to identify the areas to emphasize when implementing a strong DevOps strategy.

Cloud-Native DevOps

Anyone who hasn’t been living in a cave since the turn of the millennium will know that cloud computing has grown, faltered occasionally and, ultimately, blossomed to become a new standard barometer for all organizations on their journey toward so-called digital transformation.

That’s the good news. The not-quite-so-good news is that cloud (and the contemporary drive to go cloud-native) is still complex from initial deployment to ongoing maintenance, management and reporting.

Taking DevOps into the world of cloud-native will ultimately pay off, but first, there will be challenges as teams get used to the new shape, form and function of the altogether more abstracted and virtualized software toolsets.

The key to getting cloud-native DevOps right will be a prudent approach to monitoring and observability. As cloud-centric DevOps teams ingest the logs, metrics and traces they need to perform solid and dependable system observability, they will need a consistent set of tools to monitor and observe systems in the long term. Within this practice, it will also be important to remember that monitoring shows you lower-level granular information related to system performance. Observability includes all the information gleaned from monitoring and also includes higher-level tools, some of which will be data visualizations for DevOps practitioners to use. When the two are combined for cloud-native DevOps, system health can be optimized, preserved and maintained while any debugging or root cause analysis is executed at the lower level.

Machines in the Application Loop

With machine-to-machine events now happening more prevalently inside the internet of things (IoT), the need to capture, integrate and analyze the event streams that go on outside of the human loop and bring those log metrics back closer to the sphere of ‘human’ software engineering is not a plug-and-play quick fix.

Getting machines to play nicely and be a part of expansive and progressive DevOps teams should be a given. After all, they’re just machines. In reality, there will be specific skills needed and human DevOps personnel will be required to get used to updates and other alerts that they have not considered before.

AIOps and Automation Limits

Related to our last point on machine events, we need to think about AIOps. When we build AI-driven DevOps and create AIOps, we will need to stop and question where we set limits on process automation and where the wider elements of automation hit the limiter/restrictors. To know just how far we should build out our AIOps practice, exhaustive auditing and analysis must to be carried out; the whole technology proposition here is no simple point-and-click affair. Even when we do establish workable AIOps, know that there will be perimeters.

Add all that to the fact that some AIOps implementations will require what we like to call ‘human handoff’ support when the AI intelligence engine doesn’t know what to do next and needs additional data and training—only then can we start to appreciate that AIOps itself is no simple plug-and-play affair.

Lift and Shift Doesn’t Scale

One of the unfortunate truths in too many real-world IT shops today is that, where the cloud is used, it is used poorly. Too many technologies are unceremoniously lifted and shifted to cloud instances that an organization procured. This makes cloud-centric DevOps harder to achieve. But why?

Because what happens back down in terrestrial (i.e., non-cloud) programming is the development of individual cross-functional software teams. This silo-based approach happens due to corporate legacy structures, company management systems and, sometimes, for personal, parochial or cultural reasons. When different teams are all reinventing wheels (running diagnostics tests, setting up CI/CD pipelines, delivering upgrades and so on) that should be shared and accessible to all, a natural level of inefficiency surfaces.

DevOps Issues: Conclusion

These are the five most contentious DevOps issues in the near term, and it would, of course, not be too hard to find and categorize even more. In the future, we might even need to argue over which developers should be categorized as core devs and which core members of the operations department to include.

For software developers, software architects—really, all the software engineering professionals who work in systems administration, database admin, testing, security and all other forms of operations—there’s quite a lot at stake and quite a lot to fight over. And if you ask me, that’s what makes DevOps great.

February 11, 2022
No Matter How Things Change, Have a Plan

Had enough change yet? It is almost amusing that I and some other tech people had that conversation a decade ago, and since then, nothing has slowed down. Our conclusion was that, for the near future, change would be constant. That conclusion was right; I’d have to ping everyone else to see what they think, but “near future” turned out to be longer than I expected.

Inevitably, though, change requires taking a breather at times. It appeared that high-tech was finally ready to admit that burning out your staff was not a viable long-term business model, and was slowing down … and then, COVID-19 hit. Now I’m hearing rumblings about going back to non-stop change as if the last couple of years were a vacation and staff is all rested up and ready to replace massive chunks of the infrastructure.

The reason that change requires intermissions, though, is not 100% about staff and burnout. That only shows up when you’re making a ton of change non-stop. Before staff burnout becomes an issue, recovery and business continuity plans become outdated. At the rate we’ve been running, I’d go so far as to say they are likely useless.

Yes, all this change has brought us some cool stuff. While we are busier, some of the busywork is far easier, or even non-existent now—but that doesn’t change the fact that you need to breathe. This is a perfect time to go over plans to keep the business on its feet in case of IT catastrophe—or at least some major systems catastrophe. Saying “We’ll just deploy a new version” is cool, but it only works in some scenarios. I touched on this and discussed one case where it doesn’t work in October 2021. But there are a ton more. Every environment is different, but hardware failures have not disappeared and destructive writes still occur, as just two more examples. Your infosec team can give you a few more examples.

Knowing what you’re going to do when the worst-case scenario happens is huge. And for those who’ve never been through it, knowing before people are stressed and asking you for a timeline will save you a lot of headaches.

For those who’ve never had a DR or business continuity plan, consider it. At least have a basic DR plan that lists critical systems, things most likely to go wrong and what the steps are to recover it and get things moving again. The process of making such a list will often uncover things that should be done but aren’t—like backups or backup verifications.

For those with a DR or business continuity plan, I’ll take a wild shot and say, “It’s out of date.” Organizations tend to create them and then forget about them. These plans should involve a bit of each project, so it’s taken care of in bite-sized chunks, but—probably because the first implementation of DR or BC is normally a massive project—it tends to be set aside and revisited every few years. Don’t do that.

As I’ve said before, you and yours have built the heart of the modern enterprise. Don’t forget to protect it. It doesn’t take much to use some of these sweet new technology advances to put in DR procedures. Tack DR review/updates onto each major initiative, be it a new product or a big change to existing software. And keep rocking it. If you have a say in your organization, consider slowing the pace down for a bit and even updating DR. If you don’t have a say, may your employer be wise enough to do so.

February 10, 2022
Techstrong Research DevOps Radar Report 2022
You can’t control the pace of change; instead, consider that we are in a process of reinvention—both with regard to the way organizations use technology and how vendors position their offerings. At the same time, it’s never been more important for IT organizations to have complete visibility into the way technology is used from both a security and operations perspective.

This need to embrace reinvention while continuing to have broad and deep insight across all technology platforms led me to create a 2022 DevOps Radar Report. In this article, I highlight three near-term priorities that must be on every technology team’s radar. In addition, I’ll point out some long-range radar trends that should be on your agenda.

Collision Warning! Your Current Radar View

API Security

APIs are the lifeblood of the cloud-native and app-based economies. Increasingly, poor API security across a variety of applications and systems puts your organization at risk. A compromised API or the use of unsupported or outdated APIs can prove to be an easy attack vector for cybercriminals. In addition, API vulnerabilities are calling into question how organizations approach application security and the usefulness of web application firewalls (WAF) and encryption protocols. Therefore, API security is rapidly becoming a top security priority for enterprise security teams and software professionals.

Failing to adequately manage the security of APIs creates a host of new challenges and questions that you must consider. For example, who is using which APIs? Are your APIs updated? Did your DevOps team evaluate the security of your APIs during their selection process? Have you formalized the way your organization is evaluating API security?

It is increasingly clear that an API breach can lead to the downfall of your entire digital software strategy—but it doesn’t have to be this way.

At Techstrong Research, we segment the market into “pure-play” API security vendors and larger security vendors with specific API security offerings. Our team will be publishing a Market Vista report on the API security landscape soon, so if you want to share your opinion or thoughts, please reach out.

Below is a brief list of some of the vendors we are tracking in the API security market. Of course, expect consolidation—some of these pure-play vendors will likely be acquired in 2022.

Pure-play API security vendors we’re tracking include:
General security vendors with API security offerings that we’re tracking:
- Check Point
- Citrix
- IBM Security
- F5
- PingIdentity
Observability is Evolving to AIOps

Modern applications are composed of containers and APIs that your organization can’t control, and into which visibility is difficult. Monitoring and application performance management (APM) solutions aren’t new; for many years log vendors built their businesses on collecting log files and sending alerts … so what’s changed?

First, logs without context are meaningless. You need to understand upstream and downstream dependencies. Additionally, speaking for myself, I’m a mere mortal—if your teams are also made up of mere mortals, there is no way they can ingest, correlate and understand the tsunami of incoming DevOps log data quickly enough to take proactive measures.

Besides the need to understand context, we are dealing with multiple cloud and on-premises platforms that each have their own logging protocols. Ultimately, the goal of observability and AIOps is to understand what’s happening across and among all these environments and technologies so you can detect and resolve issues as quickly as possible to keep your systems efficient and reliable and your customers happy.

Humans are the Biggest Security Vulnerability

As an industry analyst, I see our clients pouring resources into cybersecurity efforts to prevent zero-day attacks and sophisticated advanced persistent threats (APTs). These threats, while real enough, are mostly external and may not pose as great a threat as many organizations believe. In fact, the vast majority of security vulnerabilities are caused by:
- Well-meaning employees making innocent mistakes, including:
  - Falling victim to phishing attacks
  - Poor corporate password policies
  - Cloud misconfigurations and open ports
- Technical debt—relying on older software and hardware that was never designed for a 100% mobile workforce, for example
The first step in combating this problem is improving security awareness and building a cybersecurity culture. That starts with everyone in your organization understanding that security is a team sport and that it is a 24/7/365 responsibility. Even if you work from home; even when you’re cooking dinner while checking email on your phone, you need to have your “corporate security/Is it safe?” hat on.

At the same time, machine learning, AI and automation have a role to play. There are emerging offerings that help enforce DevSecOps best practices and help security teams reduce the constant noise so they can focus on the most vital threats.

Longview Radar: Plan Your Strategy Now

To support emerging business models, what do DevOps leadership teams need to be thinking about from a long-term perspective?
- Web3/Web 3.0 and the potential for change to the internet business model. But there is still a ton of opportunity with Web 2.0.
- How will you support low-code/no-code? As a business model, vendors are selling directly to business units—it’s likely that your IT team has an existing solution to solve the business pain point(s).
- Packaged software offerings that include blockchain, NFTs and other digital ledger technologies.
- How to upskill teams, both from a technical perspective and a business perspective.
- Providing developer teams with the tools they need while establishing guardrails to enforce governance and compliance requirements.
- How to manage cloud costs in a predictable way no matter how many cloud vendors your organization uses.
Conclusion: You Can’t Put the Brakes on Change

Attempting to control change and the speed of reinvention is futile. You need to get comfortable riding the waves of industry change, or you’ll be swept away! Every IT leader needs to learn how to roll with and manage the ebb and flow of business, IT and personnel change.

The best place to start is by building a successful culture within your organization. Although we often talk about technology-focused solutions to business problems, the first step on this journey doesn’t involve tech at all; it involves helping IT and business teams understand each other’s pain points and learn how they can each support a continual reinvention process.

I will be tracking these incoming radar targets and other associated trends throughout the year and I look forward to your input. Do you think I missed something? Have a question or want to share what your organization is doing to support the need for continual reinvention?

Feel free to engage with me – @DDKirsch, LinkedIn or, of course, email.
February 9, 2022
The Evolution of Incident Management
Have you ever thought about the history of incident management?

If you’re an SRE, you might be so caught up in the day-to-day work of managing reliability and responding to incidents that you never take time to step back and reflect on the evolution of your role and your responsibilities. And that’s a shame because SREs didn’t invent incident management concepts and strategies on their own.

On the contrary, the way SREs think about incident response, structure incident management teams and rank the priority of incidents owes much to incident management strategies developed in the offline world decades ago. To understand fully what it means to be an SRE today, you have to appreciate this deep history of incident management and response.

So, let’s take a look at that history and examine where modern incident response concepts originated.

Historical Problems in Incident Management

Societies have always had incidents, of course. Fires, floods, infrastructure breakdowns and similar crises have been happening for millennia.

For most of history, however, humans lacked an efficient, purposeful way to manage these sorts of incidents. Response efforts were ad hoc, and their effectiveness owed more than a little of their success to sheer luck.

Particular challenges included:
- Lack of effective, consistent communication between stakeholders.
- Varying organizational structures which made it hard to identify leaders, coordinate response efforts and delegate tasks.
- Inconsistent response strategies.
- Differing approaches to assessing the priority of incidents.
Historically, organizations may have been able to handle incidents well enough if the incidents required response from only one, small group. But the more stakeholders involved, the harder it was to respond quickly and effectively.

Putting Out Fires: The Birth of the ICS

Things began to change for the better when stakeholders started thinking about better ways to put out fires—literally.

By the 1960s, fire chiefs in California realized that they were struggling to respond effectively to the wildfires that broke out every summer. Each year brought worse blazes than the last, with more land burned and more buildings lost. The Laguna fire of 1970 brought matters to a head and was the catalyst for a new approach to incident response for fire agencies.

After assessing what was going wrong, the fire chiefs determined that it wasn’t a lack of equipment or personnel. It was poor coordination among the various firefighting agencies that responded to blazes. Lacking a clear chain of command and a systematic approach to firefighting, the agencies struggled to deploy their resources rapidly and, thus, effectively.

To fix the problem, California fire chiefs developed what became known as the Incident Command System, or ICS. The ICS defined a hierarchy for incident response with an incident commander at the top. It also defined several categories of incident response processes including operations, planning, logistics and finance. And it established a consistent set of terms that stakeholders can use to describe their actions during incident response, which makes it easier to communicate clearly.

Although the ICS was initially conceived to fight fires, it became the de facto standard for organizing incident response strategies of all types.

From ICS to NIMS

The history of incident response doesn’t end with the ICS. A new chapter began in the early 2000s when the U.S. federal government developed an even more comprehensive approach to incident management called the National Incident Management System, or NIMS.

NIMS was born in the wake of the September 11, 2001, terrorist attacks, which underlined the importance of efficient communication not just between different agencies of the same type (like fire departments), but of entirely separate organizations. To achieve this, NIMS expanded upon the principles of the ICS.

In addition to adopting most of the incident command principles and practices included in the ICS, NIMS included standards for coordinating the distribution of resources. It also embraced the concept of the emergency operations center, which is in some ways similar to a network operations center in the digital world.

In some respects, NIMS resembled a compliance framework (although to be clear, that’s not what it is). It includes fourteen management principles, similar to compliance controls, that organizations must implement to manage incidents using a NIMS approach.

Incident Management Today

Obviously, putting out forest fires and responding to terrorist attacks is pretty different from dealing with data center failures or a buggy application deployment. ICS and NIMS weren’t designed for site reliability engineering or IT teams specifically.

Still, the influence of ICS and NIMS on the way SREs think is clear enough. Terminology like “incident commander” comes from these frameworks. So do concepts like shared accountability for incident response processes and the importance of involving all stakeholders—not just technical teams—in incident response.

ICS and NIMS may not be acronyms familiar to most SREs. But they should be, because they are the historical sources of the incident management philosophies that form the foundation for SRE work today and offer valuable lessons for any SRE on the job today.
February 8, 2022
4 Ways to Uplevel Your Software Engineering Team

In my 20 years leading software development teams, I’ve witnessed the industry’s continuous growth alongside technology’s evolution. The only thing we know for certain is that the industry will continue to change and winning businesses will be those that build with change in mind, backed by effective, fast-moving software teams.

This is the year we must focus on fine-tuning our DevOps processes and uplevel our teams, but where do we start?

Below are four ways you can begin to transform your teams into engineering powerhouses, no matter how big or small or where they are in the world.

1. Embrace New Delivery Models

Remember when deployments were a big deal; a highly-anticipated event that often meant late nights? These days, many teams have managed to make deployments a non-event and are deploying any time of day. Those that haven’t adapted risk being left behind. The rate of deployments will only increase, so how teams handle this progression will be a deciding factor for success in an already competitive field.

In 2022, teams should continuously evaluate their procedures as they push the boundaries of their tech stack. Navigating the complexity of the digital era—from massive datasets and machine learning to networks of third-party services—will force both developers and company leaders to embrace flexible tooling and processes to ultimately refine the risk/innovation tradeoff.

2. Prioritize People and Culture

While 2021’s Great Resignation saw many software professionals jumping ship in search of a fresh work environment, in 2022 we expect to see a Great Reshuffle. Realizing their new or current gig still may not be quite the right fit, engineers and developers will start looking for roles that are more in line with their long-term career and personal goals.

Don’t fear this reshuffle. Instead, recognize it as an opportunity to build a strong and stable team. Be honest about what, exactly, the job entails and the hard and soft skills you’re looking for. Honesty throughout the recruitment process leads to a better match between employer and employee and also contributes to resilient company culture.

3. Deploy Low-Code Solutions Strategically

Pressure to get the highest productivity out of software development teams has led to the adoption of no-code and low-code solutions. But that means these tools are being used predominantly by people who already know how to code. The folks with big ideas who don’t actually want to be programmers remain unserved and untapped.

Expect this disparity to soon lead to a split in the category of no-code and low-code solutions—those built specifically for optimizing developer teams, and those that can serve everyday creators. To really get the most out of your team, keep an eye on the low-code space and ensure the solution you use is the one that’s actually best suited for your goals.

4. Build With Change Validation in Mind

The growing adoption of cloud storage, service-oriented architectures, third-party API-based services and open source code (to name a few) makes modern software development monumentally complex.

A way to manage this complexity is by pulling our focus away from the application itself and onto myriad sources of change that affect the application—a concept we can think of as change validation.

Ultimately, change validation builds upon tried-and-true software best practices such as continuous integration, continuous delivery and release orchestration. Cloud-native architectures can be effective and scalable, but you need to have the right tools and systems in place to validate changes to your code at every step.

In the past, the general consensus was that you shouldn’t test in production; you should just release and wait for the bug reports to tell you what’s wrong. But in the world of extensive software supply chains and cloud-native architectures, testing in production is the only way to truly know whether changes to your code are working as intended before releasing software to customers.

In the new year, software developers will be of critical importance as organizations continue to expand on digital services and projects. Embracing new methods of software delivery, prioritizing people and culture and keeping an eye on how to best leverage automation tools like no-code/low-code and change validation will all help to transform your team for the better in 2022. This forward-looking approach and a willingness to reassess and pivot guarantees that your software engineering team will remain agile amidst a rapidly changing tech landscape.

February 7, 2022
Front-End Frameworks Enable Better Dev Collaboration

The general public often thinks about software development in terms of a lone software developer hacking away tirelessly at their keyboard. Of course, that is an anachronism, at best. What is true is that collaboration among software engineers, especially with their colleagues in IT operations which evolved into DevOps, has become the norm for rolling out better code faster.

We are on the cusp of the next big evolution as software development becomes more of a ‘team sport’ than ever before. Now, collaboration is extending beyond IT (developers and operations) to cross-functional areas across various business teams. Product development, marketing and others also are providing input and feedback into the software development process and, most significantly, becoming part of the process.

Front-End Frameworks are Driving Collaboration

Historically, software programming, including front-end programming, happened in local IDEs. However, the rise of modern front-end web frameworks has led to an entire class of developer tools that speed up the build process and allow applications to be deployed more quickly.

There are a number of front-end frameworks that do this: Netlify, Vercel and Appsmith, an open source internal app builder, are three examples. These tools are getting widespread adoption, because, in a world where front ends are becoming more complex, they make things like hosting, deployment, authentication and serverless functions much simpler. The other reason for adoption is also because many of these tools are built on top of popular open source frameworks such as React, which already has a vast user base.

This is enabling a new kind of collaboration that is unlocking a lot of value for all the stakeholders involved. Inspired by how Figma reshaped the design process by allowing real-time commenting back in 2016 or how Google’s suite allowed real-time editing, there is a similar phenomenon taking place over the last year in software engineering.

Visual, Real-Time and On the App

The most obviously striking feature is that collaboration is happening on the app (or the app prototype) and is becoming increasingly visual. Writing or editing code in the command line is great, but it doesn’t necessarily help the developer to visualize what is happening. Vercel’s Next.js Live, for example, allows teams to chat, draw and edit.

This also means that collaboration is happening on the app instead of through tools like email, Slack and Jira, leading to targeted feedback without having to toggle between multiple tools.

Collaboration and Feedback Loops Become More Inclusive

While developers often collaborate at the code level, non-developers’ feedback is often given at the design level. This is more often the case for internal tools (or apps), which typically account for anywhere from 20% to 40% of engineering bandwidth in organizations.

For example, Appsmith today has thousands of developers self-hosting and deploying internal applications for users who are often business or operational teams like support, sales and/or finance, for example. Often, these business users don’t even know who has built the application. Real-time commenting via front-end frameworks facilitates collaboration between software engineering teams and their business counterparts who can now communicate directly, provide feedback and collaborate with their engineering peers. This close collaboration empowers all parties, increases efficiency and saves significant time while improving the overall quality of the software and ensuring that it meets expectations.

In addition, non-engineers don’t need to familiarize themselves with a new tool like GitHub or go through a painful replication issue on Jira involving a variety of screenshots or screen recordings. Sharing feedback can be done much more easily.

Better Version Control and Feedback

For developers, having the ability to visualize a particular branch of an application and give detailed feedback on it and then track it on GitHub or GitLab speeds up the development cycle. Netlify, for example, pioneered this when it launched Deploy Previews earlier this year. Netlify takes this feedback and integrates it into project management tools like Jira, Trello and many others in addition to GitHub and GitLab.

We are seeing other companies, like Sturdy, building on this much-needed trend of real-time collaboration in app development.

Collaboration is the Trend

Great software is the story of teams expanding collaboration beyond developers and there is a lot of good tooling available to help achieve that. This trend should continue to gain traction in the years to come because it taps into a number of other underlying trends in the software development space.

First, the explosion of alternatives in the backend-as-a-service space, in which Heroku and Firebase were early pioneers, means BaaS is embraced by many more organizations for a variety of use cases. This trend speeds up development because they present a much more tightly integrated ecosystem of services and organizations don’t have to worry about deployment, hosting, content delivery network (CDN) and/or authentication themselves, for instance.

Second, the proliferation of APIs is driving the emergence of more complex applications built on a variety of data sources. Everything is connected to everything. Of course, this also means that a lot more data is available to support decision-making, and this leads to many different kinds of applications being created both for external as well as internal purposes.

And finally, the larger low-code/no-code movement is creating millions of new citizen developers and blurring the boundaries between who is and isn’t a developer.

Summary

DevOps marked the start of the evolution of software development into a team sport, and collaboration is now accelerating beyond the boundaries of IT. Like DevOps, the result of this collaboration in the software development process will be better software that propels businesses forward created faster than ever before.

February 4, 2022