Originally an LA-based videographer and self-taught developer, Kiope wanted to turn her hobby into a career. Following a coding bootcamp and a stint at a startup, she joined LinkedIn as a frontend (UI) engineer. Based in San Francisco, Kiope speaks about her meaningful accessibility work, impact at scale, and career growth as an aspiring manager.
After my undergrad degree in film studies, I jetted off to Los Angeles to start my career in Hollywood as a talent agency assistant. However, I’ve also always had a passion for coding, ever since I taught myself how to build websites as a kid. I would share interviews I had filmed with elders in my urban Native American community online, and I later acted as webmaster for the Southern California Indian Center for several years during high school.
After a few years in the film industry, I knew I wanted to take my coding hobby and turn it into a full-fledged career. So I moved to San Francisco and signed up for a coding bootcamp. This would be the first step toward my role today at LinkedIn.
A distinctively fun interview
Before I joined LinkedIn, I was working at a start-up called Mulesoft (now part of Salesforce) where I was part of a very small frontend engineering team. This was a great first software engineering job for someone like me with a non-traditional engineering background, because I got tons of practical hands-on experience building lots of products at a fast pace.
But to grow my engineering skills, I knew I needed to work at a bigger company where I could learn from a large pool of top-notch engineers, and gain experience building well-crafted products at scale.
When I was trying to figure out where to go next, I reached out to a fellow grad from my coding boot camp who was at LinkedIn. I’d heard great things from her about working there, and she introduced me to a recruiter. As soon as I finished the onsite interview, I knew I wanted to join LinkedIn: I’d never had so much fun in an interview in my entire life!
Not only were the interview’s technical problems interesting, but I could immediately tell that every single person I interviewed with truly enjoyed working for LinkedIn, and I wanted to be a part of that culture.
8K+ engineers to support me
In addition to culture, LinkedIn also offered the scale I was looking for, with over 8,000 engineers worldwide representing specialties like backend (apps), frontend (UI), mobile, and more. And here, you can really lean on more experienced engineers as you learn.
At LinkedIn, you learn more than just how to write quick and efficient code. You learn how to write good code. Maintaining high standards of code craftsmanship is one of our key values here, and, as an engineer with a non-traditional background who has had to learn primarily through hands-on experience on the job, I’ve benefited tremendously from this practice.
Transitioning teams and offices
When I first joined LinkedIn, I worked on our flagship, consumer product on the Growth and SEO (Search Engine Advertising) team at our Silicon Valley headquarters in Mountain View, California. Roughly 18 months into the job, I told my manager the commute — which was averaging 4-hour, daily roundtrip from my home in San Francisco — was taking a toll on me.
My manager was very supportive, and worked with me over the next several months to meet with many different managers to find the right fit, and ultimately help me transition over to one of our enterprise teams, LinkedIn Sales Solutions (LSS), so that I could work closer to home.
I’ve bounced around many different sub-teams over the last several years on the LSS team, but I currently lead our Customer Relationship Management (CRM) Enablement team, which builds features that allow customers of our LinkedIn Sales Navigator and LinkedIn Sales Insights product to integrate CRM data into their LinkedIn sales workflows.
Delivering value for millions of users
Scale to me also means impact. Every day, our engineering work directly helps millions of job seekers to find their dream jobs and build new skills, and hundreds of thousands of large and small businesses grow, even during the pandemic. You can truly see how you’re delivering value.
This is especially true in my frontend engineering work on the LinkedIn Sales Solutions team, working on products like LinkedIn Sales Navigator and Sales Insights, which supports 1.2 million sellers and counting. To know that you’re helping a startup founder scale her business global, or a CEO take their brick-and-mortar business digital mid-pandemic is incredibly powerful.
All of the engineers on our team are encouraged to take an active role in the product roadmap and problem-solve alongside other engineers, product managers, product designers, product marketers, and data scientists. It’s a level of collaboration that is not always possible as a junior or mid-level engineer at other companies and I’m glad I’ve found that at LinkedIn.
Making LinkedIn accessible to all
What really makes LinkedIn unique is our culture. Everyone seems to genuinely enjoy coming to work and many of my teammates have been at LinkedIn for four years or longer. I also love how many women engineers we have here, something that’s still a rarity in this industry — my team, for example, is currently half women.
Per the video below, one of my most memorable projects at LinkedIn is Access[in], which was a company-wide initiative to make our products more inclusive and accessible to everyone, including members (i.e., LinkedIn users) with disabilities. As a frontend engineer, I thought I knew a fair amount about how to make products accessible, like adding Accessible Rich Internet Applications (ARIA) tags and writing semantic markup. However, it turns out there’s much more to it than that.
To become more knowledgeable, I participated in LinkedIn’s Accessibility Champions program, where we not only learned how to write accessible code, but we also learned how to think like users with disabilities by using tools like screen readers and high contrast mode to navigate through our products. It was an eye-opening experience to look at our platform from the perspective of our members. There is always more to learn and I am excited to do just that!
Endless options for growth
I’ve had the opportunity to work with a wide variety of teams here. For example, I used to work on a feature called Public Profile, which is basically a LinkedIn profile that a user sees if they’re not logged in as a member. Our Product Operations team flagged that we received complaints about adjusting basic settings on the public profile.. So we worked with Product Operations and User Experience (UX) to develop iterations to address member concerns, and ultimately redesigned the page. The complaints immediately went down, so we knew we had made the right decision. LinkedIn makes it clear that if you want to try something new, they will support you.
Per the video below, one of the most memorable experiences that I’ve had at LinkedIn has been participating in LinkedIn’s REACH apprentice program, which helps aspiring, backend (Apps), data science & machine learning, frontend (UI) and mobile engineers from non-traditional backgrounds an opportunity to get their foot in the door in the tech industry and begin or continue their technical career.
I was lucky enough to participate in REACH’s first cohort, mentoring an apprentice who later joined us a a full-time engineer I’ve remained involved in the program over the years in different capacities, but it’s allowed me to meet a lot of different current and aspiring engineers from different backgrounds and LinkedIn teams — and support their growth.
Preparing for engineering management
One of our core values here at LinkedIn is transformation. In the several years since I’ve been here, I’ve gone through three individual-contributor (IC) role changes (i.e., software engineer, senior software engineer, staff engineer) across two engineering teams. Per the video below, that’s included valuable experiences like a book club with our engineering vice president and executive coaching session as part of a LinkedIn Women in Tech group to strengthen my negotiations and public-speaking skills as an aspiring manager.
After getting formally promoted to Staff Engineer earlier this year, I am now embarking on my latest transformation — transitioning into engineering management. I was initially nervous about doing this (like many ICs, I wasn’t sure if management was the right path for me), but LinkedIn offers an Apprentice Manager Program (also known as AMP) to support those of us making the IC to Manager transition. AMP lasts an entire quarter and there are workshops and coaching circles every week covering topics such as effective one-on-one meetings, talent acquisition, building/managing/leading, and intent vs. impact.
We get to learn from experienced managers and connect with other new managers going through this career change as well. Most of the workshops are virtual, but those of us based in San Francisco like to get together for lunch to swap new manager stories with each other.
Whether it’s learning a new framework, working with a career coach, or even just taking advantage of the perks like the excellent free food, LinkedIn is a place where you’re supported to grow, especially as a female engineer. I know it’s true because I’ve experienced it in action.
Based in San Francisco, Kiope is a frontend (UI) staff engineer and apprentice engineering manager with our LinkedIn Sales Solutions team, where she currently works on CRM integrations for our sales products. Before joining LinkedIn, she was a videographer and talent agent assistant at Creative Artists Agency, and a software engineer at Mulesoft (now part of Salesforce).
She holds a bachelor’s in Film and Media Studies from Stanford University, and is a graduate of Dev Bootcamp. Outside of work, Kiope enjoys skiing, figure skating, practicing hula, and finding new ways to make art with technology in her free time; and she is a member of the Red Lake Band of Chippewa Indians, and Native Hawaiians.
Editor’s note: Considering an engineering/tech career at LinkedIn? In this Career Stories series, you’ll hear first-hand from our engineers and technologists about real life at LinkedIn—including our meaningful work, collaborative culture, and transformational growth. For more on tech careers at LinkedIn, visit: lnkd.in/EngCareers.
(Re)building Threat Detection and Incident Response at LinkedIn
LinkedIn connects and empowers more than 875 million members and over the past few years, has undergone tremendous growth. As an integral part of the Information Security organization at LinkedIn, the Threat Detection and Incident Response team (aka SEEK) defends LinkedIn against computer security threats. As we continue to experience a rapid growth trajectory, the SEEK team decided to reimagine its capabilities and the scale of its monitoring and response solutions. What SEEK set out to do was akin to shooting for the moon, so we named the program “Moonbase.” Moonbase set the stage for significantly more mature capabilities that ultimately led to some impressive results. With Moonbase, we were able to reduce incident investigation times by 50%, increase threat detection coverage expansion by 900%, and reduce our time to detect and contain security incidents from weeks or days to hours.
In this blog, we will discuss how LinkedIn rebuilt its security operations platform and teams, scaled to protect nearly 20,000 employees and more than 875 million members, and our approach and strategy to achieve this objective. In subsequent posts, we will do a deep dive into how we built and scaled threat detection, improved asset visibility, and enhanced our ability to respond to incidents within minutes, with many lessons learned along the way.
Software-defined Security Operations Center (SOC)
While these data points demonstrated some of the return on the investment, they didn’t show how much scaling to Moonbase improved the quality of life for our security analysts and engineers. With Moonbase, we were able to eliminate the need to manually search through CSV files on a remote file server, or the need to download logs and other datasets directly for processing and searching. The move to a software-defined and cloud-centric security operations center accelerated the team’s ability to analyze more data in more detail, while reducing the toil of manual acquisition, transformation, and exploration of data.
Having scaled other initiatives in the past, we knew before we started the program rebuild we would need strong guiding principles to keep us on track, within scope, and set reasonable expectations.
Preserving Human Capital
As we thought about pursuing a Software-defined SOC framework for our threat detection and incident response program, preserving our human capital was one of the main driving factors. This principle continues to drive the team, leading to outcomes such as reduced toil through automation, maximized true positives, tight collaboration between our detection engineers and incident responders, and semi-automated triage and investigation activities.
It’s commonly said that security is everyone’s responsibility, and that includes threat detection and incident response. In our experience, centralizing all responsibilities of threat detection and incident response within a single team restricts progress. Democratization can be a force multiplier and a catalyst for rapid progress if approached pragmatically. For example, we developed a user attestation platform where a user is informed about suspicious activity, provided context around why we think it is suspicious, and asked a question of whether they recognize the suspicious activity. Depending on the user’s response and circumstantial factors, a workflow is triggered that could lead to an incident being opened for investigation. This helped reduce toil and the time to contain threats by offering an immediate response to an unusual activity. Democratization has been applied to several other use cases with varying degrees of success from gaining visibility to gathering threat detection ideas.
Building for the future while addressing the present
The rebuilding of the threat detection and incident response program was done while still running the existing operations. With this approach, we were able to carve out space among the team to work on more strategic initiatives.
Security, scalability, and reliability of infrastructure
As the team increased its visibility tenfold, the demand for data normalization and searching continued to grow. Our platform, tooling, data, and processes need reliability and scalability in the most critical times, like during an incident or an active attack. The team ensured a focus on resiliency in the face of setbacks such as software bugs or system failures. To get ahead of potential problems, we committed to planning for failure, early warning, and recovery states to ensure our critical detection and response systems were available when most needed. Security of the LinkedIn platform is at the forefront of everything the team does and is etched into our thought process as we build these systems.
As we started thinking about the broad problem space we needed to address, a few fundamental questions came up.
The first was, “What visibility would the threat detection and incident response team need to be effective?” This fundamental question helped us shape our thinking and requirements about how to rebuild the function. There are several ways to approach building out an operational security response and detection engineering team. Whether that’s an incident response firm on retainer, an in-house security operations center, a managed service provider, or a combination of both, there are plenty of approaches that work for many organizations. At LinkedIn, we wanted to work with what we already had, which was a great engineering team and culture, the ability to take some intelligent risks, and the support of our peers to help build and maintain the pipeline and platform we needed to be effective.
The next question that we asked was, “How do we provide coverage for the threats affecting our infrastructure and users?” There are many areas that require attention when building out a Software-defined SOC and it can be difficult to know where to prioritize your efforts. The long-term goal was inspired by the original intent of the SOCless concept, which suggests that mostly all incident handling would be automated with a few human checkpoints to ensure quality and accuracy, paired with in-depth investigations as necessary. Given our team’s skills and development-focused culture, the benefit of reducing the need for human interaction in security monitoring operations was an attractive idea. With this, we needed to build and maintain development, logging, and alerting pipelines, decide what data sources to consume, and decide what detections to prioritize.
“What are the most important assets we need to protect?” was the third question we asked. Due to the scope of Moonbase, we had to decide how to deliver the biggest impact on security before we had designed the new processes or completed the deployment. This meant we focused on the most important assets first, commonly known as “Crown Jewels.” Starting with systems we knew and understood, we could more easily test our detection pipeline. Many of the early onboarded data sources and subsequent detections were from the Crown Jewels. Ultimately, this was a quick start for us, but did not yet offer the comprehensive visibility and detection capabilities we needed.
This leads us to the last question we asked, “How can we improve the lives of our incident responders with a small team?” Early detections in the new system, while eventually iterated or tuned, led to classic analyst fatigue. To ease the burden and improve the lives of the responders, we built a simple tuning request functionality, which enables quick feedback and the potential to pause on a lower-quality detection. This principle has enabled us to maintain a reasonable expectation of results from analysts while reducing the potential for additional fatigue, alert overload, and job dissatisfaction. Additionally, we have focused on decentralizing the early phases of the security monitoring process, which has led to significantly less toil and investigation required from analysts. When a class of alerts can be sent with additional context to potential victims or sources of the alert, with the proper failsafes in place the analyst can focus on responding to the true threats. Another example is directly notifying a system owner or responsible team whenever there are unusual or high-risk activities such as a new administrator, new two-factor accounts, credential changes, etc. If the activity is normal, expected, or a scheduled administration activity that can be confirmed by the system owners, again with the proper failsafes, there is no need to directly notify the incident response team. Tickets generated from security alerts are still created and logged for analysis and quality assurance, but reviewing a select number of tickets periodically for accuracy is preferred to manually communicating through cases that likely have no impact or threat.
Phase 1: Foundation and visibility
The first phase of rebuilding our security platform was our end-to-end infrastructure and process development. We already had a small team and some data sources, including some security-specific telemetry (endpoint and network detection technologies), so we focused on finding the right platform first and then on building strong processes and infrastructure around it. Given the rapidly growing business, a lean team, and other constraints, a few base requirements were established for the foundational platform(s).
Low operational overhead
This enables the team to focus on the analysis tasks meant for humans and lets automation do the work of data gathering and transformation. Constantly working through the critical, yet laborious extract, transform, and load processes while trying to hunt for and respond to threats is a quick recipe for burnout.
Built-in scalability and reliability
Reliability is a naturally critical component in any security system, however, with a small team, it must be low maintenance and easy to scale. Additionally, time invested should be primarily focused on building on top of the platform, rather than keeping the platform operational. This is one of the strongest arguments for a cloud solution, as it allows us to work with our internal IT partners and cloud service providers. Through this, we can ensure a reliable backbone for our pipelines and alerting, along with other programs that coordinate these processes to gather data and context.
Rapid time to value
Building a functioning operational team takes time and practice, so when choosing the technology toolset, we need to see results quickly to focus on process improvement and developing other important capabilities.
To minimize context switching and inefficiencies, we want the data, context, and all entity information to be available in our alerting and monitoring system. This naturally leads toward a log management system and security information and event management (SIEM) overlays.
By the end of this phase, we wanted to be able to onboard a handful of data sources to a collaborative platform where we could run searches, write detections, and automatically respond to incidents. This was the beginning of our methodical approach to deploying detections through a traditional CI/CD pipeline.
Capturing data at scale, and in a heterogeneous environment, is a huge challenge on its own. Not all sources can use the same pipelines, and developing and maintaining hundreds of data pipelines is too much administrative overhead for a small team. We started our search for a solution internally and decided on a hybrid solution. LinkedIn already has a robust data streaming and processing infrastructure in the form of Kafka and Samza, which ships trillions of messages (17 Trillion messages per day!) and processes hundreds of petabytes of data. Most of the LinkedIn production and supporting infrastructure is already capable of transporting data through these pipelines, which made them an attractive early target. However, LinkedIn has organically grown and between acquisitions, software-as-a-service applications, different cloud platforms, and other factors, there needed to be other supported and reliable modes of transport. After analysis, the team developed four strategic modes of data collection including the ultimate fallback of REST APIs provided by the SIEM.
A simplified diagram of data collection pipelines
Most of our infrastructure is already capable of writing to Kafka. With reliability and scalability in mind, Kafka was a perfect choice for a primary data collection medium.
Infrastructure, like firewalls, is not capable of writing to Kafka inherently. We operate a cluster of Syslog collectors for anything that supports Syslog export, but not Kafka messages.
Serverless data pipelines
These are employed mostly for collecting logs from SaaS, PaaS, and other cloud platforms.
The data collector REST API is the collection mechanism natively supported by the SIEM for accepting logs and storing them against known schemas. This is currently the most commonly used transport mechanism, scaling to hundreds of terabytes.
Security infrastructure as code
The team has deep experience with security tooling and platform over the years. As we rebuilt our foundational infrastructure, we knew we needed to apply a more comprehensive engineering first approach. One aspect of this engineering first approach to defense infrastructure was treating everything as code to maintain consistency, reliability, and quality. This led to the development of the Moonbase continuous integration and continuous deployment (CI/CD) pipeline. Through the CI/CD pipeline the team manages all detections, data source definitions and parsers, automated playbooks and serverless functions, and Jupyter notebooks used for investigations, etc.
Having every engineer work on the development and improvement of the detection playbooks, as well as having the applied rigor that comes from the typical CI/CD review and testing stages, gives the team a strong, templateable, and heavily quality-assured playbook for detecting and responding to threats. Simple mistakes or detections that could lead to unnecessary resource usage are easily prevented through the peer review process. Our tailored comprehensive CI validations for each resource type help us to programmatically detect any issues in these artifacts within the PR validation process and improve the deployment success rate significantly. Change tracking is also much easier as pull request IDs can be added to investigation tickets for reference or used in other parts of the tuning process.
The Moonbase CI/CD pipeline is serverless, built on top of Azure DevOps. Azure Repos is a source code management solution similar to Github that we use for all our code with deployment done through Azure Pipelines. Azure Pipelines is a robust CI/CD platform that supports multi-stage deployments, integration with Azure CLI tasks, integration with Azure Repos, PR-triggered CI builds, etc. This also helps us deploy the same resource to multiple SIEM instances within different scopes only by updating deployment configuration settings. We leverage both to build, validate, and deploy detections and all other deployables, following a trunk-based development model. Artifacts like queries are enriched in the pipeline before deployment. These enrichments help not only with detections but also help track threat detection coverage, metrics for incidents, etc.
While there are many features of a CI/CD pipeline like constant validation, decentralized review, mandatory documentation, and metrics, the templating aspect is one of the stronger points of this detection engineering approach. The pipeline allows any analyst on the team to quickly deploy a new detection or update an existing one. In this screenshot from VSCode you can see an example detection template looking for unexpected activity from inactive service principals (SPN).
The pane on the right shows the actual detection within its template. The entire detection isn’t pictured here to obscure some internal-only information, but this snippet shows what a detection engineer has configured for this specific detection in the orange-colored text. Other items, like how far back to search and the severity of the alert, can be specified in the template.
Additionally, we explicitly configured the data sources needed to execute the detection within the template.
To assist in understanding our coverage of threats, we map each detection to its MITRE ATT&CK ID and Sub ID. Not only does this help us track our coverage, but it also enables us to write additional queries or detections that collate any technique or class of attacks into a single report.
Finally, the query itself is listed (in this case we’re using KQL to search the data).
Our internally-developed CLI generates boilerplate templates for new artifacts and helps engineers maintain quality and their deployment velocity and improves productivity by helping engineers validate their changes locally.
It is important to create space for innovation. Earlier, the team often found themselves deep in operational toil, going from one issue to another. A very deliberate effort to pause operational work, which yielded a low return on investment, really helped the team make space for innovation. Staying true to the guiding principles of automating what makes sense, the team uses automation heavily to remove as much of the mundane and repeatable work as possible. The following are some automation tools and platforms that the team currently uses. These platforms and the automation have enabled the team to unlock efficiency and quality across the functions.
Automated playbooks and workflow automation
The team leverages a no-code workflow automation platform that comes tightly integrated with the cloud SIEM. It is a highly scalable integration platform that allows building solutions quickly due to the many built-in connectors across the product ecosystem like Jira, ServiceNow, and several custom tools that the team depends on. Some use cases include alert and incident enrichment, which makes all context required to triage an alert available to the engineers, and running automated post-alert playbooks for prioritization and running automated containment and remediation jobs, and other business workflows. Another use case is automated quality control and post-incident processing, which allows us to learn lessons from previous incidents.
Several complex automation jobs are written as serverless functions. These are easy to deploy, scalable, and have a very low operational overhead. These functions are used for ingesting data from on-prem and online sources, along with more complex automation jobs like the containment of compromised identities.
Resilience and reliability are broad topics, and thus not covered in this blog, however, data and platform reliability are absolutely critical. A change in underlying data can have major cascading effects on detection and response. Data availability during incidents is key, too. Outside of the core monitoring of the platforms, the team relied on three different avenues for signals of degraded performance:
Looking at things like message drop rate, latency, and volume allows the team to quickly identify any issues before they impact detections and/or response activities.
Sending messages to ensure the pipeline is functional and that messages get from source to destination within expected timeframes.
Ideal behavior indicators (operational alerts)
Data Sources are dynamic in nature. When onboarding a datasource, a detection is developed to monitor the datasource health. For example, sending an alert when the number of unique source hosts decreases more than the threshold percentage.
These are only some of the health checks and alerts we developed to ensure that our systems were logging and reporting properly. We try to graph availability as well as detection efficacy data to assist us in constantly re-evaluating our detection posture and accuracy.
What did we get for all this?
Threat detection and incident response is not a purely operational problem, using an engineering lens paid off well for our team. If this is not something you’re doing, we hope this post drives you toward that realization. Leaving the processes to organic growth is unsustainable and violates our guiding principles designed to prevent burnout for the team and ensure a quality response. In the end, we achieved significant success and improvements. We were able to expand our data collection infrastructure by 10x going from gigabytes to petabytes, our average time to triage incidents went from hours to minutes, we were able to maintain 99.99% uptime for the platform and connected tooling, and correlation was now possible, significantly reducing alert fatigue and improving precision. Additionally, automated response playbooks allowed us to reduce toil for response and automatically handle simple tasks like enrichment, case creation and updates, or additional evidence gathering. We were also able to quickly integrate threat intelligence into our enrichment pipeline, providing a much richer context for investigations.
More work to do
What we’ve covered in this blog represents the work of a handful of engineers, product and project managers, analysts, and developers over a relatively short period of time. We learned many valuable lessons over time and have since developed new ways of thinking about detection, automated response, and scaling. Whatever platform a team decides on using for security monitoring, it cannot be overstated how important a solid design and architecture will be to its eventual success.
In a future post, we’ll cover more details on how incident response ties in with our platforms and pipelines and a re-architected approach to detection engineering, including the lessons we learned.
This work would not have been possible without the talented team of people supporting our success.
Core contributors: Vishal Mujumdar, Amir Jalali, Alex Harding, Tom Leahy, Tanvi Kolte, Arthur Kao, Swathi Chandrasekar, Erik Miyake, Prateek Jain, Lalith Machiraju, Gaurav Gupta, Brian Pierini, Sergei Rousakov, Jeff Bollinger and several other partners within the organization.
How LinkedIn Ditched the “One Size Fits All” Hiring Approach for InfoSec and Won
What drew me to LinkedIn was the chance to take on the challenge of scaling and adapting the security framework for the world’s largest professional network. Today, our Information Security (InfoSec) team is responsible for protecting LinkedIn’s infrastructure and data for our members, customers, and employees. As our platform has scaled, our security programs and strategies have grown in tandem to keep up with the company’s trajectory. But we haven’t stopped there. We want to be more than just protectors of our members, customers, and all the data we process internally and externally; we also want to expand our efforts to proactively support the goals of our business and the people who join our team. I’m a firm believer that cybersecurity is as much a business function as a technical one, and that means we have a crucial role in contributing to our company’s ongoing growth.
To realize this vision of an InfoSec team that’s both protecting our company and enabling business growth, we need to attract and retain world-class talent. As the demand for cybersecurity professionals has remained high, this is a major challenge for many organizations. According to ISACA’s State of Cybersecurity 2022 report, 62% of survey respondents said their cybersecurity teams are either significantly or somewhat understaffed, and 63% said their teams had unfilled roles. And amid the Great Reshuffle, the ability to retain such in-demand talent has become more important than ever.
Despite these headwinds, we were able to attract and retain strong talent for our InfoSec team by reimagining our approach on a simple principle: cyber threats come in all shapes and sizes, so our InfoSec team should mirror that diversity, too. From a hiring perspective, this meant that instead of looking for people who fit a specific mold—particular educational backgrounds, prior experiences, or specific training—we doubled down on looking for and leaning into people with diverse experiences, perspectives, and skills needed to fit both our culture and our team’s priorities. As a result of this skills-first hiring approach, the number of new members joining our InfoSec team increased by 182% in 2022 as compared to 2021.
From a retention perspective, we took a similarly people-centric approach by meeting our team members where they are to best support their contributions to the InfoSec organization. This encompassed everything from providing a remote-first working option to enabling internal mobility as team members sought new challenges to grow in their careers. It might seem counterintuitive to be excited when an all-star player on your team wants to try a different role, but the fresh perspective and renewed energy they bring to their new area of focus will only benefit the organization as a whole.
These are the three components that we incorporated into our reimagined approach that helped us build the InfoSec organization we have today.
Broaden your talent pool
One of the practices we’ve leaned into is investment hiring, which we define as fostering talent through on-the-job skills development. While the more traditional version of this strategy was used only for very easy-to-train skills, taking an intentional approach and having a strong focus on longer-term talent support and skill development can lead to some excellent results even for technical career paths. This has the benefit of creating an opportunity for your team members to tailor their skills to what’s needed in your particular environment.
Investment hiring can have many forms. For instance, our REACH apprenticeship program at LinkedIn gives those with non-traditional backgrounds the opportunity to get their foot in the door and develop their technical skills. REACH has been an excellent source of talent for the InfoSec team at LinkedIn and InfoSec has doubled down on the program. I’m excited to see that in the last two years nearly 10% of all apprentices hired by LinkedIn joined our team.
Another aspect of investment hiring is to leverage learning and training opportunities for skill development. These types of courses can be a great way to uplevel your talent—it’s one of the reasons why we offer a variety of cybersecurity courses and learning paths through LinkedIn Learning. In fact, one of the REACH apprentices who’s since joined our team full-time got their start through online introductory coursework.
Adopt a skills-first mindset
To successfully grow and strengthen our InfoSec team, we have adopted a skills-first approach when hiring talent. This mindset means that you look at a prospective candidate’s existing skills and think about their transferability to an InfoSec role. For instance, our team began hiring software engineers with strong computer science backgrounds who didn’t necessarily have InfoSec experience. We found that many of the fundamental skills for areas like site reliability engineering transferred well to cybersecurity work. We could attract a deeper and stronger pool of talent by avoiding a reliance on specific, niche skills for our candidates.
An additional benefit of this approach is that it can better future-proof your organization for the inevitable changes we constantly see in the technology field. Today’s most popular coding language or infrastructure skills can often be relegated to “obsolete” in just a few years, which means that focusing exclusively on niche skills can hamper your team’s ability to pivot and innovate. By concentrating instead on fundamental and foundational skills, you can build a more adaptable team.
Meet talent where they are
Meeting talent where they are means being flexible to accommodate the preferences of your team, where possible, whether that’s in where they’re based or in the specific role they have. This can benefit both recruiting and retention for your organization and it also applies to more than just geography, although that can be a key component.
As part of our hiring process, we embraced a remote-first option for candidates. Nearly a quarter of our InfoSec team is currently working remotely full-time. A key benefit of remote work is that it opens up a broader talent pool, and can also help build a more diverse team.
Another component of meeting talent where they are is finding opportunities to create new opportunities and internal mobility for team members to improve retention and keep your team engaged. We encourage our team members to explore opportunities they find professionally challenging and fulfilling, which helps us keep a strong team even as individual members may shift to new roles.
Don’t be afraid to reimagine your approach
It’s important to note that these practices work best when used in combination with each other. While there can be real challenges in finding InfoSec talent, there are also opportunities to explore new ways of closing the gap. Our team at LinkedIn has leaned into this opportunity and has been able to grow and strengthen our InfoSec organization as a result. Hopefully sharing our experiences inspires other organizations to reimagine their approach and help more candidates find exciting opportunities in cybersecurity.
Career stories: Four engineering careers. One LinkedIn.
LinkedIn’s Next Play culture celebrates transformational growth and internal mobility, and engineering leader Shalini is its biggest champion. Based in Silicon Valley, this mom of three walks us through her impactful career journey from our LinkedIn consumer and data teams, then woring on the LinkedIn Sales Solutions team, to now working for LinkedIn Talent Solutions.
Before joining LinkedIn, I worked my way up in Silicon Valley’s consumer software engineering space as a backend (apps) engineer. As my career propelled forward, and I transitioned to managing a team of backend, frontend (UI), and mobile engineers, I really found fulfillment in supporting the engineers around me as we built products together. I quickly realized that management could offer this exciting path of learning and helping engineers grow.
When I started at LinkedIn in 2015 as a senior engineering manager on the search experience team, I was impressed with how supportive the company culture was to my management style. In my first project, my team retooled the LinkedIn mobile site to give our global user base a better experience, as part of our Consumer Flagship product team.
Then, I was asked to pivot and spearhead the creation of a new data applications team that involved full stack development. Even though building internal tools for engineering was new territory for me, I was eager to learn, and — as I like to say — stumble forward with LinkedIn’s support. What initially started as a small team of about 10 has blossomed into 50+ engineers.
My work on the Data team included a site-wide project around changing the way we track events to make our data cleaner and more effective, to be used by both the data science and artificial intelligence (AI) teams. The following video explains how my multi-year project involved extracting the complexity, so when you make one change on one side it brought together product engineering, data science, site-reliability (SRE), analyst and the marketing teams, and how this changed how we think and use data.
LinkedIn is unique where we have both consumer and enterprise products. And I wanted to learn about how it is to build and manage an enterprise software. I explored various roles and products and joined the Sales Navigator team in the LinkedIn Sales Solutions organization. We were about 80-100 engineers that operated as a close-knit small org which was simpler and faster to navigate more like a start-up compared to my previous roles that were part of much larger organizations.
Transformation and looking ahead are both integral to the collaborative culture here at LinkedIn. When I was planning out my next career move, my managers at LinkedIn were invaluable, giving me the individual attention I needed to progress into my ideal role. As I explored different departments, the mentors I spoke with were generous with their time, advice, and coaching in helping me find the best career fit for me. They truly invested in my career development, ensuring that I found roles I was passionate about and aligned with where I wanted to grow.
Their mentorship was pivotal in landing my latest role as an engineering senior director (see video below) on the LinkedIn Talent Solutions team, where I focus on creating a more equitable and efficient talent marketplace. After the pandemic, skills-based hiring became increasingly valuable to the job search. This is where my role comes into play — my team works on products to build a world where people can be seen by their skills, not just the title or degree.
We build product features such as tools that help companies search for candidates based on skills and to explicitly list skills in job postings, as well as allowing job seekers to clearly compare how their skills match up to a position’s requirements. At LinkedIn, we aim to transform the skills-matching process in the job search, and I am excited about what lies ahead in my career with this team.
Through all these career transformations, my team and managers have been incredibly supportive and flexible, as a mom of three. There have been many instances of juggling work and kids especially as school events happen during working hours. However, I have had support from my team and management to balance my time.
One particular instance I remember was when I had a career conversation scheduled with a vice president, and it was right before the play audition for my 5th grader. I had to drive 30 minutes to get there. It was the only time available, so we decided to chat on the phone while I drove to school. Such flexibility and understanding have helped me to integrate my family and work in a balanced way.
My passion for skills-building led to founding one of my most fulfilling projects to date: LinkedIn’s engineering apprenticeship program, REACH. It’s a multi-year program that helps our engineers uplevel their technical skills in areas from data science, to artificial intelligence (AI), to backend (apps) engineering and user experience.
Per the video below, this started as a grassroots initiative over five years ago and now, the program has now helped over 100 apprentices become part of LinkedIn’s engineering teams. It has been so fulfilling to watch the participants channel their passions into building their future here and I’m proud to have recently celebrated our five year anniversary.
When engineers who are just starting their careers tell me they want to be managers, I always ask about their motivations. I believe a desire to support people should drive that decision, because at the end of the day you remember some of your projects as a manager, but you always remember the people you worked with.
Ask yourself where do you find the most joy? If helping others learn and grow brings you joy, such a role will come more naturally to you. Seek out what brings you joy at work, and your career will follow suit.
Based in Silicon Valley, Shalini is an engineering senior director on our LinkedIn Talent Solutions team. A great example of LinkedIn’s Next Play internal-mobility culture, she also served in consumer and enterprise engineering management roles on our Consumer, Data and LinkedIn Sales Solutions teams. Before joining LinkedIn, she worked for Universal Planet and Sonasoft as a senior software engineer before taking on new engineering leadership roles at eBay as a principal software engineer and product engineering director.
Shalini holds a bachelor’s and master’s in mathematics and computer applications from Banasthali Vidyapith University, and a master’s in computer science from California State University, Hayward. Shalini enjoys spending her free time with her three kids, and helping them learn and grow.
Editor’s note: Considering an engineering/tech career at LinkedIn? In this Career Stories series, you’ll hear first-hand from our engineers and technologists about real life at LinkedIn — including our meaningful work, collaborative culture, and transformational growth. For more on tech careers at LinkedIn, visit: lnkd.in/EngCareers.
What Are WhatsApp Polls and How Do You Use Them? All You Need to Know
Elon Musk Calls Donald Trump’s Twitter Ban ‘Grave Mistake’, Condemns Violence
WhatsApp Reportedly Testing Voice Status Update for iOS Beta: All Details
Elon Musk Says Twitter Blue With Gold, Grey, Blue Check Marks to Relaunch on December 2
Jio, Rolling Stone India Partner to Launch Platfom Short Video App for Creators: All Details
Elon Musk Says Twitter Will Grant ‘General Amnesty’ for Suspended Accounts From Next Week
Sending Messages via WhatsApp in Your Node.js Application
(Re)building Threat Detection and Incident Response at LinkedIn
Access Levels for Gaming Apps
How LinkedIn Ditched the “One Size Fits All” Hiring Approach for InfoSec and Won
Introducing the Product Tagging API for Reels to the Instagram Platform
Introducing the ‘Instagram Explore home’ Ads Placements via the Instagram Marketing API
FACEBOOK2 weeks ago
Building WhatsApp Message Templates for E-commerce
FACEBOOK2 weeks ago
Dynolog: Open source system observability
FACEBOOK7 days ago
How to Send Interactive Messages with the WhatsApp Business Platform
Uncategorized2 weeks ago
How to Make Money on Social Media: Tips for Brands and Creators
FACEBOOK6 days ago
Hermit: Deterministic Linux for Controlled Testing and Software Bug-finding
FACEBOOK6 days ago
Building Intuitive Interactions in VR: Interaction SDK, First Hand Showcase and Other Resources
OTHER2 weeks ago
WhatsApp Testing Companion Mode on Android; Do Not Disturb, Tablet Client in the Works: Reports
OTHER1 week ago
Twitter Sued by Disabled Employee Over Elon Musk’s Ban on Remote Work