Request a Demo of Tessian Today.
Automatically stop data breaches and security threats caused by employees on email. Powered by machine learning, Tessian detects anomalies in real-time, integrating seamlessly with your email environment within minutes and starting protection in a day. Provides you with unparalleled visibility into human security risks to remediate threats and ensure compliance.

See a sneak peek of Tessian in action featuring admin and end user experiences. Watch the Product Tour →

Life at Tessian

Learn more about Tessian company news, events, and culture directly from different teams. Hear from engineering, product, customer success, and more.

Engineering Team
Tessian’s Client Side Integrations QA Journey – Part I
By Craig Callender
20 May 2021
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.
Engineering Team
How Do You Encrypt PySpark Exceptions?
By Vladimir Mazlov
14 May 2021
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.
Life at Tessian
Why We’re Logging Off at Lunchtime This Summer
By Paige Rinke
12 May 2021
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.
Life at Tessian
Sumo Logic CEO Ramin Sayar Joins Tessian’s Board of Directors
By Tessian
06 May 2021
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.”
Life at Tessian
How We Created a D&I Strategy to Maximize Impact
By Amina Godfrey
19 April 2021
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. 
Engineering Team
How We Improved Developer Experience in a Rapidly Growing Engineering Team
By Andy Smith
16 April 2021
Developer experience is one of most important things for a Head of Engineering to care about. Is development safe and fast? Are developers proud of their work? Are our processes enabling great collaboration and getting the best out of the team?  But sometimes, developer experience doesn’t get the attention it deserves. It is never the most urgent problem to solve, there are lots of different opinions about how to make improvements, and it seems very hard to measure.  At Tessian the team grows and evolves very quickly; we’ve gone from 20 developers to over 60 in just 3 years.  When the team was smaller, it was straightforward to keep a finger on the pulse of developer experience. With such a large and rapidly growing team, it’s all too easy for developer experience to be overshadowed by other priorities. At the end of 2020, it became clear that we needed a way to get a department-wide view of the perception of our developer experience that we could use to inform decisions and see whether those decisions had an impact. We decided one thing that would really help is a regular survey.  This would help us spot patterns quickly and it would give us a way to know if we were improving or getting worse. Most importantly it gives everyone in the team a chance to have their say and to understand what others are thinking.  Borrowing some ideas from Spotify, we sent the survey out in January to the whole Engineering team to get their honest, anonymized feedback. We’ll be repeating this quarterly.  Here are some of the high-level topics we covered in the survey. Speed and ease To better understand if our developers feel they can work quickly and securely, we asked the following questions: How simple, safe and painless is it to release your work? Do you feel that the speed of development is high? !function(e,t,s,i){var n="InfogramEmbeds",o=e.getElementsByTagName("script"),d=o[0],r=/^http:/.test(e.location)?"http:":"https:";if(/^\/{2}/.test(i)&&(i=r+i),window[n]&&window[n].initialized)window[n].process&&window[n].process();else if(!e.getElementById(s)){var a=e.createElement("script");a.async=1,a.id=s,a.src=i,d.parentNode.insertBefore(a,d)}}(document,0,"infogram-async","//e.infogram.com/js/dist/embed-loader-min.js");
You can see we got a big spread of answers, with quite a few detractors. We looked into this more deeply and identified that the primary driver for this is that some changes cannot be released independently by developers; some changes have a dependency on other teams and this can slow down development.  We’d heard similar feedback before running the survey which had led us to start migrating from Amazon ECS to Kubernetes. This would allow our Engineering teams to make more changes themselves. It was great to validate this strategy with results from the survey. More feedback called out a lack of test automation in an important component of our system.  We weren’t taking risks here, but we were using up Engineering time unnecessarily. This led to us deciding to commit to a project that would bring automation here. This has already led to us finding issues 15x quicker than before:
Autonomy and satisfaction We identified two areas of strength revealed by asking the following questions: How proud are you of the work you produce and the impact it has for customers? How much do you feel your team has a say in what they build and how they build it? !function(e,t,s,i){var n="InfogramEmbeds",o=e.getElementsByTagName("script"),d=o[0],r=/^http:/.test(e.location)?"http:":"https:";if(/^\/{2}/.test(i)&&(i=r+i),window[n]&&window[n].initialized)window[n].process&&window[n].process();else if(!e.getElementById(s)){var a=e.createElement("script");a.async=1,a.id=s,a.src=i,d.parentNode.insertBefore(a,d)}}(document,0,"infogram-async","//e.infogram.com/js/dist/embed-loader-min.js");
These are two areas that we’ve always worked very hard on because they are so important to us at Tessian. In fact, customer impact and having a say in what is built are the top two reasons that engineers decide to join Tessian.  We’ve recently introduced a Slack channel called #securingthehumanlayer, where our Sales and Customer Success teams share quotes and stories from customers and prospects who have been wowed by their Tessian experience or who have avoided major data breaches (or embarrassing ‘Oh sh*t’ moments!).  We’ve also introduced changes to how OKRs are set, which gives the team much more autonomy over their OKRs and more time to collaborate with other teams when defining OKRs. Recently we launched a new product feature, Misattached File Prevention. Within one hour of enabling this product for our customers, we were able to share an anonymised story of an awesome flag that we’d caught.
What’s next? We’re running the next survey again soon and are excited to see what we learn and how we can make the developer experience at Tessian as great as possible.
Engineering Team Compliance Life at Tessian
Securing SOC 2 Certification
By Trevor Luker
30 March 2021
Building on our existing ISO 27001 security certification, Tessian is excited to announce that we have achieved Service Organization Control 2 Type 2 (SOC 2) compliance in the key domains of Security, Confidentiality and Availability with zero exceptions on our very first attempt. Achieving full SOC 2 Type 2 compliance within 6 months is simply sensational and is a huge achievement for our company. It reinforces our message to customers and prospects that Information Security and protecting customer data is at the very core of everything Tessian does.
The Journey We began the preparations for SOC 2 in September 2020 and initiated the formal process in October. Having previously experienced the pain and trauma of doing SOC 2 manually, we knew that to move quickly, we needed tooling to assist with the evidence gathering and reporting.  Fortunately we were introduced to VANTA, which automates the majority of the information gathering tasks, allowing the Tessian team to concentrate on identifying and closing any gaps we had. VANTA is a great platform, and we would recommend it to any other company undertaking SOC 2 or ISO 27001 certification. For the external audit part of the process, we were especially fortunate to team up with Barr Advisory who proactively helped us navigate the maze of the Trust Service Criteria requirements. They provided skilled, objective advice and guidance along the way, and we would particularly like to thank Cody Hewell and Kyle Helles for their insights, enthusiasm and support. Tessian chose an accelerated three month observation period, which in turn, put a lot of pressure on internal resources to respond to information requests and deliver process changes as required. The Tessian team knew how important SOC 2 was to us strategically and rallied to the challenge. Despite some extremely short timeframes, we were able to deliver the evidence that the auditors needed.  A huge team effort and a great reflection of Tessian’s Craft At Speed value. What Next? Achieving SOC 2 Type 2 is a crucial step for Tessian as we expand further into the large enterprise space. It’s also the basis on which we will further develop our compliance and risk management initiatives, leading to specialized government security accreditation in the US and Europe over the next year or two.
Life at Tessian
Mind Over Matter: Why We Prioritize a Growth Mindset at Tessian
By Samantha Holt
30 March 2021
“I can’t ….” “I’m an anxious person.” “I’m bad with numbers.” “I don’t understand the technical stuff; it’s just not for me!” Sound familiar? These are the limiting beliefs of someone stuck in what Dr. Carol Dweck, Stanford University psychologist and author of Mindsets: The New Psychology of Success, termed “fixed mindset.”  The problem with a fixed mindset If you’re in the “fixed mindset” camp, you most likely avoid challenges, don’t like failure (flag! can be prone to sandbag), ignore feedback, and believe you’re stuck with what you’ve got: your intelligence, talents, and abilities.  You’re simply what you are. People in this camp often rely on talent alone and will spend time looking for praise and recognition vs building on past successes, seeing the silver lining in failures, and getting better. If you say out loud that you’ll never understand the technical stuff … your team will believe it and more importantly, YOU will believe it. The opportunity to learn will end there. The very language we use to describe our limitations makes those limitations a reality.  This can be especially limiting when it comes to doing things out of your comfort zone. Why mindset matters when you’re out of your comfort zone  The mindset you have will likely how you react when you’re out of your comfort zone.  To keep it simple, there are likely only three directions you’ll gravitate towards when you’re out of your comfort zone:  Flight: You’ll freak out and run the other way, seeking shelter and safety  Fight: You’ll get angry, irritated, or annoyed by the situation  Freeze: You’ll freeze in your tracks, not able to move the conversation forward, hoping no one notices  This is where a “growth mindset” comes in.
The learning zone: A growth mindset You want to find space between the trigger and your response (i.e. fleeing, fighting or freezing) where you can plant your feet firmly on the ground, step into the chaos, and try to learn from the difficult situation. If you’re in the “growth mindset” camp, you believe your intelligence, talents, and abilities can grow through Grit & Perseverance (a Tessian value!).  What you’re born with is just the foundation, which cultivates an insatiable desire in you to continue learning and improving.  How is Tessian championing a growth mindset? In the last year, we created a Global Leadership Team (GLT) to help our people work on personal and leadership growth. 
We focused on growth mindset because an essential part of scaling a hyper-growth start-up is building a culture where your people are unafraid to set moonshot goals.  But to set these ambitious moonshot goals, we also need to be comfortable with failing fast, iterating, and continuing to build. As Simon Sinek says “What good is an idea if it remains an idea? Try. Experiment. Iterate. Fail. Try again. Change the world.”  At Tessian we want to change the world of cybersecurity. During our GLT sessions on growth mindset, our biggest takeaway was that we need to change how we view our failures. This change of mindset takes time, but we’ve already begun relishing in challenges, because mistakes and setbacks aren’t a reflection on us — just on our preparation and current ability, which are adaptable. We can grow! Tips to help you adopt a growth mindset We’re creating a culture where our leaders are open to feedback, accountable for their own growth, and resilient to take on new challenges — we are seeing the impact of this with increased creativity, innovation, and bottom-line growth. So, how can you adopt a growth mindset? Here are three of the core “growth mindset” tenants we implemented: Openly recognize and reward the value of learning from failure with your team. Failure is inevitable when it comes to running a team. So when you’re running a retrospective, it’s a good idea to openly speak about your own failures and those of the team, plus the lessons you learned. This will help create a culture where failure is recognized as a learning tool. Result? Your team will be encouraged to grow and take innovative risks. Embed a company or leadership value that focuses on perseverance. A great organization doesn’t grow overnight. The fruits of growth require time, which means perseverance is key. We found having a company value around “Grit & Perseverance” helped to better embed this concept throughout our teams. We speak about it at our Town Halls, Weekly All Hands, and Performance Reviews. The company is clear on how important it to push through failure, treat obstacles as challenges, and persist in spite of difficult situations to produce more impactful results. Pay close attention to the language you use in 1:1s with your direct reports and team meetings. Top tip: Remove the “you can’t” mindset and adopt a “how can you” mindset with your team. Also, think about moving from “this was a failure” to “we failed, this is what we learned, now let’s go make this even better”. Everyone has desires, and most of us can channel our efforts toward diligent work. But the ability to overcome constant failure has proven to be the distinguishing factor between ‘good’ and ‘great’. Language will help motivate your teams to keep coming back from failures; they will feel it’s safe for them to fail. (Hint! This is all about psychological safety). If you want to learn more about growth mindset, here are some of our favorite resources: Everything written by Dr. Dweck is great! But if you’re going to read or listen to anything, we’d recommend you watch this TedTalk or read this HBR article. We found it helpful to check out how other start-ups were using “Growth Mindset” to develop their leaders and found this article on Microsoft helpful We love everything from Farnam Street, and found ourselves coming back to this article, Creating a Growth Mindset in the Workplace again and again Farnam Street has done a great summary of the two different mindsets here Inspired by this article? Share it with your network on LinkedIn and Twitter! Or, if you’re looking for more insights into how we work at Tessian, subscribe to our newsletter below.
Engineering Team Life at Tessian
Early adoption: Is Now the Time to Invest in the ‘New Breed’ of Security Products?
By Phil O'Hagan
25 February 2021
There’s an (unfair!) perception in the industry that most CISOs are skeptical, or at least conservative, when it comes to adopting the latest security technology. But the role of the CISO is evolving. It’s no longer to simply “own” risk. Today, they’re also tasked with educating and informing everybody within the company – including the C-Suite – on the risks and what can be done to mitigate them.  In this fast moving world, it’s no longer possible to be passive. Only those who are open-minded (and ideally progressive) will protect their company from the most advanced threats. A year of firsts  The security industry is moving in a different direction. We need only look back at the last 12 months to see why: COVID has raised the profile for security.  A greater attack profile has caught the attention of executive teams, and they are looking to CISOs to respond. But, it’s not all bad news. Just as cybercriminals see opportunity in disruption, CISOs have an opportunity to play a bigger role at the executive level. The digital transformation has been accelerated. The shift to remote working means an increased attack surface. Today, security teams must support whole departments of remote workers as they engage with technology in their kitchens, bedrooms, and coffee shops. CISOs need to do more than send the occasional email or facilitate annual training to raise awareness about cyber threats.  Ransomware is an ever-growing threat. In fact, almost a third of victims pay a ransom, which means the stakes are higher than ever.  Attackers have improved the implementation of their encryption schemes, making them harder to crack. And, rather than simply encrypting critical data, some criminals now steal sensitive data and threaten to release it if the ransom is not paid.  With so much changing, CISOs have to adapt fast and adopt new technology to succeed. Gartner calls this period of early adoption a “hype cycle”.  And, for any new innovation, early publicity produces a number of success stories — often accompanied by scores of failures. Some companies take action; many do not. Where do you stand? The technology balance Both inside and outside of security, there are plenty of arguments both for and against new technologies:
Given the rapidly evolving threat landscape, though, CISOs should be pushed harder than most to commit fully to the leading edge of security innovation. After all, “nobody got fired for buying IBM” and “fortune favors the brave“, right? The next generation of security  More and more CISOs are choosing to be brave. Why? It comes down to the modern way this next generation of security is being designed and built.  Today’s security benefits  are focused on cutting the risk out of early participation while amplifying the benefits. At the heart of the change are two related trends:  Next-generation security services  The advancement of machine learning The next generation of security services has removed the need for CISOs to be experts on negotiating IT project. Instead, they can focus on managing the risks to their business.  For example, with cloud services, the costs of infrastructure – and efforts of supporting it – are completely removed as the services you buy are scalable to match the business. Cloud services also require no maintenance or professional assistance beyond an internet browser. The cloud means that the hurdles and expense associated with “trying out something new” are hugely mitigated. And, because these next-gen security services are hosted on the cloud, you’ll always have the latest version.  There is only one “copy” of these software tools. That means upgrade cycles have come down from once a year to multiple times a day. Better still, these services connect to one another. This equates to a shallower learning curve for users, faster time-to-market, and the flexibility to bolt on future tools that suit the way you want to run your operation.
Legacy technology vs. machine learning Whereas legacy technology uses rule-based techniques to secure organizational risks, new providers leverage machine learning to provide accurate, automatic protection, and visibility against advanced risks, otherwise impossible to detect with legacy systems. Machine learning’s goal is to understand the structure of the data and fit theoretical distributions to that data that is well understood. And, because machine learning often uses an iterative approach to learn from data, the learning can be easily automated. Passes are run through the data until a robust pattern is found. In an ever-evolving security world, this allows for the identification of specific risks. By using machine learning algorithms to build models that uncover these connections, organizations can make better decisions without human intervention. For example, identifying anomalous behaviors that form part of the most advanced threats in the enterprise. The benefit for CISOs – and their security teams – is clear. Lower time commitment to identify and remediate issues and more accurate reporting on the risks to the business. These next generation tools also achieve something legacy systems can’t and don’t: they share de-identified data between customers to ensure everyone is protected, even from threats that haven’t (yet) been seen in their own network. The benefit? Organizations continually – and automatically – improve their protection against an ever-changing threat environment. Low risk, high reward  Finally, like never before – and because these services are in the cloud – security leaders are in a position to switch on new services at low risk, without any upfront investment.  With no upfront CapEx, chances are that your first steps will be below any procurement ceiling too – so PoCs become simple to execute. It becomes rational to test a service or strategy with a small team before rolling out more broadly.  And, because the barrier to try (and switch!) for these early adopters is so low, “try before you buy” is a prevalent trend. With low switching costs, the software developers behind the scenes have a wholehearted commitment to making the trial period compelling enough to convince you to take the next step. They have skin in the game and understand that happy customers dictate whether or not a product is successful. This lowering of barriers, enabling of small-scale testing, and offsetting of cost should all make it a little more tempting for CISOs to take the leap and occasionally try for first-mover status. Because adopting innovative practices has never been so low-risk and the rewards are well-worth it.  To name a few… improving your security posture, reducing admin, and protecting your employees from ever-evolving threats.
Life at Tessian
Seriously Tech, It’s Time to Ditch the Zero-Sum Game
By Sabrina Castiglione
06 January 2021
In the spirit of the late-90’s classic, 10 things I hate about you, here are 10 things I hate about how my industry thinks about Diversity: Assuming Diversity = Inclusion 1D-diversity: focus on only one of gender, race, sexuality, etc. Diversity as just a hiring problem Inclusion as just a People/HR team problem Ending the convo after unconscious bias training PR without follow-through Leaving D&I to the affinity groups Assuming Equality = Equity Lack of measurement  The Zero-Sum Game I could talk about any of these, but the zero-sum game is the one that doesn’t get spoken about anywhere near enough. An example: The gender gap in tech
Here’s a simplified version where we take gender as an example.  To make the numbers easier to understand, let’s imagine that the tech industry is 75% male, 25% female (this is generous; women make up c. 24% of Technology positions). Every Tech company:  ‘We want a 50/50 gender balance’  Does dedicated diversity sourcing, asks for diverse shortlists, shouts a lot about diversity, has a fancy policy, etc etc. Also many Tech companies:  Does nothing to improve the gender diversity of the overall industry pool This is crazy. If there were 100 tech workers in the whole world, 25 were female and 75 were male, and there were two 50-person tech companies out there… if one of those companies actually achieved a 50/50 gender split, the other company would be at 0/100.  This is, at best, a local, not global success.  The tech industry’s diversity push is one never ending tug of war, yet this is the zero-sum game and the approach most tech companies take. So what does really caring about diversity look like?  TL;DR: bringing up a more diverse next generation.  Stereotypes are insidious and start at an early age – way before workers enter the workforce, even before students pick their disciplines in school that affect how they enter the workforce. There’s even evidence to suggest these stereotypes are there before children even learn to read.  And these stereotypes tell minorities that technical, high-paying jobs in tech aren’t for people like them. We’re only going to solve the diversity problem in tech by going to the source, where there are two issues:  Not enough diverse people entering the technology workforce (whether out of school or switching later in life); and  The pipeline is leaky – diverse candidates are more likely to exit the tech industry (for caring duties, personal reasons, or discrimination) than those in the majority. Inclusion initiatives should help with the second facet – and there’s been great work by many tech companies to shift to more human-first working patterns, practices and policies to shore up the leaks. But there is a lot of work to do to combat the first challenge & get more people into tech in the first place.
What you can do to support diversity in tech So, tech companies out there, here are three things you can do to get us out of this zero-sum game: 1. Support early-age initiatives Awareness of future career opportunities in diverse populations is a challenge. At Tessian, we’ve been working with organisations such as the WISE Campaign’s Young Professionals’ Board whose mission is to inspire, engage & advocate for the next generation of STEM (science, technology, engineering and maths). Gisela Rossi, Tessian Engineer & WYPB member has been supporting initiatives such as the Tara Binns book series working to break down stereotypes in children aged 5-11, and running competitions to engage children in these industries. There are many great organisations out there such as the WISE Campaign, and STEM.org, but don’t just donate dollars – donate voices, and donate time. 2. Go back to school On that note, volunteering initiatives are powerful. We encourage our Tessians to take volunteer days & outreach to schools to raise the profile of voices in tech, and evangelize that tech can be for anyone. Don’t just leave it to teachers – show the promise of these roles to the next generation, don’t just tell them about it. A quick tip is to reach out to local schools – especially those that lack the resources to explore these subjects. Local alumni speakers who are actually in these industries are a quick and simple way to show children that there are real opportunities out there for all people – including people like them.  3. Grads Grads Grads (& Career Changers) Yes, you need diversity at the top too, but if all your roles demand 5+ years of experience, the next generation of diverse candidates is never going to arrive.  As soon as you reach a critical mass, you need entry-level programs and paid internships – and yes; they have to be paid, because unpaid internships are only viable for those who can already afford not to bring in earnings.  What about at Tessian? At Tessian, we were less than 15 people when we hired our first intern, and we’ve run paid internships (sometimes in full blown programs, sometimes ad-hoc) and brought in young talent ever since. And we’re hiring our next engineering grad intake now. Yes – it’s going to eat up some management time, but in my view, any tech company with a decent cash balance that isn’t running either paid internships or entry-level programs, isn’t taking diversity seriously in a meaningful sense. Doing the right thing, and running a human first company can be hard; the benefit of the initiatives will be felt by the tech industry in 10 or 20 years’ time, not the tech industry of today.  The ROI in your one to three year business plan isn’t going to bear the fruit of these initiatives, but folks, we have to solve this: we have a huge skills gap in tech and cyber security, where there are high paid jobs sitting vacant for lack of interest and training.  As an industry with so much promise and so much investment, we need to stop looking inwards and start looking outwards to the global tech ecosystem, or our diversity initiatives will just be us forever chasing our tail.
Life at Tessian
Why Shutting Down Tessian Was The Best Decision We Ever Made
By Sabrina Castiglione
24 December 2020
When we set out to define our values, we asked our people what being a Tessian meant to them. The value that was born out of this – now our first and foremost value – is Human First.  Human First is the value we’d always had but never captured in words. As soon as it crystallized, it was everywhere. Within weeks you would hear it in every other meeting, it would be the first question in every decision that touched our people, and it merged completely into how we think about our mission; even more than being a cutting-edge technology company, we’re a cutting-edge human company, building for human beings as they are, not how security standards want them to be. So what does it mean to be a Human First company in the age of coronavirus? Like many companies a lifetime ago (March 2020) we went remote overnight. A formerly office-first company, we’d naively expected lower productivity & that everyone would be more relaxed not having to travel to and from the office every day. We were so wrong.
A couple of weeks in, once the novelty of an extra hour in bed had worn off and we had realized that being remote wasn’t stopping work getting done, we started to pick up on themes – people working later and later, more and more questions in our employee engagement platform about mental health, self care, and dealing with stress.  We talked a lot more about our Employee Assistance Program and we told people they should still try & take their paid leave. But compounded by being confined at home, those who managed to take leave found that they couldn’t help but gravitate back to their phone & laptop, with email & messaging pinging throughout the day (and night, since we’re an international team). Our Tessians couldn’t switch off with no-where to go and the spectre of their inboxes piling up and up. We knew we needed to stop saying things, and needed to do something big, fast. So we shut down the Company. (For a day.) Why? Let’s roll back a moment. We asked people why they were struggling to switch off, and we listened to their fears of letting their teammates down with so much work going on, and the creep in hours to find overlap time with their international colleagues.  We realized that unless all our Tessians – from the CEO, to our newest graduates – were all offline, it was hard for anyone to be offline. Enter Refreshian Day.
Refreshian Day is not a vacation or holiday day. It’s a paid day we give to our Tessians, to do what they need to do to take care of themselves, when all Tessians are offline, together. When we know our people have been, or will be, working even harder than usual to bring our vision to life, it’s important to give something back. Our first Refreshian was in July; our second, October. And today we’ve announced our third in February 2021.  We ask only two things of our people on Refreshian day: Don’t work Take time to take care of you Being human means one size never fits all, and our Tessians have variously taken long walks, spa days, watched sunsets, crafted pottery and baked a lot (lot, lot) of bread. Being a human first company means giving our people the space and time to revel in what makes them unique – even if it means shutting everything down from time to time.
How would you spend your Refreshian day? Join us and find out.
Life at Tessian
Our Journey Towards Diversity and Inclusion
By Jade Jarvis
18 December 2020
Over the past few months, Tessian has been taking steps towards creating a more diverse and more inclusive place to work.  Why? Because We’ve acknowledged that we’re not as diverse as we want to be. But, we’re committed to making a change.  Why is this so important to us?  Of course, there are many reasons (just a few mentioned by our very own Tessians) but the two main drivers are for:  The individual: it’s the right thing to do. Diversity is infinite and everyone should feel valued for who they are and have the opportunity to bring this to work.  Our future: With diversity of thought, we can be a better Tessian. This will enable us to not only challenge the status quo and stay ahead of innovations, but also create opportunities for more people to be a part of our journey.  We know this isn’t something we can change overnight, but we’re already making small positive moves in the short-term as we work towards those bigger, long-term changes.  Most importantly, we simply want to make a difference where we can. This is an industry-wide problem. That means it involves every single one of our Tessians. So, where do we start? We believe the first step is understanding and awareness, combined with action and change. This is what prompted us to begin our Diversity and Inclusion learning journey.  The Journey  We partnered with Jeff Turner to build and deliver our D&I learning journey for everyone to experience together – to learn, connect and come together as one company.  Two key aims for the program were:  Shared understanding: Part of the training was to socialize D&I terms; to not only get everyone ‘speaking the same language’, but also to create a safe environment for people to ask questions and learn about each other’s different perspectives.  Building connections: We chat to some of our colleagues every day. But, how many times do you get the response ‘Good, thanks’ when you ask someone how they are? I bet almost every time! We wanted to give people the chance to build connections across departments at Tessian and encourage people to share deep experiences that they otherwise might not have.  The program consisted of three sessions (described very high-level below) and each were delivered two weeks apart:  Diversity: Appreciating our differences and knowing that everyone brings value to the workplace.  Unconscious Bias: Accepting that everyone naturally has their own biases which have formed over time based on our life experiences, preferences, education – all the things that make us who we are. And importantly, recognizing that we can make the unconscious, conscious by challenging our own biases when making decisions.  Building Inclusion: Consciously ensuring our behavior is inclusive and learning how to appropriately call out exclusive behavior including microaggressions.  There were 25+ people involved in each session. Importantly, these people dialed in from all around the world. This enabled the sessions to be interactive. We also learned from feedback that these smaller, diverse groups made people feel safe and encouraged everyone to share their personal experiences. No judgement.  But we didn’t want these sessions to be the only place where people talked about Diversity and Inclusion.  To ensure the conversation continued throughout the business, we sent out pre-reads with three key learning objectives and three things to think about ahead of the session and post-reads with the top three takeaways and suggested follow up actions. 
What did we learn?  We’ve had exceptional feedback following the completion of this program and already feel like it has had a positive impact on our company culture.  The essence of the feedback is that the program genuinely encouraged deep self-reflection and learning. People have told us that not only have they already learned things that will change how they behave going forward, but that it’s been an amazing bonding experience with their colleagues – which means even more in this period of remote worklife.  A few direct quotes from our employees: “Best D&I session I’ve had – it didn’t focus on the more obvious points of diversity but delved much more deeply into what makes each of us different.” “IT WAS BLOODY AWESOME.” “I love these sessions, they challenge your perceptions and make you know other people you work with better. I am honestly sad that there’s only one left.” It doesn’t end there… As we’ve said, there’s no quick fix here. We have to keep working together to enable change.  Our culture is highly collaborative and that’s why it’s so important to us that we’re co-creating solutions and actions with Tessians as we go – to find out what they want, what they need, and how we can learn together along the way.  Here are a few ways we’re continuing to push forward:  Inclusion competition: We’ve asked people to submit their ideas for what we can do to create a more inclusive place to work. Ideas will be judged based on potential impact, scalability, and originality. We’ve already received some great entries so far. Watch this space!  ‘Managing Inclusively’: In 2021, Jeff will be back to deliver an additional session exclusively for our managers. Here we will go even deeper – talking about privilege and the power that we disproportionately hold as managers, and how to use this power to create change. D&I report: For the first time ever, we’ll be internally publishing a D&I report to share key metrics and what these metrics mean. Transparency is an essential component. We expect to uncover a lot of home truths that will lead us to building the right solutions for Tessian. We have a long way to go on this journey of creating a better Tessian and a better world. We will continue to share as we go along, and would love to hear from anyone interested in coming on this journey with us.
Page