This Pride month, at workplaces around the world, you would be forgiven for thinking nothing has changed — working at home, we find ourselves at the same desks looking out of the same windows. Pride celebrations still look and feel different from the ‘before times’, as the physical manifestations of our LGBTQ+ community are slowly rebuilt in digital fabric. A year on from the creation of Plus, Tessian’s LGBTQ+ employee resource group, we look back to our original mission and founding principles, what we’ve learned in these strange times, and what we can look forward to in 2021. How Plus was formed  In all of 2020’s uncertainty, there was one certainty in the transition to remote-working — digital would have to replace physical… at least for the time being.  Zoom calls replaced meeting rooms, Slack replaced coffee chats, and Tessian began to use a tool called Peakon to measure employee engagement. It was only natural, then, that Plus was started by a single Peakon message, asking: “Is Tessian doing anything for LGBTQ Pride Month?”

The answer turned out to be No — but that the opportunity presented itself with the full support of the company and executive team. Without any existing plans, a few LGBTQ+ Tessians self-organized and promoted our newly-formed group — Plus. For us, Pride has always been about celebration and amplification of LGBTQ+ voices — both inside and outside of Tessian, and to create a “safe space” for all Tessian LGBTQ+ employees to network, socialize, and share experiences behind closed doors.  But our largest reservation when starting Plus was always about critical mass.  How Plus grew at Tessian Without any visibility on LGBTQ+ employees at Tessian, we didn’t know if the group would have enough members to be successful, or if by creating a community exclusive to LGBTQ+ voices alone, we would be excluding allies of the community in a way that restricted our ability to act on our mission. Forming a small committee, we promoted the arrival of Plus during company all-hands, new employee onboardings, and relied on existing and larger employee resource groups to gather members. We were quickly impressed at the uptake, with more than 10% of the company joining Plus within the first month of launch — a significant minority and higher than the expected average. Seniority and function were both well-represented at Plus, pulling from all parts of Tessian and for the first time, providing an organized and welcoming committee of LGBTQ+ voices. Plus was formed around a core mission to:  Ensure an inclusive and respectful environment for all employees Raise awareness of, and represent the views and issues of, LGBTQ+ employees Provide a support network for LGBTQ+ employees Create opportunities to socialize with other LGBTQ+ employees Offer confidential support when needed Provide guidance to Tessian as an employer on policy and how to enhance its diversity strategy In practice, the digital certainties of our last year in remote work has led Plus to resculpt any and all ideas around community-building. Online socials over Zoom, knowledge sharing via Slack — and more recently — socially distanced gatherings at local parks, have all worked well. As Tessian began it’s formal journey on Diversity & Inclusion with the development of an internal D&I Report — again developed remotely — Plus had a seat at the table to shape the discussion around LGBTQ+ representation at the company. And sharing our message outside of Tessian, Plus was even fortunate enough to be interviewed for Infosecurity Magazine’s cover pride story alongside ERGs from Zivver and Rapid7.

That is to say, that even during a year when LGBTQ+ communities around the world have struggled to run gatherings, fundraising, or support networks, — when the importance of Pride as an LGBTQ+ institution has been validated — our approach to working directly with LGBTQ+ Tessians on the community-building activities that matter most to us has proven successful. What’s next for Plus? One of Tessian’s company values continues to be Human First. And with Plus, we’re proud to have created a private, Human First initiative for Tessians to celebrate their sexual orientation and gender identity. Plus germinated alongside Tessian’s transition to choice-first remote working, but won’t stop growing as we move forward to a hybrid workplace. Continuing to grow with new members, we’re excited to meet up in-person, campaign for positive change outside of Tessian, and work with external speakers to open up LGBTQ+ stories to the whole company. Do you lead an LGBTQ+ Employee Resource Group at your company? Get in touch and we would love to hear from you on how you’ve elevated LGBTQ+ voices during the past year, and what successes you’ve seen building healthy LGBTQ+ communities.

I’d like to describe Tessian’s journey with React hooks so far, covering some technical aspects as we go. About two years ago, some of the Frontend guild at Tessian were getting very excited about a new React feature that was being made available in an upcoming version: React Hooks. React Hooks are a very powerful way to encapsulate state within a React app. In the words of the original blog post, they make it possible to share stateful logic between multiple components. Much like React components, they can be composed to create more powerful hooks that combine multiple different stateful aspects of an application together in one place. So why were we so excited about the possibilities that these hooks could bring? The answer could be found in the way we were writing features before hooks came along. Every time we wrote a feature, we would have to write extra “boilerplate” code using what was, at some point, considered by the React community to be the de facto method for managing state within a React app ─ Redux. As well as Redux, we depended on Redux Sagas, a popular library for implementing asynchronous functionality within the confines of Redux. Combined, these two(!) libraries gave us the foundation upon which to do…very simple things, mostly API requests, handling responses, tracking loading and error states for each API that our app interacted with. The overhead of working in this way showed each feature required a new set of sagas, reducers, actions and of course the UI itself, not to mention the tests for each of these. This would often come up as a talking point when deciding how long a certain task would take during a sprint planning session. Of course there were some benefits in being able to isolate each aspect of every feature. Redux and Redux Sagas are both well-known for being easy to test, making testing of state changes and asynchronous API interactions very straight-forward and very ─if not entirely─ predictable. But there are other ways to keep testing important parts of code, even when hooks get involved (more on that another time). Also, I think it’s important to note that there are ways of using Redux Sagas without maintaining a lot of boilerplate, e.g. by using a generic saga, reducer and actions to handle all API requests. This would still require certain components to be connected to the Redux store, which is not impossible but might encourage prop-drilling. In the end, everyone agreed that the pattern we were using didn’t suit our needs, so we decided to introduce hooks to the app, specifically for new feature development. We also agreed that changing everything all at once in a field where paradigms fall into and out of fashion rather quickly was a bad idea. So we settled on a compromise where we would gradually introduce small pieces of functionality to test the waters. I’d like to introduce some examples of hooks that we use at Tessian to illustrate our journey with them. Tessian’s first hook: usePortal Our first hook was usePortal. The idea behind the hook was to take any component and insert it into a React Portal. This is particularly useful where the UI is shown “above” everything else on the page, such as dialog boxes and modals. The documentation for React Portals recommends using a React Class Component, using the lifecycle methods to instantiate and tear-down the portal as the component mounts/unmounts. Knowing we could achieve the same thing with hooks, we wrote a hook that would handle this functionality and encapsulate it, ready to be reused by our myriad of modals, dialog boxes and popouts across the Tessian portal. The gist of the hook is something like this:

Note that the hook returns a function that can be treated as a React component. This pattern is reminiscent of React HOCs, which are typically used to share concerns across multiple components. Hooks enable something similar but instead of creating a new class of component, usePortal can be used by any (function) component. This added flexibility gives hooks an advantage over HOCs in these sorts of situations. Anyway, the hook itself is very simple in nature, but what it enables is awesome! Here’s an example of how usePortal can be used to give a modal component its own portal:

Just look at how clean that is! One line of code for an infinite amount of behind-the-scenes complexity including side-effects and asynchronous behaviors! It would be an understatement to say that at this point, the entire team was hooked on hooks!   Tessian’s hooks, two months later Two months later we wrote hooks for interacting with our APIs. We were already using Axios as our HTTP request library and we had a good idea of our requirements for pretty much any API interaction. We wanted: To be able to specify anything accepted by the Axios library To be able to access the latest data returned from the API To have an indication of whether an error had occurred and whether a request was ongoing Our real useFetch hook has since become a bit more complicated but to begin with, it looked something like this:

To compare this to the amount of code we would have to write for Redux sagas, reducers and actions, there’s no comparison. This hook clearly encapsulated a key functionality that we have since gone on to use dozens of times in dozens of new features. From here on out, hooks were here to stay in the Tessian portal, and we decided to phase out Redux for use in features. Today there are 72 places where we’ve used this hook or its derivatives ─ that’s 72 times we haven’t had to write any sagas, reducers or actions to manage API requests! Tessian’s hooks in 2021 I’d like to conclude with one of our more recent additions to our growing family of hooks. Created by our resident “hook hacker”, João, this hook encapsulates a very common UX paradigm seen in basically every app. It’s called useSave. The experience is as follows: The user is presented with a form or a set of controls that can be used to alter the state of some object or document in the system. When a change is made, the object is considered “edited” and must be “saved” by the user in order for the changes to persist and take effect. Changes can also be “discarded” such that the form returns to the initial state. The user should be prompted when navigating away from the page or closing the page to prevent them from losing any unsaved changes. When the changes are in the process of being saved, the controls should be disabled and there should be some indication to let the user know that: (a) the changes are being saved, (b) the changes have been saved successfully, or that (c) there was an error with their submission. Each of these aspects require the use of a few different native hooks: A hook to track the object data with the user’s changes (useState) A hook to save the object data on the server and expose the current object data (useFetch) A hook to update the tracked object data when a save is successful (useEffect) A hook to prevent the window from closing/navigating if changes haven’t been saved yet (useEffect) Here’s a simplified version:

As you can see, the code is fairly concise and more importantly it makes no mention of any UI component. This separation means we can use this hook in any part of our app using any of our existing UI components (whether old or new). An exercise for the reader: see if you can change the hook above so that it exposes a textual label to indicate the current state of the saved object. For example if isLoading is true, maybe the label could indicate “Saving changes…” or if hasChanges is true, the text could read “Click ‘Save’ to save changes”. Tessian is hiring! Thanks for following me on this wild hook-based journey, I hope you found it enlightening or inspiring in some way. If you’re interested in working with other engineers that are super motivated to write code that can empower others to implement awesome features, you’re in luck! Tessian is hiring for a range of different roles, so connect with me on LinkedIn, and I can refer you!

In February this year, I set out to raise Tessian’s Series C. As many other great founders have written, timing is everything when it comes to fundraising, so we picked our moment carefully. We’d achieved significant growth since our Series B in 2019, we’d just run our first customer NPS (the scores were very good), and we were about to launch our most significant product release to date: Human Layer Risk Hub.  This isn’t our first rodeo. It’s actually my 7th fundraise for Tessian. But there was a key difference this time. The world is working remotely. This meant our entire fundraising process happened over Zoom. So while I was expecting to use a similar version of the process I’d used over the past 7 years, it instead turned out to be something completely different.  Here are four of my key lessons learned from raising our Series C over Zoom.  (1) Get ready to move fast The biggest change I experienced in raising a remote round is how much faster things move. The convenience of Zoom and the fact that nobody is traveling right now, means that it’s easier to schedule large groups of people to join a first meeting with a company. Almost all of the first meetings we had with funds involved multiple partners (some involved the majority of the fund), and this means you’ve already shortcutted what may have taken weeks in a normal process. We experienced things moving quickly from first meeting to data room (normally the same day), and then super fast again from data room to agreeing the next meetings and customer calls. Speed is a blessing for most processes (selling, hiring), but when it comes to fundraising it’s important that founders are ready to move at pace. This means having your data room prepped in advance, NDAs signed if you’re using them, and customers on standby to act as references. Because if you don’t, you risk being left behind and losing the attention span of the funds who are inundated with opportunities right now.  (2) Get your audience to lean in  You need to bring the energy on every pitch. People are back to back on Zoom all day. And to add to this, they’re sitting in front of a computer being constantly pinged with alerts and have full access to their inbox and messaging apps. The temptation to drift away from what you’re pitching and into the chaos of work has never been higher. You need to make people lean into your presentation. You need to inspire them over Zoom. It means that the standards for your deck, narrative, product demo and delivery all have to be a level up from pitching in person. This is a heavy lift without human connection involved. Be ready for it. (3) Showcase your company by bringing in your wider team In normal times, you’d more than likely have funds come and visit your offices. An office environment is such a great way to observe the people, culture, scale and mission of a company. Now that we’re all remote, you can’t showcase your company that way. But you need to. It’s still so important to show the bigger picture of what you’re creating. While remotely raising our Series C we tried hard to have as many people amplify our story as possible. We connected investors with customers, had our executives host sessions with investors and also invited funds we were speaking to join the virtual events and webinars we were running. All of this helps investors feel the scale and impact of your company and its mission in a remote world. (4) Build rapport into your process  Through our Seed, Series A and Series B fundraises, we got to build great relationships with the people that we ended up partnering with (and also those we didn’t get to partner with). By the time these rounds were closed, I’d shared multiple coffees, lunches and dinners with investors. I knew their hobbies, where they went to school, who their family were. What became immediately apparent when we started raising the remote Series C is that things are almost efficient to a fault. If you let it, the fundraising process can focus fully on the business and erase any chance to build rapport. To combat this, Ed Bishop (my co-founder and Tessian’s CTO) and I would do little things around our pitch and meeting with investors. In our core deck, we had pictures of our first “office” (i.e. the tiny kitchen table in our even tinier apartment where we started the company) and shared personal anecdotes about our journey to-date in building the company. This did two things. It showed investors who we were as founders but also as people, so they knew when they partnered with us what it would look like. It also gave us the opportunity to know them as people based on their reaction (i.e. did they laugh? Say nothing? Admire the hustle?)  So there you have it. While in a non-remote setting people used to advise budgeting 180 days for a fundraise, Tessian’s Series C took just 63 days from first pitch to cash in the bank. The difference was that the intensity was much more concentrated over a short period of time and you have to find new ways to build rapport and your relationship with your potential investors.  As the US is starting to reopen, people are naturally trying to predict whether this is the beginning of the end for remote work, and questioning if we’ll all be back to offices soon. Whatever happens, I think remote work has changed the way companies and founders will raise venture capital for good. Zoom means that the overall process moves so much faster and funds are no longer restricted by the geography of their portfolio companies.  With all of this change though, one thing remains. The human connection is still so important. We ran our entire process virtually and met funds located all throughout the world. However, it just so happens that the lead investor we chose to partner with was located 5 minutes down the road, and we had the opportunity to meet them and their network multiple times in person throughout the process. Even though remote raising may be here to stay, the people you raise the money from is still the most important thing. Make sure you take the time to get to know who they are and build the relationship ahead of time.  If you’re interested in reading more about our recent fundraise and what it means for Tessian, everything you need to know is here.  Have you raised a remote round recently? What’s your experience been? I’d love to hear from you. 

I’m lucky. I get to speak to and learn from hundreds of CISOs each year across all different sizes and types of orgs. Each conversation gives a unique insight into how companies approach security and, crucially, what works well and what doesn’t.    Over the last few years, there is a very specific type of security leader who I’ve seen succeeding time and time again. A type of CISO that has particular success in winning boards over, getting employees to engage, and ultimately reducing exposure for their org.   So what makes these new-school CISOs so successful? 1. Security = sales Gone are the days where security leaders are technical folks that shun any form of pitching as “not part of their job”. The best CISOs have recognized the importance of security in winning new customers and embraced it. Whether it’s leveraging their progressive security tech stack to impress, wowing a prospective customers’ security team over a call, or being a crucial part of the pitch team, security can have a material impact on the most important business driver (new revenue). It doesn’t start when the pitch has been secured; I’m regularly hit up by CISOs at customers asking for intros to prospective new customers. CISOs winning and finding deals – no wonder they don’t struggle with exec attention.      2. Customer success = CISO’s success I’m biased, but nothing is more important than making the customer successful. It’s easy for security teams to think they have limited ability to impact their customers’ success, but some CISOs are going above and beyond to make their customers successful. From proactively building relationships with customers’ security teams to notifying customers of potential vulnerabilities, nothing beats having a direct relationship with a customer. Better still, if you can help them be more secure, you’re creating value for the customer and protecting your organization; after all, you’re only as secure as the customers (and suppliers) you work with.      3. Employees are everything Security doesn’t work in a vacuum. You won’t win as a CISO if you push down security policies and assume they’ll be adopted. This belief is at the core of the new-school of CISO – they know that they’ll only drive positive change in the organization if they bring people along for the journey. That means great storytelling, making content relevant and doing everything they possibly can to help, not hinder, their employees to work securely. Some great examples I’ve seen here are hijacking the beginning of other meetings to educate on security, giving line managers the insight they need to make their teams work securely and gamifying leaderboards to make security competitive.     4. Mission-driven Businesses exist to achieve their mission. Security exists to ensure businesses can stay safe in order to achieve their mission. It’s that simple, and emergent CISOs are building their team around this premise. Unfortunately, often there are years worth of clunky legacy technology and processes that restrict employees, meaning CISOs need to go against the status quo, ask more from their solutions and not settle for anything less than frictionless UX. It’s awesome to see security teams start to judge their success on the delight of their employees – using metrics such as NPS or CSAT – as well as more security-centric metrics. After all, if you enable your employees, you’ll enable your business to succeed.     5. Technical proficiency There’s no doubt having a level of technical proficiency as a CISO is important, but the CISOs who are influencing the most and driving change in the profession often win because they are great communicators, understand business drivers and care about user experience. More and more, I’m seeing CISOs from non-technical backgrounds triumph by combining the above traits with hiring a team who bring the technical expertise.  It’s been awesome seeing security – and the role of the CSIO – change and observing which type of CISOs are having the most success. No doubt in 12 months time, the traits needed to succeed will have changed again and I’ll need to rewrite this 🤦‍♀️.   

We have been using OKRs (Objectives and Key Results) at Tessian for over 18 months now, including in the Engineering team. They’ve grown into an essential part of the organizational fabric of the department, but it wasn’t always this way. In this article I will share a few of the challenges we’ve faced, lessons we’ve learned and some of the solutions that have worked for us. I won’t try and sell you on OKRs or explain what an OKR is or how they work exactly; there’s lots of great content that already does this! Getting started When we introduced OKRs, there were about 30 people in the Engineering department. The complexity of the team was just reaching the tipping point where planning becomes necessary to operate effectively. We had never really needed to plan before, so we found OKR setting quite challenging, and we found ourselves taking a long time to set what turned out to be bad OKRs. It was tempting to think that this pain was caused by OKRs themselves. On reflection today, however, it’s clear that OKRs were merely surfacing an existing pain that would emerge at some point anyway. If teams can’t agree on an OKR, they’re probably not aligned about what they are working on. OKRs surfaced this misalignment and caused a little pain during the setting process that prevented a large pain during the quarter when the misalignment would have had a larger impact. The Key Result part of an OKR is supposed to describe the intended outcome in a specific and measurable way. This is sometimes straightforward, typically when a very clear metric is used, such as revenue or latency or uptime. However, in Engineering there are often KRs that are very hard to write well. It’s too easy to end up with a bunch of KRs that drive us to ship a bunch of features on time, but have no aspect of quality or impact. The other pitfall is aiming for a very measurable outcome that is based on a guess, which is what happens when there is no baseline to work from. Again, these challenges exist without OKRs, but they may never precipitate into the conversation about what a good outcome is for a particular deliverable without OKRs there to make it happen. Unfortunately we haven’t found the magic wand that makes this easy, and we still have some binary “deliver the feature” key results every quarter, but these are less frequent now. We will often set a KR to ship a feature in Q1 and to set up a metric and will then set a target for the metric in Q2 once we have a baseline. Or if we have a lot of delivery KRs, we’ll pull them out of OKRs altogether and zoom out to set the KR around their overall impact. An eternal debate in the OKR world is whether to set OKRs top-down (leadership dictate the OKRs and teams/individuals fill out the details) or bottom-up (leadership aggregates the OKRs of teams and individuals into something coherent) or some mixture of the two. We use a blend of the two, and will draft department OKRs as a leadership team and then iterate a lot with teams, sometimes changing them entirely. This takes time, though. Every iteration uncovers misalignment, capacity, stakeholder or research issues that need to be addressed. We’ve sometimes been frustrated and rushed this through as it feels like a waste of time, but when we’ve done this, we’ve just ended up with bigger problems later down the road that are harder to solve than setting decent OKRs in the first place. The lesson we’ve learned is that effort, engagement with teams and old-fashioned rigor are required when setting OKRs, so we budget 3-4 weeks for the whole process. Putting OKRs into Practice The last three points have all been about setting OKRs, but what about actually using them day to day? We’ve learned two things:  the importance of allowing a little flex, and  how frequent – but light – process is needed to get the most out of your OKRs First, flex. Our OKRs are quarterly, but sometimes we need to set a 6 month OKR because it just makes more sense! We encourage this to happen. We don’t obsess about making OKRs ladder up perfectly to higher-level OKRs. It’s nice when they do, but if this is a strict requirement, then we find that it’s hard to make OKRs that actually reflect the priorities of the quarter. Sometimes a month into the quarter, we realize we set a bad OKR or wrote it in the wrong way. A bit of flexibility here is important, but not too much. It’s important to learn from planning failures, but it is probably more important that OKRs reflect teams’ actual priorities and goals, or nobody is going to take them seriously. So tweak that metric or cancel that OKR if you really need to, but don’t go wild. Finally, process. If we don’t actively check in on OKRs weekly, we tend to find that all the value we get from OKRs is diluted. Course-corrections come too late or worries go unsolved for too long. To keep this sustainable, we do this very quickly. I have an OKR check-in on the agenda for all my 1-1s with direct reports, and we run a 15-minute group meeting every week with the Product team where each OKR owner flags any OKRs that are off track, and we work out what we need to do to resolve them. Often this causes us to open a slack channel or draft a document to solve the issue outside of the meeting so that we stick to the strict 15 minute time slot. Many of these lessons have come from suggestions from the team, so my final tip is that if you’re embarking on using OKRs in your Engineering team, or if you need to get them back on track, make sure you set some time aside to run a retrospective. This invites your leaders and managers to think about the mechanics of OKRs and planning, and they usually have the best ideas on how to improve things.

Customer Success (CS) is on fire. LinkedIn recently ranked CS as the 6th fastest growing role, 80% of CS teams saw growth last year and investors can’t get enough of net revenue retention (NRR). It’s never been more important to make your customers successful, but it’s also not always easy. In my journey growing Tessian from a 5 to a 150 person company, I am learning the importance of focus in creating the right environment for your CS team and customers to succeed.  Focus and attention needs to start at a company level. At Tessian, we’re lucky that long-term customer health and value has always been at the forefront of our founders’ minds; so much so that it became codified in of our core company values:

With a tick against company buy-in, my next learning was the importance of championing this value internally and with customers. To drive this focus, we developed a CS strategy built on 5 pillars. I’ve outlined our pillars below in the hope they may help other growing CS teams.

1. People It all starts with your people. It’s no longer enough to have a great product, it’s about how you deliver it. To turn your CS motion into extensions of your customers’ teams and into a key differentiator for your company (the holy grail), you need the best people motivated to push new boundaries. That’s why this pillar always comes first for us.      It’s all very well getting the best people in seat (we use interview scorecards based on our 5 pillars to source, interview and hire for the right competency and culture fit), but you also need to create an environment for people to succeed.   Doing so is a team commitment, which requires everyone to commit to helping each other thrive. One of the ways we’ve been doing this is through our “CS People Committee”, who meet monthly to review team sentiment and feedback from our employee engagement tool (Peakon). The committee works to ensure we are continually prioritizing the changes and refinements that are needed to ensure the team continues to remain a great place to work. They recently identified “career growth” as a key area for improvement, leading to the team collaborating to implement growth frameworks for all CS roles 🙌 !    We measure team success and progress using Peakon scores, but we all know the real impact of an engaged team is reflected in how our customers are doing, which is when we turn to our next pillar…   2. Customer Health   Having a deep understanding of your customers’ health is critical. Done well, the business impact for the team (proactive engagement, better understanding of value, more focused interactions) and customers (faster time to value, better feedback loops, earlier course-correcting) is huge.   The catch is that defining and measuring customer health isn’t easy; it is a nuanced, multi-faceted and a very contextual exercise.    Until we embarked on our journey of contextualizing customer health at Tessian, we relied on gut-feel and experience to diagnose customer health issues. This wasn’t going to scale with our rapidly-growing customer base, so we built a predictive customer health score in Gainsight, bringing together qualitative customer experience variables (relationship strength, sentiment, advocacy, etc) and quantitative product outcomes (time to deploy, product performance, portal engagement, etc) into one place.    This was a great start, but we soon realized our health score was an internally controlled score, which lacked external customer validation. Enter net promoter score (NPS). We built an adaptive NPS program based on the customer stage in their journey with us, giving us a constant stream of live customer feedback. Our NPS augments our predictive health score and has now become the north star metric for this particular pillar.  3. Customer Growth Net Revenue Retention (NRR) is fast becoming one of the most important metrics in SaaS, and CS is the new growth engine driving it. It’s a great measure of both product and customer success. Get it right (>100%) and company valuations soar. Get it wrong (<100%) and you’re going to struggle to survive.    We identified very early that onboarding was one of the key areas we needed to get right to positively impact our NRR. The quicker customers onboard, the quicker we’re showing value (for example, stopping breaches), and the more opportunities we have to show them how else we can help (by introducing them to our expanding product portfolio).   Through a combination of creating a dedicated onboarding team (less distractions for CSMs) and working closely with our product teams to drive automation in our product (post technical onboarding, our machine learning-led approach means little product configuration is required), we focused our CSMs on showing customers where there’s opportunity to deepen their protection and increase business value with Tessian.   Our quarterly account planning cycles help keep everyone (onboarding, CSMs, AMs, leadership) on the same page about how customers are progressing through their journeys and where we specifically need to focus our efforts.     As a result of this pillar, our NRR rate is now a key measure of success for not only our Customer Growth pillar, but for the company as a whole, with the CS team tracking against churn and expansion targets on a weekly basis.    Our growth focus doesn’t just stop at NRR. Sales Engineering also falls under the CS umbrella due to our proximity and intersection with Product, Engineering and, most importantly, our customers. The combination of anecdotal customer feedback and a deep understanding of the product and its use cases, leaves us with a formidable Sales Eng team who are focused on bringing more customers and revenue into Tessian 👊..   4. Customer Community   We very consciously set out to make a customer’s decision to buy Tessian about more than just buying our products; they’re also joining a the Human Layer Security movement (#SecureTheHumanLayer) that helps amplify their voice, profession and careers.   By creating a community of speakers, advocates and content creators, not only are we engaging with our customers at a deeper level, we’re also spreading the word, and building advocacy which in turns helps us to generate more pipeline, getting us closer to our mission of securing the human layer for enterprises across the globe.   We’ve repeatedly seen the power of putting our customers at the center of our community: our flagship event – The Human Layer Security Summit – has gone from 30 to over 2,500 attendees; our podcast was ranked among the best data breach podcasts after our debut season launched; and our customer-led product webinar series has been big hit. So we’ve decided to continue doubling-down on our customers’ involvement.   To incentivize the team to build and sustain a healthy customer community, we gamified customer involvement through creating an “advocacy events” score, which involves CSMs earning points as a result of customers engagement in our community (referrals, speakers, case studies, podcasts, reviews, etc). Going forward, we’ll be tracking which advocacy events lead to the most pipeline generation and acceleration of value for customers because, after all, that’s a core objective of our community.   

5. Product Enablement   Our product philosophy is based on the fact that security teams have too much to do with too little time; hence we lean heavily on automation and reducing time to manage. To maintain our product experience, we are very aware that we need to carry that philosophy through in our onboarding and support interactions.   To do so, we invested early (way before most people said we needed to) in building, maintaining and promoting a HelpCenter. This continues to be a great resource for educating both customers and new team members dealing with onboarding or technical issues. We learned soon after release that text-heavy articles are often counterproductive and get poor uptake, so we pivoted to snappy articles, explainer videos and lots of diagrams.    The feedback on the HelpCentre has been amazing and it has played a big role in influencing our key product enablement metrics: CSAT and % users onboarded.    Defining your pillars of success   We’re still on a journey of continually reviewing and refining our pillars (we have so much more to learn), but having this framework has allowed us to focus on the things that matter most for our company and customers.    Here are some top tips for defining your own pillars: Keep them simple – anyone should be able to glance at your pillars and quickly understand what your CS team is about. Align them to business priorities – what’s top of mind for your company in the next 12-18 months? Align your pillars to that. The more relevant they are to the company story, the more they’ll resonate with execs, leadership and other teams. And be sure to build a routine of re-examining and refining the pillars because as the business changes, so will your team’s focus. Make sure they’re measurable – pick a “north star” KPI to measure each pillar against. You’ll likely have a ton of supporting KPIs in each pillar, but the north star KPI will keep everyone focused on what’s important. Don’t pick too many! – we’ve learned that 5 to 6 is the sweet spot. Anything more and you risk spreading your focus too thinly and anything less you’re likely to not be effective in helping your company achieve its mission. I’ve only scratched the surface in this article but hope at least some of these lessons we’ve learned at Tessian can be helpful in your journey. It can sometimes be daunting to condense your team strategy into a few key pillars (not least because CS differs so wildly in every company), but get them right and your team will have the focus, clarity and ownership it requires to thrive 🤝 .  

Today, I’m thrilled to share the news that Tessian has raised a $65m Series C led by March Capital with participation from existing investors Sequoia Capital, Accel, Balderton Capital and Latitude and new investor Schroder Adveq!   Tessian has achieved a huge amount since our Series B funding in early 2019.   We’ve helped created a new category of security software, addressing the 90% of data breaches caused by human error in the enterprise: Integrated Cloud Email Security (ICES) We’ve added a slew of product enhancements to our platform including the Human Layer Risk Hub, machine based detection for incorrectly attached files on emails and email security against phishing emails from externally compromised vendors. We’ve expanded globally hiring an incredible team in the US, grown our company from 77 to over 150 and hired security experts to lead us in this next chapter. (Welcome again Ramin Sayar, Aaron Cote and Matt Smith 👋) But the work I’m most proud of is how we’ve served our customers. We tripled our Fortune 500 customer base in 2020, and to date have prevented an incredible 300k+ data breaches and security threats for our customers, as well as prevented over half a million phishing attacks that would otherwise have bypassed other security controls like Secure Email Gateways.   From the first meeting we had with March Capital, it was clear that we shared the same vision. March Capital’s experience with Crowdstrike and KnowBe4 not only showed them what it takes to build a category leader in security, but also, made it clear that so many challenges still remain to be solved.   As with our Seed, Series A and Series B, what’s always the most important thing, though, is the people who you’re going to be working with. I’m delighted to welcome Jamie Montgomery to Tessian’s Board of Directors and couldn’t be more excited to partner with him, Jed Leidheiser and the whole team at March Capital on our next chapter of growth.   I’m also excited to welcome Schroder Adveq to our investor base. Schroders and their security team have been invaluable supporters of Tessian right from the start when they became one of our first ever customers. It’s a great honor and a proud moment to have one of our first customers join our Series C and now support us as investors.   Tessian’s Series C marks an incredible new chapter for our company. The capital raised will be used to investing heavily in R&D to expand Tessian to secure other interfaces and communication channels beyond email, as well as bringing Human Layer Risk Scores to enterprises around the world, helping them quantify the security strengths and weaknesses of every single employee in their organization. We’ll also be expanding our go-to-market teams in the US, UK and beyond, as well as launching our first partnership programs led by our newly formed Business Development team.   But the most exciting thing about this Series C announcement is how it will help our customers. Every single minute Tessian’s behavioral intelligence models prevent 36 human layer security incidents. This new round of funding will see us continue to invest heavily in building world class Customer Success and Product teams to serve the security teams that rely on their human layer security. I’d like to take this opportunity to say a huge thank you to all of our customers. Without your support and trust none of this would be possible. Tessian would still be a concept in the sketchbook of Ed Bishop (my co-founder and Tessian’s Chief Technology Officer), not the company it is today.   And last but by no means least, the biggest thank you of all goes to our employees and the tireless, mission-driven work you put in every day to build our incredible company. Tessian shines so brightly because of your brilliance.   But as with every fundraise, this is just the beginning. It takes a village and we’re only just getting started. If you know anyone looking to take the next step in their career and to join a company solving the biggest problem in enterprise security today, please get in touch, we are hiring! 🚀

In this series, we’re going to go over the Quality Assurance journey we’ve been on here in the Client Side Integrations (CSI) team at Tessian. Most of this post will be using our experience with the Outlook Add-in, as that’s the piece of software most used by our clients. But the philosophies and learnings here apply to most software in general (regardless of where it’s run) with an emphasis on software that includes a UI. I’ll admit that the onus for this work was me sitting in my home office Saturday morning knowing that I’d have to start manual testing for an upcoming release in the next two weeks and just not being able to convince myself to click the “Send” button in Outlook after typing a subject of “Hello world” one more time… But once you start automating UI tests, it just builds on itself and you start being able to construct new tests from existing code. It can be such a euphoric experience. If you’ve ever dreaded (or are currently dreading) running through manual QA tests, keep reading and see if you can implement some of the solutions we have. Why QA in the Outlook Add-in Ecosystem is Hard The Outlook Add-in was the first piece of software written to run on our clients’ computers and, as a result of this, alongside needing to work in some of the oldest software Microsoft develops (Outlook), there are challenges when it comes to QA. These challenges include: Detecting faults in the add-in itself Detecting changes in Outlook which may result in functionality loss of our add-in Detecting changes in Windows that may result in performance issues of our add-in Testing the myriad of environments our add-in will be installed in The last point is the hardest to QA, as even a list of just a subset of the different configurations of Outlook shows the permutations of test environments just doesn’t scale well: Outlook’s Online vs Cached mode Outlook edition: 2010, 2013, 2016, 2019 perpetual license, 2019 volume license, M365 with its 5 update channels… Connected to On-Premise Exchange Vs Exchange Online/M365 Other add-ins in Outlook Third-party Exchange add-ins (Retention software, auditing, archiving, etc…) And now add non-Outlook related environment issues we’ve had to work through: Network proxies, VPNs, Endpoint protection Virus scanning software Windows versions One can see how it would be impossible to predict all the environmental configurations and validate our add-in functionality before releasing it. A Brief History of QA in Client Side Integrations (CSI) As many companies do – we started our QA journey with a QA team.  This was a set of individuals whose full time job was to install the latest commit of our add-in and test its functionality. This quickly grew where this team was managing/sharing VMs to ensure we worked on all those permutations above. They also worked hard to try and emulate the external factors of our clients’ environments like proxy servers, weak Internet connections, etc… This model works well for exploratory testing and finding strange edge cases, but where it doesn’t work well or scale well, is around communication (the person seeing the bug isn’t the person fixing the bug) and automation (every release takes more and more person-power as the list of regression issues gets longer and longer). In 2020 Andy Smith, our Head of Engineering, made a commitment that all QA in Tessian would be performed by Developers. This had a large impact on the CSI team as we test an external application (Outlook) across many different versions and configurations which can affect its UI. So CSI set out a three phase approach for the Development team to absorb the QA processes. (Watch how good we are at naming things in my team.) Short-Term The basic goal here was that the Developers would run through the same steps and processes that were already defined for our QA.  This meant a lot of manual testing, manually configuring environments, etc. The biggest learning from our team during this phase was that there needs to be a Developer on an overview board whenever you have a QA department to ensure that test steps actually test the thing you want. We found many instances where an assumption in a test step was made that was incorrect or didn’t fully test something. Medium-Term The idea here was that once the Developers are familiar and comfortable running through the processes defined by the QA department, we would then take over ownership of the actual tests themselves and make edits. Often these edits resulted in the ability to test a functionality with more accuracy or less steps. It also included the ability to stand up an environment that tests more permutations, etc. The ownership of the actual tests also meant that as we changed the steps, we needed to do it with automation in mind. Long-Term Automation. Whether it’s unit, integration, or UI tests, we need them automated. Let a computer run the same test over and over again let the Developers think of ever increasing complexity of what and how we test. Our QA Philosophy Because it would be impossible for us to test every permutation of potential clients’ environments before we release our software (or even an existing client’s environment), we approach our QA with the following philosophies: Software Engineers are in the Best Position to Perform QA This means that the people responsible for developing the feature or bug, are the best people when it comes to writing the test cases needed to validate the change, add those test cases to a release cycle, and to even run the test itself.  The why’s of this could be (and probably will be) a whole post. 🙂 Bugs Will Happen We’re human. We’ll miss something we shouldn’t have. We won’t think of something we should have.  On top of that, we’ll see something we didn’t even think was a possibility. So be kind and focus on the solution rather than the bad code commit. More Confidence, Quicker Our QA processes are here to give us more confidence in our software as quickly as possible, so we can release features or fixes to our clients. Whether we’re adding, editing, or removing a step in our QA process, we ask ourselves if doing this will bring more confidence to our release cycle or will it speed it up.  Sometimes we have to make trade-offs between the two. Never Release the Same Bug Twice Our QA process should be about preventing regressions on past issues just as much as it is about confirming functionality of new features. We want a robust enough process that when an issue is encountered and solved once, that same issue is never found again.  In the least, this would mean we’d never have the same bug with the same root cause again.  At most it would mean that we never see the same type of bug again, as a root cause could be different even though the loss in functionality is the same. An example of this last point is that if our team works through an issue where a virus scanner is preventing us from saving an attachment to disk, we should have a robust enough test that will also detect this same loss in functionality (the inability to save an attachment to disk) for any cause (for example, a change to how Outlook allows access to the attachment, or another add-in stubbing the attachment to zero-bytes for archiving purposes, etc…) How Did We Do? We started this journey with a handful of unit tests that were all automated in our CI environment.   Short-Term Phase During the Short-Term phase, there was an emphasis on new commits ensuring that we had unit tests alongside them.  Did we sometimes make a decision to release a feature with only manual tests because the code base didn’t lend itself to unit testability? YES! But we worked hard to always ensure we had a good reason for excluding unit tests instead of just assuming it couldn’t be done because it hadn’t before. Being flexible, while at the same time keeping your long-term goal in mind is key, and at times, challenging. Medium-Term This phase wasn’t made up of nearly as much test re-writing as we had intentionally set out for.  We added a section to our pull requests to include links to any manual testing steps required to test the new code. This resulted in more new, manual tests being written by developers than edits to existing ones. We did notice that the quality of tests changed.  It’s tempting to say, “for the better”, “or with better efficiency”, but I believe most of the change can more be attributed to an understanding that the tests were now being written for a different audience, namely Developers.  They became a bit more abstract and a bit more technical.  Less intuitive. They also became a bit more verbose as we get a bad taste in our mouth whenever we see a manual step that says something like, “Trigger an EnforcerFilter” with no description on which one? One that displays something to the user or just the admin? Etc…. This phase was also much shorter than we had originally thought it would be. Long-Term This was my favorite phase.  I’m actually one of those software engineers that LOVE writing unit tests. I will attribute this to JetBrains’ ReSharper (I could write about my love of ReSharper all day) interface which gives me oh-so-satisfying green checkmarks as my tests run… I love seeing more and more green checkmarks! We had arranged a long term OKR with Andy, which gave us three quarters in 2021 to implement automation of three of our major modules (Constructor, Enforcer, and Guardian)— with a stretch goal of getting one test working for our fourth major module, Defender.  We blew this out of the water and met them all (including a beta module – Architect) in one quarter.  It was addicting writing UI tests and watching the keyboard and mouse move on its own. Wrapping it All Up Like many software product companies large and small, Tessian started out with a manual QA department composed of technologists but not Software Engineers.  Along the way, we made the decision that Software Engineers need to own the QA of the software they work on. This led us on a journey, which included closer reviews of existing tests, writing new tests, and finally automating a majority of our tests. All of this combined allows us to release our software with more confidence, more quickly. Stay tuned for articles where we go into details about the actual automation of UI tests and get our hands dirty with some fun code.

We at Tessian are very passionate about the safety of our customers. We constantly handle sensitive email data to improve the quality of our protection against misdirected emails, exfiltration attempts, spear phishing etc. This means that many of our applications handle data that we can’t afford to have leaked or compromised.   As part of our efforts to keep customer data safe, we take care to encrypt any exceptions we log, as you never know when a variable that has the wrong type happens to contain an email address. This approach allows us to be liberal with the access we give to the logs, while giving us comfort that customer data won’t end up in them. Spark applications are no exception to this rule, however, implementing encryption for them turned out to be quite a journey.   So let us be your guide on this journey. This is a tale of despair, of betrayal and of triumph. It is a tale of PySpark exception encryption.

Problem statement   Before we enter the gates of darkness, we need to share some details about our system so that you know where we’re coming from.   The language of choice for our backend applications is Python 3. To achieve exception encryption we hook into Python’s error handling system and modify the traceback before logging it. This happens inside a function called init_logging() and looks roughly like this:

We use Spark 2.4.4. Spark Jobs are written entirely in Python; consequently, we are concerned with Python exceptions here. If you’ve ever seen a complete set of logs from a YARN-managed PySpark cluster, you know that a single ValueError can get logged tens of times in different forms; our goal will be to make sure all of them are either not present or encrypted.   We’ll be using the following error to simulate an exception raised by a Python function handling sensitive customer information:

Looking at this, we can separate the problem into 2 parts: the driver and the executors.   The executors   Let’s start with what we initially (correctly) perceived to be the main issue. Spark Executors are a fairly straightforward concept until you add Python into the mix. The specifics of what’s going on inside are not often talked about and are relevant to the discussion at hand, so let’s dive in.

All executors are actually JVMs, not python interpreters, and are implemented in Scala. Upon receiving Python code that needs to be executed (e.g. in rdd.map) they start a daemon written in Python that is responsible for forking the worker processes and supplying them with means of talking to the JVM, via sockets.   The protocol here is pretty convoluted and very low-level, so we won’t go into too much depth. What will be relevant to us are two details; both have to do with communication between the driver and the JVM:   The JVM executor expects the daemon to open a listening socket on the loopback interface and communicate the port back to it via stdout The worker code contains a general try-except that catches any errors from the application code and writes the traceback to the socket that’s read by the JVM   Point 2 is how the Python exceptions actually get to the executor logs, which is exactly why we can’t just use init_logging, even if we could guarantee that it was called: Python tracebacks are actually logged by Scala code!   How is this information useful? Well, you might notice that the daemon controls all Python execution, as it spawns the workers. If we can make it spawn a worker that will encrypt exceptions, our problems are solved. And it turns out Spark has an option that does just that: spark.python.daemon.module. This solution actually works; the problem is it’s incredibly fragile:   We now have to copy the code of the driver, which makes spark version updates difficult Remember, it communicates the port to the JVM via stdout. Anything else written to stdout (say, a warning output by one of the packages used for encryption) destroys the executor:

As you can probably tell by the level of detail here, we really did think we could do the encryption on this level. Disappointed, we went one level up and took a look at how the PythonException was handled in the Scala code.   Turns out it’s just logged on ERROR level with the Python traceback received from the worker treated as the message. Spark uses log4j, which provides a number of options to extend it; Spark, additionally, provides the option to override log processing using its configuration.   Thus, we will have achieved our goal if we encrypted the messages of all exceptions on log4j level. We did it by creating a custom RealEncryptExceptionLayout class that simply calls the default one unless it gets an exception, in which case it substitutes it with the one with an encrypted message. Here’s how it broadly looks:

To make this work we shipped this as a jar to the cluster and, importantly, specified the following configuration:

And voila! The driver: executor errors by way of Py4J   Satisfied with ourselves, we decided to grep the logs for the error before moving on to errors in the driver. Said moving on was not yet to be, however, as we found the following in the driver’s stdout:

This not only is incredibly readable but also not encrypted! This exception, as you can very easily tell, is thrown by the Scala code, specifically DAGScheduler, when a task set fails, in this case due to repeated task failures.   Fortunately for us, as illustrated by the diagram above, the driver simply runs python code in the interpreter that, as far as it’s concerned, just happens to call py4j APIs that, in turn, communicate with the JVM. Thus, it’s not meaningfully different from our backend applications in terms of error handling, so we can simply reuse the init_logging() function. If we do it and check the stdout we see that it does indeed work:

The driver: executor errors by way of TaskSetManager   Yes, believe it or not, we haven’t escaped the shadow of the Executor just yet. We’ve seen our fair share of the driver’s stdout. But what about stderr? Wouldn’t any reasonable person expect to see some of those juicy errors there as well?   We pride ourselves on being occasionally reasonable, so we did check. And lo and behold:

Turns out there is yet another component that reports errors from the executors: TaskSetManager; our good friend DAGScheduler also logs this error when a stage crashes because of it. Both of them, however, do this while processing events initially originating in the executors; where does the traceback really come from? In a rare flash of logic in our dark journey, from the Executor class, specifically the run method:

Aha, there’s a Serializer here! That’s very promising, we should be able to extend/replace it to encrypt the exception before actual serialization, right? Wrong. In fact, to our dismay, that used to be possible but was removed in version 2.0.0 (reference: https://issues.apache.org/jira/browse/SPARK-12414).   Seeing as how nothing is configurable at this end, let’s go back to the TaskSetManager and DAGScheduler and note that the offending tracebacks are logged by both of them. Since we are already manipulating the logging mechanism, why not go further down that lane and encrypt these logs as well?   Sure, that’s a possible solution. However, both log lines, as you can see in the snippet, are INFO. To find out that this particular log line contains a Python traceback from an executor we’d have to modify the Layout to parse it. Instead of doing that and risking writing a bad regex (a distinct possibility as some believe a good regex is an animal about as real as a unicorn) we decided to go for a simple and elegant solution. We simply don’t ship the .jar containing the Layout to the driver; like we said, elegant. That turns out to have the following effect:

And that’s all that we find in the stderr! Which suits us just fine, as any errors from the driver will be wrapped in Py4J, diligently reported in the stdout and, as we’ve established, encrypted.   The driver: python errors   That takes care of the executor errors in the driver. But the driver is nothing to sniff at either. It can fail and log exceptions just as well, can’t it?   As you have probably already guessed, this isn’t really a problem. After all, the driver is just running python code, and we’re already calling init_logging().   Satisfyingly enough it turns out to work as one would expect. For these errors we again need to look at the driver’s stdout. If we raise the exception in the code executed in the driver (i.e. the main function) the stdout normally contains:

Calling init_logging() turns this traceback into:

Conclusion   And thus our journey comes to an end. Ultimately our struggle has led us to two realizations; neither is particularly groundbreaking, but both are important to understand when dealing with PySpark:   Spark is not afraid to repeat itself in the logs, especially when it comes to errors. PySpark specifically is written in such a way that the driver and the executors are very different.   Before we say our goodbyes we feel like we must address one question: WHY? Why go through with this and not just abandon this complicated project?    Considering that the data our Spark jobs tend to handle is very sensitive, in most cases it is various properties of emails sent or received by our customers. If we give up on encrypting the exceptions, we must accept that this very sensitive information could end up in a traceback, at which point it will be propagated by Spark to various log files. The only real way to guarantee no personal data is leaked in this case is to forbid access to the logs altogether.   And while we did have to descend into the abyss and come back to achieve error encryption, debugging Spark jobs without access to logs is inviting the abyss inside yourself.

We don’t have to tell people that it’s been a hard year.  We’ve all been locked inside, unable to leave our local areas to explore the world around us. Tessians haven’t been able to see their families and friends IRL, and relationships have had to be maintained on zoom.  It’s tough, and it’s definitely weighing on all of us.  But, this summer we want to change that and hopefully give our Tessians the chance to make up for lost time. To spend time with loved ones, to take care of themselves, and (maybe, just maybe!) even board a plane again. We’ve been running what we’ve deemed “Refreshian Day” over the last year. This is a day we all take each quarter, to all be offline together, and to focus purely on taking care of ourselves.  Want to learn more? Check out this blog: Why Shutting Down Tessian Was The Best Decision We Ever Made. With the success of these days, we’re introducing something new: Refreshian Summer.  So, what exactly is Refreshian Summer? Every Friday in July and August will be a half day for Tessians – meaning we will all log off around lunchtime. No annual leave needs to be logged to take these afternoons off, it’s just time for all Tessians to spend doing whatever will bring them joy or relaxation. This seems like a lot of time off….why are we doing this?  First, we think it’s simply the right thing to do. Research has shown that in countries like the US and UK (where most Tessians are based), people are working 2 – 3 hours more per day. The line between our personal and professional lives are blurry and everyone seems to always be online. That means there’s never a delay between emails. It’s a perpetual cycle of quick responses, and persistent, intense pace. And, because people aren’t taking time off, there’s no real “break”.  While we don’t expect the pace to change (hypergrowth will always be demanding, and we like it that way!), we can change the way that we support our people.  We’ve found that on Refreshian Day, people genuinely manage to switch off, without worrying about what’s going on in their absence, or the number of emails that are coming through (because there aren’t any!). We want to create this feeling all summer. After what we’ve all been through, we really need to be able to take advantage of the sunniest days, in whatever way we like, and truly relax.  Plus, there’s some pretty cool research on how having something to look forward to bolsters our ability to cope with stress – we could all use a little of that right now!

How are we going to make this work? We appreciate that many of you will be thinking “How on earth are you going to get all your employees to reduce their working time by 10%?” or,“How are you going to manage this across multiple timezones, since you’re losing daily crossover time?” We get you, and we hear you.  But, we’re encouraging our team to remember that this is temporary. And we think that for a temporary period it’s possible to adapt and reduce our working time just one day per week, and to workout timezone issues. We don’t believe in mandating an approach (autonomy =  where the best ideas come from), and trust all Tessians to work with their team and manager to agree ways of working during this time.  But, we’ve come up with some broad suggestions on how people might work together to reduce time in meetings this summer. Here’s a look at some of these: Manage how you will communicate with team members in earlier/later time zones that you would normally have a Friday crossover with – e.g. Can you use asynchronous communication instead? Recording a short video clip is easy to do on Zoom and is a great way to communicate complex ideas.  We ask that every team scrutinize their recurring meeting and determine where you can temporarily reduce the number of meetings. For example:  Do you need to have a stand-up every day? Would 3 days per week suffice instead? Can you move your global wrap-ups to a Thursday afternoon (UK)/morning (US) instead?  Which 1 to 1s or team meetings can you reduce from weekly to bi-weekly, or can you shorten the duration? Does the idea of Sync & Maker hours work in your team and would it be worth trying out to increase efficiency? Should you block out Friday mornings on your calendar for “No Meetings” so that people have time to plan before the weekend? Do you have the right coverage/on-call approach in place if you’re in a customer facing role? There will be plenty of things we won’t have thought of, which we can’t wait to hear from our team about.  What’s next? This is an experiment – but one that we’re really excited to try. We will be seeking feedback continually from our team and adjusting where we need to as the summer goes on. We’ll also be collecting best practices from our teams who have found ways to reduce time spent in meetings (but maintain effectiveness) or communicate asynchronously.  And, we will simply be looking forward some well-earned time off this Refreshian Summer.  Want to learn more about Tessian’s values and culture? You can explore more articles here.

Ramin Sayar, President and CEO of Sumo Logic, has joined Tessian’s Board of Directors. In his role as a board member, Sayar will advise on various go-to-market strategies, technology strategies, as well as, help drive and improve operational excellence to support Tessian’s accelerated global growth. Sayar will continue to lead Sumo Logic as the company’s President and CEO, a position he has held since 2014. Sayar brings with him over 20 years of experience in the technology industry, along with a strong track record of developing innovative products in both emerging and mature markets. Mr. Sayar, an experienced strategic and operating leader of both small and large organizations, has a strong track record of developing innovative products in both emerging and mature markets. Prior to joining Sumo Logic he served as the Senior Vice President and General Manager of VMware’s Cloud Management Business Unit at VMware, which was the company’s fastest growing billion dollar business unit. Previously, Ramin held multiple executive roles with leading companies such as HP Software, Mercury Software, Tibco Software, AOL & Netscape. Sayar has also served as advisor and on the boards of various other startup companies, helping them build product, go-to-market and business strategies. On joining Tessian’s Board of Directors, Sayar said, “It’s very exciting to join such an innovative and pioneering team like Tessian. By focusing on people first, Tessian has defined and created a new category of security software that is defining the Human Layer Security movement, and I see more companies – legacy and new – following suit. Tessian’s technology enables businesses to visualize the risks posed by employees and easily take targeted actions to reduce them. What I find most impactful and remarkable is how Tessian drives lasting behavior change in employees, which ultimately makes them not only more accountable, but also more secure in their work and personal lives.” Tim Sadler, CEO and co-founder of Tessian said, “Having Ramin join Tessian’s board is another step in reinforcing our position as the category leader in Human Layer Security. Ramin is a world-class operator and one of the most empathetic leaders I’ve met. His human-first approach to business aligns perfectly with our company values and mission, and I believe this alignment will help us solve some of the biggest challenges that enterprises face today. With his knowledge of the industry and talent for helping innovative startups grow and thrive, Ramin’s appointment is going to be game-changing for our customers and our company.”

You might have read about our D&I learning journey, the start of our journey to create a better Tessian and a better world. After such an illuminating learning series, it was tempting to dive straight into initiatives and solutions. But if we want to tackle such significant and impactful challenges, we can’t work on everything all at once. We need focus.  So we made an active decision to approach D&I with the rigor we bring to all aspects of work at Tessian…and that means data. We gathered data we knew could inform our broader D&I strategy and help us to narrow down focus areas where we could have sustainable impact.  Gathering the data The aim of our internal research was to understand: What our representation at Tessian looks like; and Whether the experience of Tessians varies according to personal attributes and protected characteristics On a voluntary basis, we asked all our Tessians to submit information about themselves using our engagement platform Peakon. We had great uptake, with 80-90% of Tessians providing information about their personal attributes. This allowed us to understand representation at Tessian, across different aspects of diversity, including gender, sexual orientation, religion, ethnicity, and age. From this we were able to: Segment anonymous employee experience feedback scores to identify groups (based on personal characteristics) who are having a different experience and; Conduct a pay gap and employee retention analysis Determining focus areas You might be thinking…how statistically significant is data when you’re a small company (for reference, we’re currently about 150 people)? We asked ourselves this question A LOT. With so few data points, we were reluctant to draw certain conclusions from our findings. Instead, we have treated our findings as indicators of places we need to go and do further research. The data isn’t the be all and end all of our understanding, but it does provide the signposts.  We paired these data insights with what we hear from the company anecdotally, and what we know to be the case in the tech industry. This gave us a good picture of where Tessian is with D&I today. But we still needed focus. So, we asked ourselves: Where are our biggest concerns? Where can we make a significant impact? These two simple questions helped us to identify the key focus areas of our D&I efforts this year. So…where did we land? Ensure every Tessian continues to feel like they’re supported, valued and belong at Tessian Improve ethnicity and gender representation across all levels of seniority at Tessian We believe by focusing in these areas we can create a long-lasting positive impact on diversity and inclusion, in Tessian and in our industry. Building our strategy Once we had our focus areas, we worked closely with our exec team to build the strategy and tactics we would commit to this year. These discussions with our exec team centred not only on how to make change for a better Tessian, but also initiatives that would help create a more diverse industry.  As the exec team were bouncing ideas on tactics, we were careful to keep in mind every point of the employee life cycle. When thinking about D&I, it’s easy to focus on top of funnel diversity in hiring. Improving representation through hiring is important, but on its own it’s not enough. It matters what Tessians experience once they’re through the door too.

Once we had committed to the steps we’re taking this year, we kicked off by presenting our research and our strategy to the whole of Tessian. Our employees don’t just want to know what we’ve found, they want to know what we’re doing about it and when. So as part of this presentation, we shared this 2021 D&I roadmap.

As we work our way through the roadmap, we will be communicating progress, wins and learnings every two weeks in our employee newsletter. We want every Tessian to stay super engaged in this work, and to have the opportunity to bring ideas and feedback to the table. How our work this year will create long-term solutions It’s no secret that today, the tech industry isn’t that diverse. If we want representation of  diverse people at Tessian, it’s not enough to draw from the existent talent pool, where so many groups are so underrepresented. By this we mean that it’s not enough for us to think about short term wins for Tessian’s stats. We need to be committed to making positive, sustainable change in the long term. And that means changing the whole industry, as well as Tessian.  We want to create opportunities for a range of people to move into tech, and make sure they want to stay! If we don’t, our CFO, Sabrina Castiglione, will tell you how no-one wins in this zero-sum game.  Our long term strategy is about growing and expanding the entry-level talent pool by creating junior jobs for people entering the tech industry, whether that’s in Sales or Engineering. But remember, we don’t just want to bring them in, we want them to stay, learn and grow! Only then will we get representation of diverse voices in senior positions.  To achieve this, we’re prioritizing the development of future leaders through well-defined growth frameworks across the company. Every Tessian creates a detailed growth plan, and by the end of the year, we’ll have a tailored growth framework for every single department at Tessian.  These tactics won’t move the needle on senior representation this year. Probably not next year either. But through them, we can change the game when it comes to diversity in tech. We want to see senior representation, and that means bringing in and building up fresh talent.  How to act today As well as the longer-term goals, we’re taking action on some short-term wins to ensure our business is an equitable and inclusive place for everyone today. Even before that representation has changed.  D&I needs to be baked into the culture of a business. And that doesn’t just mean D&I training alone.  It means we need to interrogate every single one of our People processes and ask “Is there opportunity for bias here?”.  It means we need to inspect our company communications and ask “Who has a voice here?” It means we need to listen to employee feedback and ask “Do people have an equitable experience here?” There’s nothing stopping us asking these questions today. And the good news is — we have the power to have a huge impact on the answers straight away. Want to keep up with our D&I journey? Subscribe to our weekly blog digest to be the first to hear about updates. Or, if you’d rather explore open opportunities at Tessian, click here.