Info-Tech Research Group

Ransomware is now a daily news item. Having an effective and formalized response plan in place is more important than ever. Organizations are considering how to prepare and respond, whether they need cyberinsurance, and how it all works with their business continuity.

Join us in this webinar where we will address how to:

• Assess your ransomware preparedness.
• Document a formal response plan.

View Webinar

The Better Business Bureau’s Women in Business Networking (WiBN) program is thrilled to announce the 2022 Women of Impact honorees, as well as Jeanne Porter Career Achievement Award recipient.

Women of Impact honorees are dynamic professional women who have been recognized for inspiring and encouraging those around them to actively challenge the status quo, working to improve their communities, develop their employees and advocate for women in general. Rather than being content with others just watching them work, these women involve those around them in their endeavors thereby increasing their collective impact. They understand we are “BETTER TOGETHER.”

Melissa Cutcher, Technology First, will be the recipient of the 2022 Jeanne Porter Career Achievement Award. This honor is presented annually to a woman who continues to inspire, influence and impact the business community and the world around them well beyond their initial recognition as a WiBN Top 25 Woman. This award is meant to recognize an impactful professional legacy, like that of Jeanne Porter, founder of WiBN.

2022 Women of Impact include:

• Sheri Aldridge, New Beginnings for You
• Molly Bardine, Chaminade Julienne
• Cassie Barlow, Col. USAF Ret. & SOCHE
• Judy Budi, Graceworks Lutheran Services
• Janet Carpenter, Sophie‘s companions for Veterans/Sophie Kerrigan  For the love of Animals Foundation
• Joyce Carter, Montgomery County
• Pamela Cone, Aviatra Dayton & Curated Conversations
• Lissa Cupp, Big Rocks of Life & Style Encore
• Angela Dugger, National Alliance on Mental Illness
• Lois Elrich, Real Change Business Coaching
• Denise Henton, Single Parents Rock
• Karlee Mason, Picnk, LLC
• Anita Moore, A. Moore Consulting
• Dr. Shanee Pacley, Wright Patterson Air Force Research Laboratory
• Robyn R. Razor, Mount Carmel East
• Dr. Rhonda Smith, Divine Core Transformation & Renewed Health Care Practice
• Yvonne Turner, BSN, CHPN, CNS, Ohio’s Hospice
• Lisa Wagner, Levitt Pavilion Dayton
• Natalie Walters, WKEF/WRGT
• Erika Ward, Ronald McDonald House Charities of Dayton

Cadre Information Security

You’ve probably heard about it. Maybe you wrote it off as just another product on your cybersecurity bingo card? It is Extended Detection and Response (XDR)—cybersecurity’s “next big thing.”

Could it be the security management technology of your dreams? Let’s find out. We’re diving right in to give you an up close look at the technical evolution that vendors seem to be going gaga over. And, we’ll let you judge for yourself.

What is XDR Anyway?

Before we define XDR, it might be helpful to create context with Endpoint Detection and Response (EDR). As endpoints proliferate, organizations are focusing more attention on securing workstations. To do this, EDR provides two essential functionalities:

1. Continuous monitoring and threat detection.
2. Follow up of automated responses to threats discovered during the monitoring phase.

While EDR provides essential visibility and control over threats to endpoints, threat actors do not focus solely on laptops, desktops, mobile phones, and other devices. Rather, they find the entry point of least resistance and escalate their privileges to move laterally until they reach their intended target. 

To block and disrupt threats effectively, organizations need to go beyond EDR with extended, real-time visibility into security events not only for your endpoints, but for cloud workloads and the network. XDR achieves this by collecting and correlating data across all channels to enable visibility and context into advanced threats. After alerting analysts, threats can be analyzed, prioritized based on risk, hunted, and remediated to prevent breaches and data loss.

But I Have a SIEM for That

As with many security solutions, some features of XDR and SIEM overlap. Because of this, customers tend to ask if XDR adds value in environments that already have a SIEM solution deployed.

The distinction starts from the very beginnings of each product. SIEM had its genesis in compliance. Over time, SIEM evolved to a threat and operational risk platform, pulling data from disparate sources, performing automated analysis, and alerting human analysts. However, it does not include some of the broader functionality that XDR encompasses.

Unlike SIEM, from day one XDR was developed to focus on threats and to provide a single platform for deeper and narrower threat detection and response. Seen as the next generation of EDR, XDR includes additional functions like antivirus, firewall, and of course, EDR.

More specifically, XDR differentiates from other product categories in three ways:

1. Level of turnkey integration is much higher and does not require expensive, labor-intensive calibration.
2. Squarely focused on threat detect and incident response and have a higher quality detection and analysis lab.
3. Generally built on cloud-native architectures and can be rapidly deployed.

Is XDR Right for Your Business?

As vendors begin to take their XDR offerings to market, we have seen it appear in different forms—hardware companies adding standalone XDR products while traditional enterprise security companies add XDR as an extension of their existing platform. Given the range of options, there is certainly an XDR for every need.

But, is there a need for every XDR? Sometimes you don’t know until it’s too late. Or instead of waiting, you can try finding your security program holes through a pen test. Read more in our blog, What are the different types of Pen Testing?

Greg Franseth, Cadre Information Security

The internet is chock-full of cloud growth stats. We all know it’s happening, but do we really know how great our security risk is? According to our friends over at Netskope, in 2020, the number of apps in use by the average enterprise increased by 20%[1]. Organizations with 500-2,000 employees used on average 690 distinct cloud apps. Of those apps, 47.5% have a “Poor” Cloud Confidence Index™ (CCI) rating—meaning enterprises should avoid using these apps and take steps to migrate to safer app alternatives.

And that’s just a glimpse into the current state of cloud security.

With so much of today’s work rooted in the cloud, it’s easy to get wrapped up in doing everything you can to improve your organization’s cloud security posture. But these days what we’re seeing is that IT teams need to take a pause and revisit these 3 need-to-know security facts.

1. Everyone’s cloud security stack still needs to be tailored.

“More cloud security doesn’t equate to stronger security” is something you have probably read time and time again. But it’s worth repeating. Why? Because as the attack surface keeps expanding, organizations keep falling into the same pattern. There’s an issue, they buy a security solution to stop the hemorrhage or meet a compliance requirement, and then put off dealing with the complexity issues for another day.            

The real problem is that cloud complexity combined with too many different and uncooperative security solutions leaves you with no shared intelligence.

To overcome these challenges, you must streamline your security stack and include must-haves like: Cloud Access Security Broker (CASB) as part of your Secure Access Service Edge (SASE), Identity and Access Management (IAM), threat intelligence, and next-generation firewalls. And do so in a strategic manner that ensures all solutions work in harmony.

2. Constant vigilance is the only way forward.

So much of the discussion on cloud security revolves around technology. However, it’s not the IT team’s problem alone. Today, people are the weakest link in security. Even with a cloud-based SWG, if an employee clicks on a phishing email and enters their credentials, your whole cloud ecosystem could be at risk as attackers stealthily move and escalate privileges. While artificial intelligence (AI) and machine learning (ML) technologies help with predicting these events, and isolation layers can keep phishing attempts and malware off endpoint devices, awareness is still a central pillar of keeping the cloud secure.

3. You have to use ML/AI to take the load off analysts so they can keep a human eye on end users. 

The cloud can be safer, but you’ll always need real-time monitoring and analysis of end-user behavior. This will allow you to spot irregularities that deviate from normal usage patterns (did they modify audit trails, did they repeatedly try to download data, etc.). And at the other end of the spectrum, when that employee departs the company, do you have a process to ensure they can no longer access your cloud storage, systems, data, customer information, and intellectual properties?

To address these issues, consider completing an assessment before buying any new solutions that use AI/ML to complete low-level, high-volume tasks to take the burden of human experts such as:
 

·       Intrusion Detection & Response

·       Extended Detection and Response

·       SIEM


Cloud-First Must be Security-First

As a bonus fact, to reap the benefits of cloud computing, organizations must put security first on the list of priorities. While cloud is more secure if you take the right precautions, it takes constant evaluation and re-evaluation to ensure you have the best solutions for your ecosystem. At Cadre, we work with the best cloud security providers in the business and take an unbiased approach to review and recommend how to best secure your unique environment and reduce risk.

To learn more about integral parts of today’s cloud security, watch our recorded webinar, Demystifying SASE - A Cloud-Based Approach to Network Security.

Monique Little, Cadre Information Security

News of companies getting hacked is omnipresent. The fear, uncertainty, and doubt as a result of these reports can make you want to give up. But don’t let that dissuade you—there’s still hope and it resides in an unusual fact: more than 99% of today’s cyber attacks are human-activated.¹

You might think to yourself, how is that good? Well, for one thing, human behavior can be changed. It just requires a strong Security Awareness Program.

Security Awareness is More than Phishing Campaigns

Running phishing simulations is a common security education practice, but it is only one component among many other tactics. When we boil it down, Security Awareness is teaching employees how to develop a strong security mindset both at work and at home. That could mean using townhalls, chat channels, newsletters, and informal and formal trainings to enhance cybersecurity best practice knowledge.

Security Awareness is … not holding the door open for the person behind you, even though human nature tells you it’s common courtesy. It’s learning that threat actors leave USB drives behind and hope someone will plug it into their computer to see what’s on it (it’s in our nature as humans to be curious). It’s being aware that hackers use social media to see what your title is at work so they know who to target. It’s training employees to trust, but verify. Just because she says she’s there to fix the printer and name-drops so that it sounds legit, doesn’t make it so; always verify before leading anyone into your office space. Remember, these are just a few examples of social engineering attacks, not an exhaustive list.

When Security Incidents Happen

When an attack or breach occurs, what often has the most influence on the end result is how the organization reacts—and, how they learn from the event.

Post-event, it is critical to evaluate using these questions:

-How did the targeted user react?
-How did IT react?
-What went great?
-What opportunities are there for improvement?
-Are security tools configured correctly?
-Do you have a Security Awareness Program in place? How did it prepare the affected parties?
-Do you know what to do in case of a suspected incident?

What to Do: The #1 Rule

Knowing what to do in the case of a suspected incident is paramount. Messaging to all staff needs to be clear and encourage communication and participation. Good organizational responses should emphasize positive, defensive behaviors. This is true from the CEO to the receptionist, and to the head of IT. No matter who you are, if you have the slightest suspicion that you are experiencing an attack or have been infected with malware, don’t wait to confirm. End users need to know that IT departments would prefer false alarms than be kept in the dark about potential attacks. If anything gives an end-user pause, it should be reported immediately to IT.

It is important to note that an event or an incident is not synonymous with the B-word (rhymes with reach). Anything that happens on a network—even a false positive—is categorized as an incident. That doesn’t mean that your data has been compromised. Organizations can tie themselves in knots in fear of a public relations fallout only to discover there was never anything there. Don’t allow nomenclature to dictate how you respond.

Be Sure Users Know This

Do the users in your organization know how to contact your IT department in case of a suspected incident?

Make sure that all employees know how to contact IT during business hours, after hours or on weekends/holidays. And most importantly, how to contact IT if their email or whole computer has been compromised. Users should have email addresses, desk phone numbers and cell phone numbers of the appropriate IT contacts.

Debunking the Biggest Cybersecurity Misconception

The IT and security team are solely responsible for the organization’s cybersecurity posture. That couldn’t be further from the truth. But it underpins the importance of starting, and maturing, a Security Awareness Program.

Everyone in the organization is responsible for remaining diligent to protect business, employee, and client data. However, not everyone thinks this way. End-users must be educated in the role they play, and how “good” cybersecurity behavior isn’t simply beneficial to the business, but their own personal lives.

There is no technology that can stop all social engineering attacks since they rely on exploiting human nature—you must have ingrained security awareness as your first line of defense.

Having a strong Security Awareness Program can help to minimize security incidents within your organization. If employees know what to look for, they can do their parts to help keep your organization’s data secure. If you have questions about or need assistance in building a strong Security Awareness Program within your organization, please contact us. 

Smart Data Systems

If you lead an organization that is required to estimate software development projects, you may already know estimating software development is not easy. In fact, the entire topic of estimating software is often a contentious one within many organizations. Whether that is internal stakeholders or clients who have a desire to know what will be delivered and when, or a software development team that is hesitant to create something that stakeholders will use against them. A lot of this frustration and the challenges surrounding estimating this type of work stems from a belief that software developers should be good at estimating in the first place.

Don’t get me wrong, we humans are amazing creatures in so many ways. We have the capacity to solve complex problems, make technological advances that have made all of our lives easier and more enjoyable. And yet, despite all those achievements, we still fall prey to flawed thinking and in general humans are not always great at estimating many complex challenges. While not all software projects are complex, many tend to be and one very real reason why is how we think about complex problems and how being more aware of where that thinking can go wrong.

A great book on the process of thinking that highlights some of these basic mistakes is Thomas Kida’s  “Don’t Believe Everything You Think, The Six Mistakes We Make in Thinking”. While not specifically about software estimating, it does provide some very interesting insights and research on why most humans can make common mistakes in how they are applying critical thinking

The six basic mistakes are:

• ·         We have faulty memories
• ·         We tend to oversimplify our thinking
• ·         We sometimes misperceive the world around us
• ·         We rarely appreciate the role of chance and coincidence in shaping events
• ·         We seek to confirm, not to question, our ideas
• ·         We prefer stories to statistics

One common challenge for software teams is what is often called “the problem of perfection” or the pressure to provide “perfect” estimates. Most good teams can empathize with the need to prioritize work, the love of metrics, and the all too common need to push for estimates of work that will tell you when something will be “done”.  What can often happen with or without this pressure is good teams or developers will fall into one of Mr. Kida’s six mistakes which is our human tendency to oversimplify our thinking.

Heuristics or general rules of thumb are what most of us use to try to effectively simplify complicated judgments we need to make. They also can give us good approximate solutions to our problems. The great news is approximate solutions are surprisingly very effective and for many project estimates they can provide teams with good estimates and can keep many organizations from following into the “Perfect is the enemy of good” rut. However, the challenge is those same rules of thumbs can also lead to systematic biases that result in grossly inaccurate judgments. A common mistake is our “representativeness” rule of thumb or “of course it’s the same, it looks the same doesn’t it.” This method of oversimplification works well for many decisions as things that go together can often be similar in development. However, things will go off the tracks with this way of thinking, if enough other relevant data is overlooked, and thus often can lead to major decision errors. This is sometimes reflected in a piece of development that was done by one group of developers so the natural thought would be, it’s the same relative size of work so the new work must take the same number of hours.  A is similar to B, so therefore they must be equal, right? Factor in the relevant data that the previous development team was made up of six people all with two or more years of experience in working with this same solution and your new team consists of only two of those same people and now two new people that started last month. Is that still similar?

The great news is simplifying as a thinking strategy is not all bad. In fact, simplifying strategies will serve you quite well in most software development estimates, just remember to recognize that oversimplifying, with little or no relevant data, and your own biases will lead to major problems with how your team thinks and estimates. I would also suggest looking at more of Thomas Kida’s work or the work of others to understand how we think about problems and see if it can’t help you or your teams with your process of estimating software development.

Don Kennedy, Smart Data Systems and the Technology First Board of Directors

“We are uncovering better ways of developing software by doing it and helping others do it”

-Agile Manifesto, 2001

There is a lot of talk in and outside of the technology community about “being agile” and helping organizations increase their ability to react quickly to what seems to be an ever-changing business environment. Just in the last 18 months we have seen unprecedented spikes of demand on Health care, Manufacturing, and Logistics systems as well as perceived permanent shifts in where and how we work, shop, and visit our physicians.  At the heart of all of these changes are millions of lines of code written by craftswomen and craftsmen. Software development and engineers continue to be at the forefront of an accelerating digital change and why Technology First is proud to continue to support this community at the heart of it all. In this month’s edition we wanted to highlight some of the ideas, people, and practices from this important part of our community

One set of principles deeply entrenched in this part of the technology world are Agile Principles. They are now over twenty years old and you would assume many of us may have felt or heard of them as you worked with your developers or technical teams. While often confused with the adjective Agile, the Agile Manifesto is actually a set of principles that have evolved and continue to very much be an effective and sustainable way of working for many organizations around the world. While there also continues to be some misunderstanding of the Agile manifesto and Agile community, I hope to demystify some of what being “Agile” means to many within the software community.

Allow me first to give a very brief history of where some of these principles came from as I think this lays important groundwork. I will apologize in advance as with any history many things are lost and, in an attempt to be concise, it can be difficult to give it the adequate coverage it deserves. But in 2001 and growing out of sympathy for the need to find alternatives to documentation-driven, heavyweight software development processes, seventeen people, some competitors and most very independent thinkers, documented specific ideas they believed would provide that alternative. Underneath this manifesto of ideas are the bedrock themes of values and culture. So the manifesto and principles are really nothing more than a set of values that was intended to underpin and promote an organizational model based on People, Collaboration, and the Organizations models in which the original group would want to work.  What has since grown out of those original ideas is a celebration of a sustainable, quality, process model that works to hold up the idea that “people are our most important asset”.

With that history under us, I would also highlight critics of the principles will often confuse the original ideas and all too often accuse “Agilest” of being anti-methodology, anti-modeling, and completely against documentation. These are all incorrect beliefs, but a common theme among many critics in this way of working and building software. What the principles are and how people incorporate them into their way of working is a much longer subject that I could not begin to cover here, but my understanding is these principles stand more for certain principles than they are against anything if that makes sense. This is also where I will maybe get into a little trouble and admit some people do hide behind some of these ideas, like humans can, and will use them to fight against certain processes more than maybe they should. That said, inherently the principles are again about balance in planning, or documentation, etc. So while the principles highly value Individuals and interactions over process and tools, nowhere do these principles say you should not embrace documentation, planning, or methodologies. I will also admit I am very much a traditionalist when it comes to business in many ways and while I work with many developers, I am not a software developer myself, so it has taken me time and first hand witnessing the value of these principles to come to a better understanding of the intrinsic value they bring to people, teams, and entire businesses. While we do not have adequate time to cover these principles here I hope this brief piece and the principles themselves below will help in some way to provide insights to those unfamiliar with Agile practices. If nothing else, I would encourage you to remain open to the idea that as humans we can fall into habits and ruts of behavior all too easily and practicing new ways of working can have unforeseen benefits.

What follows is the manifesto itself and the twelve principles of Agile Software freely copied in its entirety from https://agilemanifesto.org/

We are uncovering better ways of developing
software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Please join us at the Taste of IT this November 17^th and look at our developer track for more interesting content around software development and its practices! Registration and Details here!

Dave Best, Technical Director, Mile Two

“Minimum Viable Product,” or MVP, is a well-known acronym in the software and product development community. Eric Ries popularized this term in the book, The Lean Startup. He describes the MVP as:

“[...] the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort” (https://leanstartup.co/what-is-an-mvp/).

That definition is reasonable, but the reality is more complicated. “MVP” has become a largely unhelpful term. In this article, I will present two ways that it is unhelpful and two mechanisms for mitigating those concerns.

A Lack of Shared Understanding

Shared understanding is one of the most valuable assets of a team, especially when moving quickly. It is inefficient and expensive if your team members are building too much or building the wrong things. The group may be well-aligned on the “what” you are developing, but the ambiguity of the MVP term creeps in around the edges. You may find yourself answering questions like:

●     Do we need tests?

●     That feature needs to be complete, but what about these related features?

●     What sort of user load does this need to support?

●     How, where, and which users will be using this MVP?

●     Will this become production code? Really? (How many teams have been burned by this one?)

I’ve seen the term MVP used as a stand-in for non-production work or as an excuse for bugs or poorly implemented features. This lack of shared understanding may not be a problem for the disciplined and experienced team, but I’ve repeatedly seen senior teams make poor assumptions.

The Build Trap

The second concern with MVP is the last word in the acronym - ‘product.’ Product implies a level of fidelity much higher than ‘experiment.’ The original definition and the Lean Startup book couch the MVP in terms of the scientific method. MVPs are experiments; they allow the team to test the output from a single cycle through the “Build, Measure, Learn” loop (read more about it here: http://theleanstartup.com/principles).

Shipping a product can be uncomfortable work; I’ve seen many teams get bogged down in the details of their MVP; they are doing too much (or the wrong) work because, for many groups, building a product is less daunting than facing the customer.

At Mile Two, we use a handful of terms alongside the stray MVP; experiment, design seed, prototype, mockups, etc. Our early “MVPs” for some projects were simple pen and paper or whiteboard exercises. Some relied on mockups designed in Adobe XD. When your business is developing software, you’re going to get some odd looks if you call your mockup drawn on a whiteboard your “MVP.” You’ll get fewer strange looks calling it a “Process Experiment.”

Words Matter

Fundamentally, my problem isn’t the term itself. It is a placeholder; shared understanding must support it to make it effective.

Scales of Fidelity

At Mile Two, we’ve been experimenting with using “fidelity scales” to better understand and communicate the level of effort to be invested in any endeavor. The categories that we use are in flux but include:

●     Software Fidelity

●     Design Artifact Fidelity

●     Project Resilience

●     Progress Alignment to Plan

Our goal is to develop consensus around these levels so that every team (and team member) has a shared understanding of the work needed. An experiment that is (for example) a “3” on the software fidelity scale, regarding the level of testing, reliability, and roughly how long the team will work on the iteration.

These metrics connect to the specific way that Mile Two works, but they are adaptable to the processes of other organizations.

Embrace the Experiment

One of the easiest ways to frame the work is to walk through the three parts of the “Build, Measure, Learn” loop backward:

●     What one thing are you trying to learn?

●     What can you measure so that you will learn what you need?

●     What is the simplest thing you can build to measure what you need adequately?

This framing can help you break out of the “build trap” where you over-engineer or over-develop your experiments. The “Build, Measure, Learn loop” is meant to be an iterative process; if you try to learn too many disparate things from an experiment, you can end up learning nothing at all.

At Mile Two, we believe strongly in iterative development and co-creating the solution with our customers. We bring them into the process early and often; we get feedback on small experiments that advance our (and sometimes, our customer’s) understanding of the problem domain as frequently as possible.

I’m always happy to talk about product development processes or how Mile Two can help you solve your complex problems. Feel free to send me an email at dbest@miletwo.us.

Mardi Humphreys, Change Agent, Integration Edge

Why am I, a marketing aficionado, writing about developers? Because their scarcity is about to halt the pace of innovation here in Dayton, Ohio. You know, the birthplace of aviation, the cash register, and the pop-top beverage can? This situation could hurt Dayton’s brand, and that’s where I come in.

So here we are, fully vaccinated and (somewhat) back in the office, but wait…where is everybody? Where did all the developers go? If they aren’t all WFH, (and research suggests that if you want them to work for you, you should let them work from home, but more on that later…) then they are probably being wined and dined by potential employers like Google, IBM, and Apple because good developers are hard to find. They are few, far between, and in demand right now.

In 2019, the average time it took to fill a tech position was 66 days compared to taking 43 days to fill non-tech positions. When COVID-19 sent everyone home in 2020, and multitudes of businesses moved to e-commerce, the demand for developers went up exponentially. Here at the end of Q3 2021, businesses continue to rethink their strategies thanks to the lessons learned from the digital transformation thrust upon them last year. Plus, evidence suggests that there is no going back to the way things were pre-pandemic. Competition for talent is intense. Simply put, there are more open positions than developers to fill them.

Why is there a shortage?

Every employer is now a tech employer: retail, education, finance, healthcare, etc. Reading those industry categories, you can think of at least one name for each of them. Take retail for instance. Kroger not only offers a digital shopping experience, now they are testing drone delivery right in our backyards. Kroger has nearly half a million employees and plenty of them are developers since their digital business doubled in 2020, and they plan to do $20 billion in online sales by 2023.

Lack of skills:The technology is evolving so fast (like Blockchain, Cybersecurity, and AI) and the necessary skills are so specialized (e.g., Chief Nursing Informatics Officer is a real job) that humans can neither learn fast enough, not get experience fast enough, nor interview fast enough to fill open positions.

Lack of credentials:Our colleges and universities are playing catchup in offering the languages and internships necessary to work with the emerging technologies, and employers are looking for those college and university names on resumes. To fill open positions, more employers and job seekers are turning to bootcamps as avenues to quickly upskill workforce.

If you want to be a developer, what should you learn?

There are a few things you should be well versed in to stand out from the competition and attract a lucrative salary. Employers are looking for developers who are experts in Python; followed closely by JavaScript and Go. If you are looking for certification, CompTIA has paths that are widely accepted by employers and offered by local workforce development companies. Python is the most popular language to date and experience with machine learning is quick on its heels because you have to be able to make sense of all of that collected data. Being able to legitimately list Data Science on your resume is a plus. It’s a bit vague since it could mean anything from data analytics to software engineering, but if machine learning is on your resume, data science can be too. If you are not already certified in Amazon AWS, Microsoft Azure, and/or Google Cloud, get certified. Everything is moving that way. It behooves you to be ahead of the wave. If you want to specialize, then experience in Cybersecurity, AI code testing, or IoT (especially as consumers gain access to 5G) will put you in a good position to get the role you want. But please remember, you also need soft skills like emotional intelligence, flexibility, continuous learning, strategic thinking, and habitual process improvement to thrive in a team environment.

If you employ developers, how do you keep and attract talent?

Be flexible: Remember earlier in this article when I said more on WFH later? Well, it’s later. Developers in the market for new positions are in the driver’s seat and plenty of them are driving home. Post-COVID-19, WFH is less of a perk and more of an assumption. Hey, if Microsoft can do it , so can you; particularly as it pertains to where, when, and for how long an employee works for your company. Giving employees options for working in the office, at home, or a combination of both, will help you compete for top talent. And flexibility has a wonderful side effect. It helps you with your DEI goals. Offering remote work attracts mothers, diffuses location bias, and ensures accessibility for the physically challenged.

Communicate: Offer multiple communication channels to promote team bonding. Open a Slack channel for remote workers to discuss what Netflix shows they are currently bingeing as well as separate channels for teams to collaborate on their mutual projects. Smooth onboarding by assigning new hires an ambassador to help them navigate company culture, introduce them to colleagues, and answer questions. In your emails to the entire company, normalize asking for help and promote overcoming challenges together.

Upskilling: Make continuous education for employees an item in the company budget. It should be a perk of working for you. Partner with local higher learning institutions and talk about emerging technologies, what you think you’ll need, and how you’d like to get your pipeline from them. They want to supply you with future employees as well as upskill your current workforce, you want a skilled workforce, and the workforce wants to, well, work. It’s a win-win-win that keeps everyone in the Tech Community in business.

Randy Hinders, IT Director, Mile Two

What was your first job?

Afternoon paper delivery route. This was great at teaching responsibilities and accountabilities. It’s a shame that these types of opportunities for teens are not as easily available today.

What’s the best career advice you ever received?

My dad told me as I joined the Army. Volunteer for everything. Sometimes you will get a crap job, and I did, and sometimes you will get an awesome assignment. Which I have. I raise my hand for those technical challenges that will push my understanding of a topic or business process so that I learn and grow. Sometimes they stink and might not be successful, other times they are wonderful experiences making lifelong friends in other areas of business that I would not have seen had I just stayed in my cube.

What advice would you give to aspiring IT leaders?

First, remember that it is about your team and not you. If your team is successful, only then will you be successful. Second, know and be yourself. Do not try to be someone you aren’t but do bring on people who can and will fill in your shortcomings.