Tag: Great Resignation

  • How the ‘Great Rebalance’ Accelerates Low-Code/No-Code Adoption

    How the ‘Great Rebalance’ Accelerates Low-Code/No-Code Adoption

    If you were just reading headlines, you would think that careers in tech were limited—especially developers and DevOps professionals. The media and job sites have highlighted layoffs weekly since the beginning of the year, with over 120,000 employees eliminated from 400+ companies (including Amazon, Alphabet, Microsoft, Meta and others). With this much shedding of technical talent, you would think there would be a glut of developers and limited new career opportunities for software developers.

    In fact, the opposite appears to be true. In the U.S., job growth accelerated sharply in January while the unemployment rate dropped to a 53-year low. According to a recent report from Bain & Company, at a macro level, the demand for technical talent is still high but is now growing within non-tech industries. “The growth of demand for tech talent from non-tech business has really been a game-changer,” said Jonathan Frick, a partner at Bain and one of the study’s authors. Using publicly available job postings and U.S. government data, Bain determined that demand for tech workers at non-tech businesses outpaces demand at tech businesses for the first time.

    So is the “Great Resignation” now being replaced by the “Great Rebalance” as other industries finally catch up and have the opportunity to find and hire technical talent? That appears to partly be true; however, there’s a bigger takeaway than developer talent is simply changing employers … it’s a more fundamental and structural shift in the industry. As talent moves beyond traditional tech firms, non-tech businesses seek to apply software innovation differently. So let’s discuss why this sets the stage for 2023 being “the year of no-code.”

    Continuing Demand for Digital Apps

    It’s been said that “every business is now a software business” (in the words of Watts S. Humphrey, the father of quality in software and CMMI). Businesses of all sizes and across all industries have taken advantage of software to enable sweeping digital transformation initiatives and put software at the heart of their business strategy. In fact, IDC predicts that by this year, over 500 million digital apps and services will be developed and deployed using cloud-native approaches – the same number of apps developed in the last 40 years. The majority of these new apps will be targeted at industry-specific digital transformation scenarios and will define competitive requirements in every industry.

    This exploding appetite for digital apps still vastly outstrips the supply of developers in the market. As a result, non-tech organizations have been desperately seeking new and creative solutions to keep up with demand. This is one of the key reasons businesses across all industries and all sizes have turned to no-code. By accelerating the pace of developing software, using visual and intuitive drag-and-drop tools, no-code levels the playing field and enables more rapid delivery of digital applications without having to wait on scarce IT or development resources.

    Headcount Budgets Remain Constrained

    Non-tech organizations tend to be more pragmatic about how they invest – unlike tech firms, they are less likely to simply invest in “shiny new technology” but look for stricter business justifications and returns on development projects. Also, the overall continued market uncertainty and concerns about recession will continue to pressure businesses to get the most value from their investments. So even though it may be easier to find developers in the talent pool, there’s not a blank check to hire at any price.

    This will drive non-tech organizations to look for ways to enable app development within their business teams as part of a ‘do it yourself” (DIY) approach to software development. The DIY approach enables business teams to play a more central role in app development using low-code/no-code solutions. By democratizing app development, low-code/no-code enables a whole new range of non-developer roles (often referred to as “citizen developers”) within an organization to take on the building of software applications. While IT and professional developers are still important for certain types of apps, the use of no-code has increased the talent pool inside most organizations, allowing employees within the business to take on development tasks.

    Non-Tech Organizations Accountable for Everyday Delivery

    Startups in the tech industry have been accustomed to a traditional venture life cycle of innovation – which has historically been accepting of years of challenges as long as the startup could demonstrate rapid growth at all costs; a single successful exit would be seen as a reward. However, non-tech firms don’t usually have the luxury of this sort of development model and are under scrutiny to show profitability and quarterly earnings. Non-tech businesses look for approaches to accelerate new sources of sales or add new products to market more quickly. They need to exploit app development strategies that deliver results in days/weeks (not months/years).

    Instead, an ‘everyday delivery’ approach to no-code is much more evolutionary and provides a continual but rapid stream of updates to the end user as part of a high-velocity, ongoing improvement cycle. The deployment can be based on specific features without a need to connect it to a specific Agile sprint deadline or other formal milestones. This mode of continuous everyday delivery builds on the rapid development and continuous deployment automation provided by low-code/no-code platforms. Combined, this allows for quick, small updates to be pushed frequently (perhaps daily) to production while maintaining higher levels of quality than traditional “big bang” software releases.

    Conclusion

    They say every challenge presents new opportunities. While the recent tech layoffs would appear to create challenges and uncertainty, “The Great Rebalance” presents an opportunity for a new accelerated model of innovation across industries as non-technical businesses find new and different models for software development. In the dynamic and unpredictable markets we live in today, those who evolve and leverage low-code/no-code to compete, expand and thrive will outgrow and outpace their peers.  This is why businesses are hungrily adopting low-code/no-code tools and everyday delivery approaches to realize the benefits of accelerating time-to-market and reducing time to deliver results.

  • Automation has Become an Absolute IT Necessity – Techstrong TV

    Automation has Become an Absolute IT Necessity – Techstrong TV

    Vijoy Pandey, vice president of emerging technologies and Incubation for Cisco, explains why automation has become an absolute IT necessity. The video is below followed by a transcript of the conversation.

    Michael Vizard: Hey, guys, thanks for the throw. We’re here with Vijoy Pandey, who’s vice president of emerging technology and incubation for Cisco. We’re gonna be talking about all things related to automation. Vijoy, welcome to the show.

    Vijoy Pandey: Thank you, Mike, pleasure to be here.

    Michael Vizard: Right now, everybody is struggling, looking to find people, hire people, retain people, and this was an issue before COVID came, but it seems like it’s much worse these days, and there seems to be no end in sight. So, what is your best advice to folks about how to think about managing talent these days?

    Vijoy Pandey: Yeah, I think that’s a pretty important point you raise there, Mike. Just like everybody else, we’ve been seeing not just news articles around the great resignation, but also we’re feeling that inside of Cisco as well. We know that our partners, our customers, all of us are feeling that pinch, where it’s incredibly important to retain top talent, but it’s also very hard to find talent, given the trends that we’re seeing around us.

    Anything about cloud computing, anything about AI, all of those things. So, we think of the problem in a very different way. We think – and we’ve done a bunch of surveys inside of Cisco – what we realized was given the global nature of events – we know some events unfolding right now – and all of the geopolitical events happening, all the pandemic, people really are realizing that life is too short.

    It’s not a pithy statement here, it’s actually people believe that life is just too short, and they actually want to do meaningful work. They want to make an impact, not just to the team that they are with, nor the company that they’re with, but even a global impact with the work that they do.

    But they also want to grow and learn, and make sure that they are on a path themselves towards meaningfully improving their own lives. So, I think those are pretty important characteristics that we have gathered, and as organizations and as teams we need to harness that desire to make both local impact as well as global impact as well as figure out how to drive meaning into everybody’s personal lives – yours, mine, our teams’, and so on and so forth.

    So, there’s a bunch of things that we are doing inside of Cisco to make sure that this meaning, or meaningful impact, is nurtured. One of the things that we keep on saying is that yes, there is a business to run, but there’s also an avenue we need to give our employees and our teams to innovate, to look at impact beyond the run-of-the-mill business that any corporation needs to do.

    So, typically what we end up doing is we end up taking problem statements that we face, let’s say, as a team or an organization, and we start splitting it into buckets. So, think about buckets that deal with run-of-the-mill business, because that, you need to absolutely take care of.

    But also, there are buckets that you need to innovate around or do meaningful work around. So, we have a portfolio management system inside, at least on my team, that says let’s take 60 percent of your time and make sure that that’s allocated towards run-of-the-mill business as usual projects, and then maybe 30 percent of the time which is future-looking and adding new features or looking at new markets and so on and so forth, and maybe 10 percent of your time is actually towards growing yourself, nurturing yourself, or making some meaningful impact on the global stage. So, that’s actually how we’ve been viewing the problem.

    Michael Vizard: Early on, I think a lot of people were intimidated by automation, and there was concerns that people might lose their jobs. Now, I wonder if we’ve flipped that entirely, where people are saying hey, I don’t really wanna work for organizations that don’t have automated IT process in place because of your points – there’s just things that I don’t wanna spend my day doing anymore. So, has the whole conversation flipped, as far as automation is concerned?

    Vijoy Pandey: I would say the conversation is flipping as we speak, again, yeah, going back to the previous comment, yes, people don’t want to spend time on repeatable tasks, on things which a computer can do better than you and I can do. I have this constant struggle with my kid nowadays as to why do I need to learn grammar when there’s Grammarly? But that’s a different matter.

    But I think it’s a similar mindset going through every individual in the workforce, as to am I really adding value in the workplace, and am I being more productive, which in turn translates is the organization being more productive, which in turn translates to is the economy and the country being more productive.

    So, I think the bump towards productivity is definitely a goal that people are more concerned about, and you hear the other side of this, which is, as you pointed out, is the digitization of the workplace is the digitization of all economy. That’s in progress.

    We’ve called that using various phrases – software eating of the world, or the API economy – whatever term that you want to use. But we are moving towards a world where software is critical in driving everything that we do. Software in terms of automation, or even beyond that, is definitely key to whatever we do.

    Michael Vizard: Not too long ago we all thought we’d be running around by flying cars by now, and that IT would be easy. We’ve seen neither, and it looks like IT is getting more complex than ever. So, my question to you is is IT getting to the point where it is just too complex to manually deal with and we need automation, because we are seeing all these microservices, serverless frameworks.

    There’s all our existing monolithic applications, it’s distributed all the way out to the edge now. Have we reached some sort of inflection point?

    Vijoy Pandey: Yeah, I think to your point IT is definitely way more complex than it was even a decade ago, and I think the crux of the matter is that the way you are building applications and all of the digitization that we talked about is actually taking place in a very, very distributed manner.

    So, as an application developer, first and foremost, we at Cisco like to say that the application is your brand. So, if I am a bank, how my customers interact with the apps that I build defines me, my company, my bank, as the brand. Because if bank A has more capabilities in their software, their mobile app, versus bank B, I will migrate towards bank A.

    So, I think the application is becoming the front end to everything customer experience is all about. So, if you take that notion and play it out, that means the application developer that is developing those applications is under extreme pressure to deliver velocity behind features, do deliver trust with the data of the customers, to deliver uptime and security and so on and so forth.

    So, which means that they are picking and choosing all of these APIs that exist anywhere to make their job faster, easier more secure, more trustworthy. So, if you think about that kind of an environment, as a developer, I’m picking APIs from cloud providers, SaaS providers, I have legacy systems, I have transaction systems, I have edge devices, in the case of a bank. It might be sitting at a branch office.

    I have all of these APIs and systems that I need to interface with just to build one particular app or feature. So, in this kind of a distributed environment, think about the IT – more IT people, right? It’s like I’m trying to build a platform that caters to these kind of demands, and so it is definitely getting more complex, it’s getting more distributed, and every provider in the distributed environment has their own semantics, their own lifecycle management behind their APIs and their infrastructures.

    So, automation – I mean, it’s just humanly impossible to not just deploy but even manage and observe such a highly distributed – and secure, by the way – such a highly distributed system. So, automation is key to doing all of this, a direction automation, to me, is discoverability.

    It’s intent-based, it’s security, which is there’s no longer a perimeter of security, and it’s observability across all of these end points, API to mainframe. That is key to moving forward.

    Michael Vizard: Do you think as we go along that organizations – at least some of them I talked to, it’s almost like a chicken and an egg kind of issue. They have so much legacy stuff that can’t be automated that they can’t invest in automation, and they can’t necessarily buy all new platforms tomorrow. So, how do we get over the automation hump to kind of get from point A to point B without necessarily breaking the IT budget?

    Vijoy Pandey: Yeah, that’s a great point. I think some of that, I’ve dealt with in my previous lives as well. The way to do that is – and there’s no questions about it, that for some period of time, there is going to be more chaos and more money spent than before that time or after that time.

    So, we just have to acknowledge that as vendors, as customers, as organizations, that for some period of time, there’s going to be turmoil. That’s the way, at least, I’ve handled it in the past, where you say let’s put milestones, where we say maybe we look after a pocket of the organization, and say we’re going to build this out in a highly automated, distributed, cloud-first, API-first manner.

    This part of the application, this part of the infrastructure goes out and does that. To do that, we’re going to do a clean slate process here. So, we’ll think about – we won’t get ourselves bound to organizational boundaries, skill set boundaries – that is very hard to do. Most people’s jobs, peoples’ skill sets, organizational structures, all of that.

    But we have to try in some pockets, and then give ourselves strict guidelines and metrics, and try and meet those metrics. If we meet those metrics, the resulting outcome is that I will be spending less moving forward than I’m spending today.

    So, I might spend a little bit more in getting maybe SREs or software engineers, and marrying them up with IT folks or architects, and getting something going. I’ll give myself a timeline of let’s say a year or 18 months; it cannot be longer than that, otherwise it’s a science project. 

    But after those 18 months, these are the metrics I’m going to come back to. I’ll get X percent improvement in productivity, and Y percent reduction in head count, let’s say. We shall measure ourselves to that objective, and I’ve seen that work.

    If it works – and start with something simpler. But go all the way, don’t go 80 percent. Let’s not do 80 percent automation or 80 percent of the use cases. Hundred percent automation, 100 percent of the use cases for this pocket of your environment, and then grow that out over time.

    Michael Vizard: We, of course, hear a lot about artificial intelligent and AI Ops. Are the machines gonna save us from ourselves? What’s the reality of AI?

    Vijoy Pandey: To me, AI is a tool, just like all of the other tools that we’ve talked about, which is we’ve talked about automation or infrastructure as code, we’ve talked about cloud native and serverless and microservices. Each one of these tools, programming and scriptings tools.

    So, all of these tools bring in something to the table, and infrastructure as code brings in consistency and intent-based infrastructures, and serverless and microservices, or cloud-native, bring in immutable architectures.

    The fact that you can grow and scale out and do all of those things, and availability goes through the roof and velocity goes through the roof. Similarly, AI and ML bring in insights to the table where it was humanly, again, impossible to do that just by looking at the vast variety of data and the deluge of data coming our way.

    If we could just take all of that – and it’s all unstructured. So, if I could take all of that and somehow put it in a structured database and somehow make sense of it as an individual, sure, we don’t need the AI or ML. But if I need to take all of that unstructured data and make some sense out of it, there’s no other way out, and I do need AI and ML.

    I mean, I do need some statistical mechanism first, to figure out and make some sense out of it. I do need AI/ML, maybe deep-learning, to make some sense out of it. But then I need to marry that tool with subject matter expertise, I need to marry that tool with what I as an individual, or as humans, we’ve learned in the past, because AI doesn’t have that context.

    Yes, we can do learning, all sorts of learning, but it doesn’t always work in all kinds of environments. We need to marry that with subject matter expertise, with some boundary conditions, and then we need to marry it with actions. Because AI/ML is gonna give us insights, but somebody needs to take actions on the insights.

    So to me, it’s a tool in the toolbox, and we need to leverage it when it makes sense. We need to rely on subject matter expertise when it makes sense, and eventually things will get to a point where we need to go to the next level of abstraction. 

    So, it’s always a game of moving that level of abstraction higher and higher, and that’s what we are after. So, maybe someday there will be flying cars and robots that will take all our jobs, but not right now.

    Michael Vizard: How do I bridge this divide in IT that maybe we don’t talk enough about, but there’s clearly a DevOps community that’s very programming-centric. The use APIs. Then there’s traditional IT administrators that use ITSM tools. They tend to be more graphical in nature. As we move forward with automation, do you think that those two camps are gonna converge, or how will this all play out?

    Vijoy Pandey: In my opinion, I think they have to converge. I think each one of those pieces have their space in the hierarchy of things. One of the things I learned pretty early on in one of my previous lives is what good is a dashboard if you cannot take an action on it?

    So, if you think about all dashboards that exist today, eventually, there is data being presented in a certain way about a certain problem, so that somebody can look at that and take an action. If you think about infrastructure as code, it’s exactly that.

    It’s basically let’s remove the dashboard, and let’s figure out what goes – triggers that, that allow me to take those preset actions. Let’s try and remove the action of a human looking at a dashboard, thinking about it, and taking some action on it.

    Now, again, I’m describing utopia, but I think that’s where, as engineers, as operations folks, we all need to move towards. To me, dashboards are a good start when the problem is less well understood. As we understand the problems better, we need to move towards code.

    Dashboards will still have their place in helping us understand more and more complex problems, but as problems are better understood, they need to move towards code. And that’s the way at least I think through it.

    Michael Vizard: All right, so automation needs to be our new North Star, as it were. Hey, Vijoy, thanks for being on the show.

    Vijoy Pandey: Thank you so much, it was a pleasure, and I enjoyed our conversation.

    Michael Vizard: All right, back to you guys in the studio.

  • Force Me Back to the Office? Apple ‘Hasn’t Learned Anything’

    Force Me Back to the Office? Apple ‘Hasn’t Learned Anything’

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: I’m devoting my entire column to new ways of working. Whether it’s remote work, enforced hybrid working or a four-day working week, let’s triage the trends and futz with the future.

    Analysis: The Great Resignation — Not So Great

    Too many managers are stuck in their old ways. Despite the success of pandemic-era WFH, they yearn for how it used to be. But that ship has sailed.

    Mark Gurman: Apple Sets Return-to-Office Deadline

    “Pushing employees back into the office”
    The company … set a Sept. 5 deadline [and] will require employees to work from the office on Tuesdays, Thursdays and a regular third day that will be determined by individual teams. [It] has been working toward getting its employees back in the office since at least June 2021, when it first announced the three-day policy.
    …
    The iPhone maker has been one of the most stringent technology companies when it comes to pushing employees back into the office, irking some staffers. … An Apple spokesman declined to comment.


    It “Shows the Company Hasn’t Learned Anything,” cries Jason Aten:

    “Not the same thing as actual collaboration”
    Right now, every company is trying to figure out how to get its employees back to the office. Despite the fact that the world did not, in fact, come to a stop over the past two years. … Many companies—especially Apple—had their best two years ever when most of their employees were working from home.
    …
    Apple SVP of software Craig Federighi … told employees in an email … he “can’t wait to experience the special energy of having all of us back in the office together again!” … I imagine a lot of the people who work in the software organization are wondering whether that “special energy” actually makes them more productive—or if it’s just a thing managers feel as they watch employees.
    …
    If we’ve learned nothing else from the pandemic … coming to the office doesn’t make them more productive. It might make managers feel better … but that’s not the same thing as actual collaboration.


    But WFH doesn’t suit everyone. Here’s Aunty’s Kate Morgan: Why workers just won’t stop quitting

    Anthony C Klotz, a professor of management at University College London’s School of Management who coined the term “Great Resignation” [says] in addition to the original push factors … the reasons people are resigning have diversified. … Some workers are now swapping jobs that require them to be present in the workplace for remote positions. Other workers … are leaving remote jobs for ones that have a larger in-person component.


    WWSJD? quonset knows:

    Regardless of the jerk he was, Steve Jobs had grand visions which he brought to fruition. … One thing he stressed was the personal connection and serendipitous encounters.
    …
    It’s why, before he died, he was arms deep in the design of Apple’s headquarters. He wanted people to bump into each other, he wanted interaction between different groups. It’s why it’s designed the way it is. People are funneled to certain areas and have no choice but to interact with others.


    Is there an unintended brand consequence? u/Latinhypercube123 demonstrates there might be:

    Hahahaha. Apple is such a dead end company now. They’ve literally become what they ridiculed IBM of being: Corporate monolith of sameness.


    But is there a better way? You should read Evelyn Yu: Bank Says Four-Day Week Is The ‘Future of Working Life’

    “Flexible work is here to stay”
    Six months after switching to a four-day working week, the UK’s Atom Bank said it’s seen benefits from talent retention to improved productivity. … Days lost to sickness fell over the period and customer service ratings also improved.
    …
    Even as the pandemic recedes and some bosses push for a return to the office, there’s increasing evidence flexible work is here to stay. Office vacancies in central London are at the highest level in more than 15 years.


    Not just in the UK—it’s in Canada too. Here’s Sean Davidson:

    “Huge impact on employee retention”
    Ross Wainwright, CEO of Alida, said the software company implemented four-day work weeks for its 500 employees at the start of June and the two-month trial wraps up this week: … “The early results are fantastic. … The employees are clearly happier. … This is about getting better balance for our employees and helping to invest in their mental health.”
    …
    He said the trial is also having a “huge impact” on employee retention. … The most “unanticipated” result of the trial was how empowered his employees told him they felt, knowing the company trusted them to get the job done with a reduced schedule: “We empowered the employees to get the work done within their schedule.”


    Also in Toronto is u/SuperChloe:

    We had similar results at my company when we initially trialed 4-days (also not longer days, still 9-5) — overall increased output/productivity and employee satisfaction. We’ve moved to permanently having a 4 day work week.


    Meanwhile, @AnnaLovesVoting is just fine with a hybrid schedule:

    I don’t need 100% WFH, I’m willing to go to an office 1 maybe 2 days a year.


    The Moral of the Story:
    The tempter or the tempted—who sins most?


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Carles Rabada (via Unsplash; leveled and cropped)

  • Unstructured Data Management: Avoiding Insider Knowledge Gaps

    Unstructured Data Management: Avoiding Insider Knowledge Gaps

    Most IT leaders know that managing an unstructured data environment can be quite an undertaking. Before beginning an unstructured data management project, there are a lot of factors to consider including the number of storage devices, the size of a particular dataset, the number of files in the dataset and, perhaps the most intimidating, the unique environment the unstructured data inhabits.

    One-size-fits-all solutions can often inadvertently sweep important characteristics of unstructured data environments under the rug. Granted, this short-term, simple solution is easier than putting in the work to customize the best-fit solution for each organization’s data set. However, anyone undertaking an unstructured data management project should be forewarned—this methodology can create a longer-term detrimental effect known as “insider knowledge.”

    Insider knowledge is what is left when a group of people spend time setting up data management systems within an organization and then move on from their roles without passing along critical information about the data management system to those who take over. It makes things incredibly difficult for those who inherit the agglomerated system and, chances are, the organizations who currently have this problem don’t yet realize they have it.

    The Beginning of the End: Creating Insider Knowledge

    Today’s storage administrators have a lot on their plate and are perpetually spread thin. Their daily responsibilities typically include:

    • Creating shares and exports
    • Designing a file system layout
    • Assigning devices for each app or dataset
    • Hunting down unused data
    • Organizing and pairing workflows to datasets

    Often, with their busy day-to-day environment, the IT team’s decisions and actions are being made with a siloed approach. And as the project progresses, a unique language known only to the IT professionals overseeing the project is created. They may create their own tags and place files by a certain organizational system. However, most of this is not written down, meaning it is left to be deciphered like a code without an answer key. This language is the “insider knowledge.”

    Insider Knowledge and the Great Resignation

    Why is this an issue? As long as someone knows what is going on in the overall picture of the data, it’s fine, right? Well …

    Solely depending on the team of IT professionals who created the workflow means that they must stick with the company forever for their systems to make sense. After all, once the people with that knowledge leave, it is largely lost forever to the company.

    It is not a bet worth taking that the employees of a company will merely stick around to see the data management project to completion. The threat that insider knowledge brings to organizations is that only the people with an idea of how the system works can properly onboard the next hire. This is a great position to be in for the IT professionals who know everything about the system as there is a sense of job security, but it’s not great for the organization.

    For organizations, 44% of employees in the workforce are active job seekers. The Great Resignation has showcased that job seekers have the upper hand in the market today, and that good talent can be bought and poached from companies without a moment’s notice. When—not if—an organization’s IT team members move on, it is imperative to have a well-documented, organized foundation for the unstructured data management system so that the next team is able to pick up where they left off.

    Otherwise, when team members leave, they will inevitably leave knowledge gaps and questions will arise such as:

    • Are you hosting 20 TB of dead application data on your NAS?
    • Is this 20 TB of data something the storage administrator was planning on deleting, or is it important?
    • Are you going to pay to keep that data on Tier 1 disks?
    • Do you have old employee files that were archived to other storage devices but were never deleted?

    The implications of insider knowledge are important to remember before beginning to tackle a data management project. It truly is as simple as future-casting and deciding not to give a few people control over an entire enterprise’s unstructured data stores.

    Leave it to the Technology: What to Ask When Finding a Solution

    To manage unstructured data, there are now many tools on the market built with insider knowledge (and the pre-existing codes within organizations) in mind. By automating the process as much as possible, organizations can avoid a headache when their IT team moves on. Some questions to ask to aid in finding the proper tool include:

    • Location of data: How many storage devices are there? How many data centers are there? And how many countries are the data centers spread across? Do any live in the cloud? 
    • Scanning capabilities: Do the aforementioned locations of the data affect the tool’s ability to scan it? What functions can be performed, from just scanning to analyzing with big data abilities?
    • Presentation: How do you receive the information from the tool? Is it digestible and usable? Will it easily highlight the forgotten data sets? 
    • Aftermath: When you have the information at your disposal and have the insider knowledge in front of you, how can it help you move forward to promote a healthier unstructured data environment? 
    • Time: How long will it take? How much data can the engine scan? And will this affect business-as-usual?

    These are inquiries IT leaders must find answers to before deciding on the best solution for their organization’s long-term success. Regardless of how understaffed and overworked IT teams may be, in today’s modern data center, the last thing that should be done is give a few IT professionals complete control over an enterprise’s unstructured data management system.

    Staff turnover is never fun. In IT, it can severely impact an entire organization if IT teams are forced to start from scratch on projects because no one is left to translate the system’s language that was built on insider’s knowledge. 

    With the amount of data created each day, the time to clean up and automate the process as much as possible is now, as the time to decide on a solution that works for today was yesterday. IT leaders who take time to evaluate the new technologies and comprehensive data management solutions available will be poised to spend their budgets wisely to reduce the risk of setbacks, delays, cost overruns and even IT team turnover.

  • Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New Normal’

    Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New Normal’

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Linus says next release will support Rust, FBI warns scammers are getting hired in deepfake interviews, and 80% of IBM staff stay at home. (more…)

  • Go Language is Popular? | VMware Sells to Broadcom? | Unlimited PTO?

    Go Language is Popular? | VMware Sells to Broadcom? | Unlimited PTO?

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Golang goes from zero to hero, will Broadcom buy VMware? And limitless vacation is still a Thing. (more…)

  • Twitter/Bluesky ADX Algorithm | Cloud Energy Use ‘Tripled’ | Apple Staff are Revolting

    Twitter/Bluesky ADX Algorithm | Cloud Energy Use ‘Tripled’ | Apple Staff are Revolting

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Bluesky—Twitter’s research spinout—opens its ADX algorithm, Irish data center electricity worries grow, and Apple employees are the latest to rise up against hybrid working. (more…)

  • Wi-Fi 7 Chips Ahoy | Google ‘Gone Downhill Fast’ | Real-World ‘Severance’

    Wi-Fi 7 Chips Ahoy | Google ‘Gone Downhill Fast’ | Real-World ‘Severance’

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: The first silicon for Wi-Fi 7, Google’s search quality “is” failing, and what Severance tells us about The Great Resignation. (more…)

  • Facebook Bans Innocent Users | Azure and ARM/Ampere | ‘Great Resignation’—No End in Sight

    Facebook Bans Innocent Users | Azure and ARM/Ampere | ‘Great Resignation’—No End in Sight

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: No remedy for banned Facebook users, new ARM-based VMs on Microsoft Azure, and The Great Resignation will still be a Thing for the foreseeable. (more…)

  • Turnover, Documentation and Missing Links

    Turnover, Documentation and Missing Links

    When employee turnover spikes, IT in general and DevOps teams in particular need to be prepared.

    At the time of this writing, the stock market is roiling, and DevOps compensation is bouncing up. This has an impact on turnover because many in DevOps (and nearly all senior positions) have compensation that includes stock—stock that may be down significantly or that is currently at high risk of going down. This causes two types of movement—those leaving an organization to avoid further loss in their compensation and those who are leaving their current gig to join an organization whose stock is down. Combined with those who leave for a role with a larger base salary, there are those who are leaving to earn more and those who are leaving to avoid more loss. IT budgets ballooned during the pandemic but those, too, are deflating, so while we have a worker, not a position shortage, there will be pressure from both sides.

    So, why is this geek going on about employment, compensation and available positions?

    Simple: Because DevOps is not any better at documentation than any other flavor of IT. In tightly-run shops, documentation is available and maintained. In most shops, it is spotty at best. In some, it is downright nonexistent. This has forever been true in IT and, if anything, it is more true because the early stages of DevOps implementation result in a massive amount of change.

    People leaving in an environment with less-than-stellar documentation can be a problem. What tools are used? Where are they located? What’s the login for these SaaS tools? Etc., etc., etc. If turnover means you’re losing entire DevOps teams in relatively short order, this can become a nightmare relatively quickly. And that nightmare is very real for everyone left behind and those that are coming in. Someone has to go figure it out; IT management has to let the rest of the business know that retention issues are causing backlogs. Everyone not tasked with figuring it out has to pick up slack for those who are … you get the picture.

    Take the hour or four and document what you have. It doesn’t have to be comprehensive, it just has to list what tools, where they are, who at the organization is responsible for credentials at any SaaS vendors and under what circumstances the tools are used. If each team documents their own stuff, even in a shared toolchain environment, comparing the documents will uncover little details one missed that another did not.

    Let’s face it, we have—for better or worse—moved largely to a world where loyalty is based on compensation. Much like mercenaries, most IT employees are always listening for a better offer. So the organization, while acknowledging this fact, needs to take steps to minimize the negative impacts of turnover. New ideas and suggestions to change things are all good and you don’t want to interfere with that aspect of turnover. But anything that impedes the organization’s ability to deliver should be addressed beforehand. And that means documentation so remaining and new employees can get up to speed quickly and take ownership rapidly and with confidence.

    And keep rocking it. Whether you are looking for a new gig or not, keep the apps you are responsible for running—and document them. You’ve contributed to the success of your organization; don’t slack off while moving along. And don’t hate those that are moving along. Not all of us base our loyalty on compensation, but we do all allow compensation to influence our decisions (unless you are working for free and I missed it?) Keep rocking, no matter your status. And don’t hesitate to tell interviewers that you helped your last organization achieve success.