When security incidents from software defects happen, retrospectives often tell the story of heroic remediation in the form of a few hundred lines of code (or less) but maximum organizational disruption: all-hands-on-deck root cause investigations and executives working 24/7 to control fallout. 

This reality has been the main drive behind the adoption of “Shift-Left” security—a proactive approach that integrates security testing like static application security testing (SAST) and software composition analysis (SCA) early in the development process. 

Common pre-production security controls in a software development lifecycle (SDLC).

Catching and fixing security vulnerabilities before they reach build, test, release, and deployment—before they even exist seems easy to justify, right?

Turns out it’s more complicated than that:

1. Return on Investment (ROI) arguments rely on speculation and fear: cost savings by avoiding unexpected losses.
2. Business priorities typically focus on revenue-generating activities. The prospect of adding any extra step to pre-merge workflows when a company is already behind on deadlines is a tough pill to swallow.
3. It’s hard to prove #1, very easy to prove #2.

Here, security leaders find themselves in an all-too-familiar paradox: if an ounce of prevention is worth a pound of cure, how is it so difficult to prove?

Rethinking return on security investment

Is a “return” on loss prevention the right justification for security investment? How do we quantify how well an organization outsmarts cybercriminals? How many organizations budget for expected data breaches as part of fiscal year planning?

Cybercriminal activity isn’t a predictable variable in business operations, but risk mitigation is. A more accurate framework for investment decision-making is return on mitigation (RoM)—the financial impact of preventing breaches, regulation penalties, and reputational damage.

Using the RoM model, we can estimate business impact for pre-attack mitigation. Imagine your team catches a high-severity SQL injection vulnerability during routine testing. Based on the $5.45M average cost of a data breach, its high severity, and exploitation likelihood (5.5%), the estimated mitigated losses is about $149,875. 

For more, check out HackerOne’s RoM calculator to see how much financial damage your security investments prevent.

The true cost gap

Another important factor in investment justification is the delta between cost of remediation pre-production vs. post-production. 

When a vulnerability is caught in production, fixing the code is a resource-intensive process that requires time and work from both security and engineering teams. How is the vulnerability possible? How and when did it get there? What development team, if any, is working on the application now? If we send the vulnerability report to the developers working on it, will they know how to fix it? Will attempt #1 to fix the vulnerability work? What about #2?

The below image from CISQ provides a good visual of how it plays out in practice: a trial-and-error feedback loop.

Dollar signs indicate where most effort/cost is concentrated.

At HackerOne, we see a median resolution lifecycle of 34 days for vulnerabilities reported to penetration tests. 

Even when a patch involves an update to just a few lines of code, determining what lines of code can be like looking for a needle in a haystack. Fixing vulnerabilities discovered in production is roughly 30 times more expensive than finding and fixing them during development.

Source: NIST: The Economic Impacts of Inadequate Infrastructure for Software Testing

Fixing a vulnerability in coding/unit testing is more cost-effective because the context is immediately known, and the complexities involved in writing the code change have already been solved (e.g., navigating existing technical debt to “get it to work”). When a developer is tasked with a vulnerability report to fix, it creates an unplanned cycle of repeating this work. All of the context and technical debt navigation needs to be re-learned. In other words, code patches—even the ones with just a few changed lines of code—take a lot longer than they look.

How big of a problem is this? Just ask your engineering team. Developers spend 13.5 hours a week dealing with technical debt, which is the biggest obstacle to making changes to existing code bases and has an estimated economic impact of $1.52T in the US alone.

A majority of development teams already have a quality assurance stage built into their workflow: pull request review and approval. For most development teams, proposed changes remain in this stage for 47-50 hours, during which defects are caught and fixed prior to merge. During this stage, developers catch and fix about 3.4-4.7 defects per 1,000 lines of code with the help of peer review and automated tooling.¹ These existing development practices provide an opportunity for a non-invasive security policy that, if thoughtfully executed, avoids duplication of development effort and minimal impact on velocity. Ideally, none.

Revisiting our example of an SQL injection vulnerability caught in production, let’s assume the root cause was an implementation where a JavaScript template string was used instead of a parameterized query which would have escaped values properly. If the developer writing the code was informed with the right guidance in a pull request review, it would have taken them 30 minutes to address. Caught in post-production testing, perhaps months later, expect it will take 15 hours of triage, troubleshooting, translating application security terminology to software engineering terminology, etc.

Determining cost impact can be more directly measured based on known operational expenses and varies between organizations. For this example, let’s say the cost is $100 per hour.

Post-production remediation: $1,500

Pre-production remediation: $50

Total operational cost savings: $1,450

This brings overall financial impact to $151,325 when added to return on mitigation ($149,875). Or, 3,027 times cheaper. “An ounce of protection is worth a pound of cure” may be an understatement.

Conclusion

Whether caught pre-production or post-production, catching and fixing vulnerabilities before cybercriminals can exploit them prevents enormous losses. Forecasting business value is best achieved by using a return on mitigation (RoM) framework. The additive business value in pre-production code security comes from significantly lower remediation costs.

There’s no one-size-fits-all methodology for metric-based objectives to determine a “shift-left” security program’s success, but a good place to start is the volume of true positive reports received over the 12 months with a reasonable “prevention” rate prediction (i.e., expecting 40% fewer new true positive reports matching target CWE categories).

How HackerOne is reinventing security for developers

While there’s a clear investment justification for security in development, efforts to “shift-left” often backfire, creating frustration for developers, an unhealthy relationship between engineering and security, and overly strict friction inhibitors on velocity. HackerOne has been on a mission to understand why “shift-left” security isn’t working and to build a methodology-based solution that gets it right.

HackerOne PullRequest is a true, developer-first approach to code security. We combine AI with expert human manual code review. The output – remediation guidance embedded directly in the developers’ existing workflow – empowers them to write secure code and proactively address security risks in the tools they already use. With a developer satisfaction rate of over 96%, HackerOne PullRequest is trusted by development teams because it’s actionable, fast, and self-learned.

¹ Source: HackerOne PullRequest Benchmarks sample of 3,000 organizations and 115,000 repositories spanning Small, Mid-Sized, and Large development team size cohorts.

There’s no debate that catching and fixing security flaws in development saves time, money, and stress.

What is HAQL?

Back in 2022, we were faced with a challenge: we wanted to build useful, actionable dashboards for our customers, and we wanted to build them fast. We had the data, we had the context, and we had the designs, but we were missing a way to scale the process of data wrangling for each additional data visualization. We built helper classes, DRY’d, and abstracted away code, but we still found ourselves bogged down writing opaque Arel queries that were prone to error and difficult to debug. On top of that, trying to optimize for performance while navigating a complex database authorization layer led to difficult tradeoffs between load times and security. 

Enter HAQL. Rather than struggle through defining each query in ActiveRecord, Arel, or risky raw SQL blocks, why not simplify the interface and focus on the specific needs of a fast analytics query engine? At its core, HAQL is just that: a simplified query interface for writing performant aggregate queries on tables modeled purposefully for data analysis. 

On the backend, HAQL consists of a Ruby class that constructs Arel nodes from a given input, enabling fine-grained control over the available schema, authorization, database functions, data types, output formats, database connections, row limits, error handling, and more. 

The query inputs themselves are highly structured and strictly typed, which makes it easier to validate malicious payloads and enforce access controls. And most importantly for our original use case, the structured inputs and outputs grant us the ability to rapidly build new dashboards. 

We leveraged this HAQL response contract to write reusable React components on the frontend for all our most common data visualizations; now a chart becomes a configuration, and creating a new dashboard becomes a low-code activity. 

So how does it work? 

The Anatomy of a HAQL Query

A HAQL query has many of the familiar components of a SQL query: a required select statement along with optional where predicates, join statements, order by specifications, and limit directives. Queries are typically executed via GraphQL, but can also be defined explicitly as JSON. Let’s look at an example. 

With this query, we’re retrieving the sum of bounties grouped by asset in the select statement. We join the assets table to the bounties table in the join statement, and specify the join conditions via a series of predicates. Finally, we order the results by the summed bounty amount.

Behind the scenes in our Rails backend, each query component is parsed, validated, and incorporated as a node in an Arel query. At this point, we also apply authorization predicates and other safeguards against improper access. Results are then returned in a key-value format that’s compatible with GraphQL. 

In PostgreSQL, the above query would translate to:

Though a simple interface, HAQL allows for quite complex queries. We’ve found that in combination with reusable frontend components and well-defined patterns for grouping related queries, HAQL has brought down the time to build a new dashboard from weeks to hours in typical use cases. 

Investing in Catalysts

It’s often the case in the world of engineering that small improvements have reverberations greatly exceeding the initial problem in scale. Discovering these force multipliers is more art than science, but with HAQL we found out almost immediately that there were a number of applications, many of which were completely unexpected. 

One of the most exciting opportunities for HAQL is its relationship to Hai, HackerOne’s AI copilot. HAQL’s schema is naturally dense with information and highly structured, making it easy for Hai to learn the language via conventional Retrieval Augmented Generation (RAG) techniques and enabling Hai to fetch, analyze, and render data as an agent in real time. 

Without this analytics query layer, our Hai developers would’ve been required to hand-engineer data access rules and schematic context to coax generated SQL from an LLM, they would’ve needed to write parsers for validation, and they would’ve been forced to implement complex logic for handling diverse response formats. Instead, a relatively simple addition to the LLM’s system prompt unlocks a powerful new functionality: context-aware, chat-based insights across the HackerOne platform.

As an added benefit, simple yet strict authorization rules give us greater confidence in Hai’s ability to safely execute HAQL queries, and support for rich metadata allows us to “steer” LLMs towards more reliable queries that wouldn’t have been possible otherwise. 

Limitations 

In the age-old tradeoff of build vs. buy vs. open source, HAQL is no exception. Are there other tools that could have potentially helped us solve this problem? Of course. Are there downsides to managing a homegrown custom query engine in a Rails app? For sure. Are there unknown risks we haven’t uncovered yet? Definitely. 

The verbose syntax may also feel heavy-handed for experienced SQL users at first, and for more complex operations such as subqueries, CTEs, unions, and the like, HAQL is not the best option (yet). But there’s always the right tool for the right job, and at HackerOne, HAQL is a powerful one to have in the toolbox. 

Looking Forward

In the future, we expect HAQL to have uses that go far beyond powering dashboards. It already enables a handful of REST API endpoints, and in the future, it will likely be queryable directly via the API. The number of datasets available in the HAQL schema has also been growing steadily to cover a greater share of HackerOne’s product suite. Finally, the integration with Hai is sure to attract additional product and engineering investment as we discover creative new ways to surface and interact with data. 

We only anticipate these capabilities to grow in what is turning out to be a very exciting time for cybersecurity and technology as a whole. 

At HackerOne, we’ve made data analytics a top priority for the hacker community and our customers. While this might sound like a cliché in 2024, there are countless technical decisions made behind the scenes to enable these insights, and each fork in the road provides both a risk and an opportunity. One decision, in particular, has shaped almost every analytics product we offer, ranging from our core platform to our APIs and beyond: the HackerOne Analytics Query Language, or HAQL (pronounced "hack-uhl," rhymes with "tackle").

So, What Is Disaster Recovery?

In the dynamic world of tech, things can break – sometimes due to our actions, but it can also be due to external factors like provider outages. That's where Disaster Recovery (DR) comes in. It’s our blueprint for rapidly restoring to normal when the unexpected strikes. Consider it our contingency plan for events outside our control, from power outages to natural disasters. It helps the company get back to normal as quickly as possible. 

The Plan in Action: Ensuring Continuity

What's our primary mission in a crisis as explained above? Get HackerOne up and running again, and do it quickly. We start with our core platform because that's the heart of our operation. Once that's secured, our attention shifts to other vital services like our Gitlab instance and several others. To make sure we're efficient and effective, we follow a tier-based catalog that ranks each service by importance. This approach helps us all to be on the same page about what needs to be up and running first.

While our Disaster Recovery Plan is an internal document, it's accessible to every member of our HackerOnie. Why keep such valuable insights under wraps? This plan is more than a bunch of procedures – it’s our blueprint for maintaining top-notch data security and system functionality, especially when challenges arise.

By ensuring that all our team members can access this plan, we’re not just sharing information; we’re fostering a culture where disaster recovery is a shared responsibility. This approach underlines our dedication to keeping our systems secure, operational, and resilient, regardless of the challenges we might face.

Annual Drills: Beyond Compliance

Sure, frameworks like ISO 27001 and SOC 2 specify that we need to run disaster recovery tests. But honestly, for us, it's way more than just ticking off a box for compliance. We see these regular disaster recovery drills as a key part of our culture, just like we view regular credential rotations. It's all about staying sharp and up-to-date.

Think of it as our pledge to not just follow, but lead in best practices. We're not just looking inward, though; we're aiming to set a standard that inspires our customers, too. By rigorously testing and updating our disaster recovery strategies, we're not just ensuring our own resilience; we're also showcasing a model of preparedness and proactiveness.

In short, these exercises are a chance for us to reinforce our defenses and demonstrate to our customers the value of staying ahead of the game. It’s about building a community that values vigilance and readiness, not just because a rule book says so, but because it’s the smart thing to do.

Targets and Performance: Striving for Excellence

In our pursuit of disaster recovery mastery, HackerOne has set ambitious goals tracked by two key metrics: the Recovery Point Objective (RPO) and the Recovery Time Objective (RTO). A Recovery Point Objective is the maximum time permitted for data to be restored, which may or may not mean data loss. The Recovery Time Objective is the targeted duration between the event of failure and the point where operations resume. Our RPO targets 24 hours. Our data, being some of our customers' most valuable and sensitive data, targets seconds. Internally, we strive for even greater speed - RPO in seconds and RTO in hours, guided by the mantra "As fast as possible." This drive for rapid response has led to significant strides. 

From achieving a 50-minute RPO and 16-hour RTO in 2021, we've accelerated to an RPO of less than a second and an RTO of just over 6 hours in 2022. The 2023 exercise, a venture into more complex scenarios with extended duration, was both a challenge and a triumph, leading to the immediate identification and resolution of 10 improvement areas. Here are two examples of the improvements we made: We enhanced our code deployment strategy to increase flexibility in likely scenarios during disaster recovery, and we also developed internal tools to automate the mundane and error-prone tasks required in these situations. This continuous journey of setting and surpassing benchmarks shows our progress and cements our commitment to delivering unparalleled reliability and excellence in disaster recovery. After implementing these enhancements, we recorded an RPO of less than a minute and an RTO of two hours and 41 minutes, marking significant progress. This is a big win! 

Yet, we must ask ourselves if this is sufficient. While we meet compliance requirements and already have an awesome new time record, is that enough? Should we integrate more realistic scenarios, such as adding new components to our exercises, or aim for faster recovery times?

Continuous Improvement: The Road Ahead

Drawing from our experiences and the lessons learned in previous exercises, we're committed to evolving and enhancing our disaster recovery plans. The focus now is to broaden the scope of our disaster recovery exercises, integrating more critical services as dictated by our tier-based service catalog. This expansion will include key services like GitLab and others, ensuring a comprehensive and robust disaster recovery strategy. By continuously incorporating new elements and refining existing ones, like our search service, we aim to not only meet but exceed disaster recovery standards, keeping pace with the dynamic nature of our services and their importance to our overall operations.

Learning With a Dash of Fun

Our disaster recovery exercises strike a unique balance between serious preparation and fun learning. Each year, we infuse our simulations with creative scenarios, such as blizzards, tidal waves, or alien threats to our data centers. 

Example of our introduction of the Disaster last year: 

“In a shocking turn of events, the AWS us-west-2 datacenter in Oregon fell victim to a targeted invasion by green-skinned extraterrestrial beings. The enigmatic assault left the once bustling hub of digital infrastructure in ruins, with the invaders seemingly focusing their efforts solely on this critical data center. Eyewitnesses reported a surreal scene as the aliens descended upon the facility, causing widespread destruction before vanishing without a trace.”

This approach not only keeps the team engaged but also sharpens our skills in a variety of unforeseen situations. But it's not just about the fun; communication plays a pivotal role in our disaster recovery strategy. 

We believe that effective disaster recovery is a collaborative effort that requires transparent and constant communication throughout the organization. From the start of a disaster recovery exercise to the final presentation of our findings, we ensure everyone is informed and involved. This dual focus on engaging learning experiences and clear communication fosters a culture of preparedness and teamwork, essential for any successful disaster recovery plan.

Ready for the Real Challenges

At HackerOne, we view disaster recovery as more than just a set of protocols; it's our pledge to be fully equipped for real-life challenges. It's a team-wide mission, bringing us together in a shared goal: to not only anticipate but tackle any obstacle skillfully. As the world of cybersecurity constantly evolves, being prepared is crucial. For us, readiness isn't merely a choice; it's an essential part of who we are, ensuring we stay resilient and responsive in the face of adversity.

I invite you to embrace this practice in your teams. How well are you prepared for when disaster strikes? Regularly testing and updating your disaster recovery strategies is not just good practice – it’s essential. Prepare, practice, and stay ahead. 

In cybersecurity, the best defense is a proactive approach. Let's make resilience and preparedness our collective goal.

Let's explore an essential yet often overlooked aspect: Disaster Recovery, or DR for short. It serves as our strategic response to external events beyond our control. I'll walk you through not just what DR means, but also how we put it into action at HackerOne, sharing insights into our team's practices and performance stats.

As a recipient of HackerOne's prestigious 2024 'Win as a Team' award, I'm excited to share my thoughts on what drives collective success. This particular award, 'Win as a Team,' emphasizes empowering and enabling colleagues to excel and embrace challenges, which resonates deeply with my core belief: together, we achieve more, or, as I like to say, 1 + 1 = 3. 

My inspiration for valuing teamwork comes from an early influential read The Seven Habits of Highly Effective People by Stephen Covey. In his book, Covey outlines seven habits crucial for achieving personal and professional success and enhancing overall effectiveness in various aspects of life. The first three focus on self-improvement, and the latter four, particularly from the fourth to the sixth, highlight the power of collaboration and collective achievement. These three emphasize collaboration over competition, the importance of empathy, and the continuous quest for synergy. Let's take a closer look at how we embody these principles in action, starting with Habit 4: Think Win-Win.

Think Win-Win

Habit 4, Think Win-Win, is all about fostering high-trust relationships for better collaboration. At HackerOne, we embody this habit through a win-win mindset that is fundamental to all our interactions. This principle guides us in building strong partnerships both internally and with our clients. At HackerOne, these principles are not mere theories but form the foundation of our daily operations, particularly evident in our own managed Bug Bounty Program (BBP). Our goal is not just to be a leader in the field but to set the gold standard for bug bounty programs. We strive to leverage our platform for security and as a tool to uncover new possibilities for our customers.

Our strategy is similar to white-box testing in software development, where transparency about the system's inner workings is key. We keep our processes and challenges completely transparent, ensuring that every detail is visible to the whole team. In our Slack channel, discussions are held openly, and we strive to disclose as much information as possible. Additionally, we actively listen to the community and take their feedback seriously whenever we make a mistake. This transparency lets us see every detail, enhancing our understanding and problem-solving abilities. This approach, aligning with the win-win mindset, fosters mutual improvements and successes for both us and our clients.

Seek First to Understand, Then to Be Understood

Habit 5, Seek First to Understand, Then to Be Understood, focuses on developing a deep understanding of others' needs and perspectives to influence them more effectively. In our BBP, a diverse group of stakeholders, including bug bounty hunters, engineers, and security analysts, collaborate. This platform serves as a prime example of dogfooding - we use our own system to detect and rectify vulnerabilities. By doing so, we not only improve our offerings but also deepen our understanding of our customer's needs and challenges, embodying the principle of empathetic understanding.

From the Customer Success Manager, who focuses on the program's success, to the Security Analyst, who is triaging the incoming report, to the engineer who brings the bug fix to production. By bringing together varied skills and viewpoints, we craft solutions that would be unattainable individually. 

This process of constantly refining our approach also embraces the 'shift left' movement in security. 'Shifting left' refers to integrating security measures earlier in the development process, rather than as an afterthought. By analyzing the bugs and vulnerabilities reported in our BBP, we're resolving current issues and gaining insights into how similar issues can be prevented in the future.

We aim to learn from each bug and use that knowledge to enhance our security protocols from the outset. This proactive approach helps build more secure systems from the ground up, reducing the likelihood of vulnerabilities in the later stages of development. Moreover, we're committed to sharing what we have learned with our customers. By providing them with insights and best practices gleaned from our BBP, we help them in their own 'shift left' journey. This includes guidance on incorporating security considerations early in their development cycles and training their teams to identify and mitigate potential risks from the start.

Synergize

Habit 6, Synergize, emphasizes developing innovative solutions by leveraging differences and satisfying all stakeholders. This concept perfectly encapsulates the power of collaboration at HackerOne. By exploring the 'shift left' approach and learning from our bugs, we're not only improving our security posture but also empowering our customers to learn from their mistakes and prevent future occurrences. This continuous learning and improvement cycle is essential in our mission to create a safer digital ecosystem for everyone.

We must remember that our work's impact goes far beyond professional limits. When our hackers find security weaknesses, it personally highlights the wider consequences of what we do – such as protecting people close to me, like my parents and friends, from digital threats. This connection amplifies the significance of our work and the powerful synergy we create. For me, it’s more than winning as a team at HackerOne; it’s about forging a safer digital world for everyone.

Together, we've cultivated an environment where innovation is born from the diverse ideas and strengths we each bring to the table. It’s in this synergy where we find our greatest successes—where indeed, 1 + 1 equals 3. As we look to the future, let’s carry forward this momentum, embracing each challenge as an opportunity to learn, grow, and achieve together.

Here’s to continuing our journey with hearts and minds united, always striving to embody the 'Win as a Team' ethos. Let’s keep leveraging our collective expertise, driving towards a safer tomorrow. Together, we are unstoppable. Here's to winning as a team—today, tomorrow, and beyond!

HackerOne holds an annual program recognizing five employees whose achievements embody the company's values. 

Because the fact is, it’s easy to have your work go unnoticed. Sure, as Engineers, we see our faces move around on the sprint board, but on a daily basis, we do so much more than that (we help others, lead small but important projects, give useful feedback to proposals, help customers get unstuck) and if we don’t share what we do, it’s easy that our work becomes unnoticed, or even forgotten.

The Brag Document

Last year I couldn’t shake the feeling that I didn’t move forward. I did my daily tasks, but I had a hard time seeing the bigger picture of my work, and the impact that I made. When my manager would ask me what I was working on, I sometimes didn’t know how to answer.

I then read a blog post by Julia Evans about Brag Documents. Soon after reading, I created a Brag Document. A Brag Document is a list of your accomplishments, achievements, and your future goals. It’s used to track your work, the impact you’ve made, the things you’re proud of, the goals you have, and what you’re doing to achieve them.

Help Your Manager Help You

Your manager’s job is to help you and the rest of your team to get better results. So, it’s logical that they are invested in your career. When you do better, they do better. But, even if you have the best manager in the world, they won’t remember everything you did. And that’s okay, because it’s not their responsibility. It’s yours.

You own your career, which means, it’s your responsibility to keep track of it. A Brag Document is a good tool for this. It can also be of help during 1:1’s with your manager and for the annual 360 reviews.

Eventually, when seeking promotion, your manager needs to bring you forward to other people and make a case for why you should be promoted. "They are doing a great job" might not be good enough of a reason for a promotion. The Brag Document could help your manager make a stronger case.

Bragging to Reduce Imposter Syndrome

But, ‘getting promoted’ isn’t the goal of the brag document. The idea is to help you reflect on your work, to recognize patterns, to see what’s important to you, what you’re learning, and what your impact is. It can even help with imposter syndrome. When you hear the voice in the back of your mind saying: "You’re not good at any of this stuff. One day, they will finally see you for the imposter that you are," you can open your Brag Document and think: "That’s actually not true. Look, I did add value."

How to Create a Brag Document

The general idea of a Brag Document is that it contains the work you’re proud of. You don’t have to try to make your work sound better than it is. Just make it sound exactly as good as it is. For example: "I was the primary contributor of feature X, generating $500K annually."

To help you get started, I created a Brag Document template. Feel free to use it and make a copy for yourself!

I believe that, if you focus on improving your skills, impact, and value to your organization, the recognition, promotions, and pay raises will be a byproduct. I also believe that, in practice, it’s more complicated than that.

The topics I want to keep under control are the usual suspects: sleep, diet, exercise, and social connections. I understand these will vary greatly depending on your situation at home. Whether you have a family or not. The feng shui in your bedroom. What your dog tends to do at 5:00 a.m. But I hope some tricks can resonate.

Sleep 

First up, sleep. We all know it’s essential, but in the real world, a full night’s sleep can often be a luxury rather than a routine. With blurred boundaries between work and personal life, the schedules can now be bent to your liking. But no amount of caffeine will cancel the effects of sleep deprivation. The temptation to squeeze in a bit more time for your hobbies at the expense of sleep is hard to resist. Sometimes, I’m even tempted to work in the evening because I know there are no distractions, and I can simply focus better. This should be an exception and not the rule.

Diet 

Now, about the diet. Have you tried getting spaghetti for lunch? Sure, it’s great, but it will put you to sleep before the coffee can even kick in. The convenience of grabbing a quick bite can easily slip into a habit of mindless snacking. The lethargy induced by poor dietary choices becomes the background music to your Zoom meetings. I fight this with a combo: first off, plan your meals in advance and do not give in to pasta every day. A balanced diet can do wonders for you, talk to a dietician to know what makes sense in your situation. But even more importantly, I try to squeeze in a 10-minute nap after lunch whenever the schedule allows. This is hands down my best hack for productivity.

Exercise 

Since it’s January, we all must have mentioned exercise in our resolutions for the year. A digital first company comes with long Zoom meetings where you’re supposed to be sitting and paying attention. And your body rebels, because it’s built for movement. Many members of my team make it a habit to squeeze in time for exercising during the day, I prefer to do it in the evening. The key is, once again, consistency: find what you enjoy doing and keep showing up, rain or shine.

Social 

As for the social front, remote work is often considered to be introducing a new layer of isolation. In the eyes of some, the water cooler chats, the impromptu collaborations, and the camaraderie built during shared lunches are replaced by the solitude of your home office. I do not think this is true. The remote work reality simply readjusts the focus of your day on yourself, and empowers you to build your routines in a way you prefer. You can meet a friend for a quick breakfast at the bar, or go for a run during the lunch break. Take some time during the day for errands, or shuffle your availability around your team meetings and rituals. I found a couple of good ideas from this list of resources.

In this exploration, it’s clear that your lifestyle isn’t just an afterthought; it’s the main actor influencing your work life. Sleep, diet, exercise, and social connections – each element plays a role in the intricate dance of your work efficiency. And now, go get a quick nap.

One of the reasons I was excited to start working for HackerOne was its digital-first policy. Not entirely separated from your colleagues, but not that close either. In my case, I live a safe 2.5 hours away from the closest office. I had struggled to work remotely during the lockdown, and I thought that working for a digital-first company would help me be more efficient with remote work and more organized in my daily routine. To my surprise, it worked! Well, sort of. I’m definitely happy to be working from home most of the time, and I want to keep improving my routine to work better and, above all, feel better.

Good listening is an act of empathy and curiosity. Empathy is understanding how others feel, what their world looks like, and being compassionate towards them. This means that the main goal of a conversation, any conversation, is to seek to understand. To understand the other person, their viewpoint, their motivations.

In another life, I was a journalist. One of the most valuable lessons I’ve learned as a journalist is that anyone can be interesting as long as you ask the right questions, don’t fear silence, and listen well.

Listening is a skill, and as with any skill, you can develop it. While researching the concept of ‘good listening’, I put together a small framework to break down the process of listening emphatically.

Check Your Intentions Before Going Into a Meeting

At times we can enter a conversation as if we’re entering a boxing ring. Ready to fight and to convince others of our great ideas. But, the idea of having good conversations is to explore the other person’s point of view, not to force them to agree with ours. Listening well goes hand in hand with being open and vulnerable. We need to allow others to change our minds with their perspectives, knowledge, and opinions.

Be Present

Research has found that when people speak to others who are not paying attention, the speakers share less information and may not express themselves as well. To listen well, you need to pay full attention to what the other is saying.

At a digital-first company, we have many virtual meetings, which can come with different distractions than face-to-face meetings. Make it a habit to put your Slack messages off when you’re entering a Zoom call. Remove your phone from your desk, and close the windows on your desktop you still have open. Even if you think you can multitask, science shows that you can’t.

Act as if You’re a Journalist

Stephen Covey, the author of The 7 Habits of Highly Effective People, said: “Most people do not listen with the intent to understand; they listen with the intent to reply.”Listening goes beyond hearing what others are saying. It also involves asking questions and paying attention to what is said, and what is being said.

But it’s essential to ask the right questions. When you ask judgemental questions, it can easily turn the conversation into a self-promoting elevator pitch. A rule of thumb you can follow is that curious questions don’t end with the words: ’ Don’t you think?’.

When the main goal is understanding their perspective, people will trust you more. With trust comes better relationships and collaborations. And with better collaborations comes, ultimately, a better product.

Becoming a great listener isn’t easy, but with practice, you will develop understanding. Because when it comes down to it, when you’re not listening well, you’re missing out on so much.

Being a good listener will not only make you a better engineer, it will make you a happier person as well. It will help you build meaningful and productive relationships.

At HackerOne, we believe that the better we are aligned, the better we know where to go, and the more confident, empowered, and engaged HackerOnies will be.

So, how do you run prime communication on a project that spans multiple teams? The 3 Ps: Purpose, People, Process.

Purpose

Have a clear sense of where you are going, and communicate it well. The more time you spend on explaining and defining the final outcome, the less you need to align on specific tasks. You empower others to make decisions. The more people are on the same mission, the less room for problems. Try to be concise and to the point with the message, and be explicit about what you expect from other people. If necessary, you may want to add a Call To Action or try to engage other people to contribute to the discussion by explicitly asking them what they think.

More than that, repeat yourself all the time. Say it in the same words, find something catchy, make it like a chorus to your favorite song.

People

We are all unique as humans, we all carry different cultural backgrounds. The feeling that you create in your project contributes to an open and honest culture. We are all products and producers of culture, so it is up to you to create that environment.

It is always recommended to over-communicate something rather than under-communicate. This will allow us to increase visibility into the things we are working on that may spark some interest for other teams, thereby leading to a natural collaboration. This will also help us identify blockers earlier, address dependencies and work around removing them gradually as we communicate it to other teams. Not only will it be useful for sharing information but also for gaining a common understanding of the topic that is being discussed, addressing pros and cons, and eventually agreeing on the next steps. It is very important that the goal should be creating an alignment between teams so that it would be easier to divide responsibilities, sequence the work, create feedback loops and, as a bonus, identify improvement opportunities.

Process

I also cringe at the word ‘process.' But, processes are your friend! They are there so you don’t need to waste time thinking about what to do all the time.

At HackerOne, we are Digital First. This means that we are working remotely, and that most of our communication goes via Zoom or Slack.

Depending on the type of communication we need to make, the medium might also change. For instance, if it’s something that concerns only the team, e.g., stand-up notes, team planning, or code reviews, typically, we would put this in the internal team Slack channel. If there is an incident that may affect more people in the entire company, it would be useful to publish this in the public Slack channel. So that we can more easily reach out to a broader audience and vice versa, other people could easily chime in in the thread. Or, you may also need a group of people to address some discussion points and come out with a decision, in which case you’d probably need to set up a meeting.

The best way to know when, who, and how to communicate with the interested parties is to agree in advance when starting the project. It is impossible to predict the future to know things in advance, but we can try to put ourselves in other people’s shoes to be able to think about what they’d like to know. From there, it’s easier to set expectations from all sides. Expectations prevent miscommunications, which help prevent damaging surprises and bad relationships.

Conclusion

In summary, effective communication goes beyond a singular act and should be viewed as an ongoing environment that you create. It is crucial for establishing strong connections with colleagues and maximizing their collective expertise. While challenges are bound to arise within any organization, a thriving company culture is not defined by the absence of problems but by the ability to address and resolve them swiftly and effectively. Each day presents an opportunity to cultivate a culture of open communication and knowledge sharing, which ultimately leads to enhanced outcomes for all stakeholders involved.

In life, you can get pretty far on your own, but you will always get further together. In that, good communication is the foundation of teamwork. It is good communication that brings people together under one purpose. It is communication that helps establish good relationships and connections between peers/teams/stakeholders. It is communication that helps you foster empathy, pool all your knowledge together, and act as one in the most efficient way.

Before we dive into the tips and strategies for different types of 1:1s (e.g. 1:1s with your manager, your peers, or your product manager), let’s cover the three golden rules that apply to all of them:

• Plan and set the agenda. This helps make the most of your time by focusing on the most important topics. The agenda provides a compass for the conversation, so the meeting can go back on track if the discussion wanders off course.
• Respect each other’s time. Show up on time and end the meeting when you’re supposed to.
• Avoid canceling your 1:1s. Regularly rescheduling or canceling sends the message that the meeting isn’t important and that the other person isn’t a priority.

Manager 1:1s 

When it comes to 1:1s with your manager, the main goal is you! Use this time to discuss how you are doing, your career goals, and where you want to go in your role. Keep in mind that it’s your career, so be prepared to drive the conversation. Ensure that the meetings take place consistently and have an agenda and a goal.

Here are some topics to discuss during your next 1:1:

• What’s been going well — “I really enjoy working on this new project”, “I feel like I’m adding more value to the company”
• What’s not going well — “I’m doing too much CSS and want to focus more on the backend”, “I feel overloaded, and I struggle with delegating my tasks”
• The team — “Are there any upcoming projects we need to prepare for?”, “If you could wave a magic wand, what one thing would you change about the team right now?”
• Career planning — “I want to level up, how do I get there?” or “These are my 3 main goals for the upcoming 6 months, what do you think about them?”
• Opportunities — “I’d love to work on a customer-facing project” or “Is there anyone I can shadow to learn more about frontend development?”
• Feedback — “How did I handle that conflict with X?” or “How can I do better?” or “I think it would benefit the team if we could meet more in person”
• Brainstorming — “Let’s figure out how to tackle this problem together”
• Resources — “I think taking this course would help me”, “I think I could benefit from going to this conference because…” or “Can you recommend a mentor who can help me with X?”

Remember, your manager wants you to do well and succeed. If you do well, your team does well. And if your team is successful, so is your manager. In other words, you’re both on the same team. Try to see your 1:1s as coaching sessions, take responsibility, and get the most out of them.

General 1:1s

Your 1:1s are a great chance to learn from your colleagues like your squad mates, team lead, designer, engineers from other teams, or product managers. Plus, it’s a good way to get to know them better.

Here are some examples of things you can talk about during your 1:1s:

• What’s on their mind — “How are you feeling?“, “What are you working on right now?“, “What challenges are you facing at the moment?”
• What’s on your mind — “I’m excited to tackle this new project”, “I’m struggling to manage my workload”, “I found the last team retrospective helpful because of X”
• Project Progress — “Are there any roadblocks that could prevent us from meeting our deadline?“, “I’m concerned about this issue, what do you think?“, “How can we get more people excited about this project?”
• Technical Challenges — “I want to improve the performance of this page, where should I start?“, “When I’m working on OSHA, here’s how I debug a route”
• Communication and Collaboration — “How can we improve our team’s communication?“, “Do you have any tips for working effectively with people from other departments?”

Though discussing the last episode of Succession is a great conversation to have, try to find balance and prioritize topics during your 1:1s. These meetings are valuable and can improve your work and relationships, so make the most of them! With a little effort, you can turn your 1:1s into your most productive and enjoyable meetings of the week.

We’ve all been stuck in ineffective 1:1s. There was no clear agenda, and the only thing you spoke about was the last episode of Succession, the other person arrived late, or it was canceled at the last minute. It’s a shame because our calendars are full of one-on-ones, which means we’re essentially wasting these moments. And when I say “wasting” I mean not just wasting time, but potential value as well.

The Pitfalls of Saying “Yes”

Have you ever released a Minimum Viable Product (MVP) only to abandon it straight afterwards? Did it break anything? Perhaps it was a feature born from a HackWeek that ended up causing more trouble than anticipated. These scenarios highlight the importance of discerning whether projects are truly done or require further iterations. Did they succeed? Why or why not? What lessons can we learn for next time? Without addressing these questions, we risk facing escalations down the line.

Meetings, while necessary, can also consume valuable time that we could spend on productive tasks. If you don’t have time to prepare for them if there are no action items, or if the follow-up gets lost somewhere. As valuable as discussions can be, they don’t mean anything before being translated into work.

In a similar manner, if everyone in your team is working on a different project, it seems that you are doing more at the same time, but you miss out on synergies, lose time on context switching, and delay the delivery date. Work together; In scrum mathematics, 2+2=10.

But those are the immediate, apparent issues. What about the cost of opportunity?

Did these features and meetings result in anything down the line? When you drop or postpone a project there is always a good reason. It took longer than expected, a distraction showed up out of nowhere, priorities simply changed. And every time you do it, it feels bad because you have effectively wasted time. Additionally, picking up the project again after six months might require you to start from scratch.

Tip #1 — The Power of Under-Commitment

Under-committing doesn’t mean working less. It means not making promises that you are not able to keep. By allocating buffers in our day-to-day schedules and roadmaps, we prepare for unexpected challenges.

Having a buffer also helps keep a low level of stress: we are not robots, we won’t perform 100% every day. It also creates space for helping others where needed. Something small for you might mean the world for someone else if you are able to help them timely. Try to position yourself to be happy to do it rather than it feeling like a sacrifice. Reducing feedback loops across projects is a cornerstone of productivity.

Tip #2 — Predicting the Future

Do you think your buffer is too big? Do you spend too much time-solving emergencies instead of working on your important goals?

To reduce your under-commitment buffer you have to spend more time thinking about the upcoming problems:

• If you just launched a feature, expect escalations, and be ready to address them on the spot.
• What is the cost of ownership of the features you own? Expect having to maintain them over time, don’t postpone maintenance forever.
• How do you feel after sprinting for 100 meters? Can you do 100 more at the same pace? Scrum sprints are no different; don’t push on every sprint, and plan for changes of pace.
• Teams operate, on average, at 80% capacity when measuring over a Quarter.

Tip #3 — Find a New Owner or Kill it

At times, you notice that you have overcommitted and you need to drop something. As painful as it is, it might be better to just terminate it. Alternatively, while it might not align with your immediate priorities, it could be valuable for others within the organization. You might be able to find a new owner.

However, it’s crucial to consider the repercussions of dropping it on someone else. If this causes them to abandon their own tasks or priorities, it disrupts their workflow and wastes their time. Therefore, it’s essential to communicate effectively and possibly coordinate with other teams in advance to avoid such situations.

Transparency in these decisions is key to fostering trust and streamlining future collaboration. While it may be scary to subject your decisions to scrutiny, it’s a necessary step towards creating a culture of accountability. Learning to confidently say “no” when needed ultimately leads to more efficient and impactful outcomes.

Conclusion

In conclusion, mastering personal time management and prioritization is essential. In order to maximize our impact, we need to embrace under-commitment, predict future needs, and steer the wheel when necessary.

In our fast-paced engineering environment, the mantra “less is more” echoes everywhere. It’s a catchphrase, and for a good reason: focus is key. Over the past six months, our company has embraced this strategy wholeheartedly. However, we’re bombarded with urgent priorities and enticing good ideas from all sides. So it becomes tempting to say yes to everything. Yet, every “Yes” inevitably means saying “No” to something else. The challenge lies in making conscious decisions and staying laser-focused on our top priorities.