The relationship between mental wellbeing and work is being talked about now more than ever.  We’re all experiencing different emotions around the current global pandemic and seeing firsthand that if we don’t manage our stress and anxiety, we can’t be productive or thrive in our roles.  At Tessian, we put mental wellbeing at the top of our list of priorities because we know it’s critical to the health and success of our employees. We’re approaching this head on by launching our new mindfulness program — TesWell. TesWell runs for 4 weeks and covers topics like building a mindfulness practice, growing in resilience, understanding emotions, creating habits, and teaching employees how to have difficult conversations. The program is a proactive step to give all Tessians the tools to learn how to grow in openness, awareness, and presence in each moment so we all feel more resilient towards changing circumstances.   Resilience has become especially important during COVID19; we’re all having to adapt to changing work environments. But, we think it’s important to share some of the insights that have been the basis of this new program. This way, people outside of Tessian can support mental wellbeing in their own workplace.

1. Mental wellbeing starts with a conversation One of the most powerful ways you can foster mental wellbeing (or support mental health problems) in your workplace is simply to talk about them — this is the first step to normalizing mental health problems and reducing the stigma around them.   This is important because when we feel we’re able to speak up about our mental health at work, it means we can get ahead of problems and prevent them from spiraling. We’ve found there are many ways to get the conversation started. For example, sharing posts on Slack channels about mental wellbeing (we’ve even created a channel dedicated to wellbeing). Managers have even more opportunities to initiate these conversations. How? By intentionally (and frequently) speaking to people about their own wellbeing.  In a recent session we held with our managers on mental wellbeing, we had some great suggestions on how to start the conversation. These ranged from making sure managers are asking their team members how they’re feeling during 1:1 check-ins to encouraging managers to share their own stories of how they’re coping during this time.  This second point is of particular importance. Leaders must shed light into the darkest corners of their own journey so others know they are not alone in their own fight. This allows employees to feel safe and to begin speaking up about their own mental health challenges.  Think of it as an exercise in empowerment. 2. Leaders need to role-model healthy behaviors Leaders can role-model healthy, stress-reducing behaviors such as taking regularly scheduled breaks, engaging in walking meetings, and going offline at a reasonable hour rather than being available all the time.  We’ve found that using our calendars to demonstrate these healthy behaviours can spark others to feel it’s okay to do the same. For example, taking an hour and a half lunch break to go out for a run and eat lunch, taking a proactive mental health day (and labeling it this way in your calendar), or simply scheduling “meditation” at any point during the day — these are all great ways to do this.  3. Create programs that signal mental wellbeing as a top priority  There are many initiatives companies can implement during COVID19 like TesWell that signal to employees that their wellbeing is important. This could be programs related to physical activity or initiatives that provide social interactions with others (even in this remote world). The point is to help remind employees  that staying healthy requires a holistic approach — we have to nurture our bodies and minds and offer self-compassion to ourselves.  So, make it a priority to help people develop good habits. How? offer meditation, mindfulness, yoga or even a free fitness membership like ClassPass.  The bottom line? You can foster mental wellbeing for your company simply by talking about it.  

Mental wellbeing starts with a conversation. It’s our job, then, to ensure we create a safe space to facilitate those conversations and implement programs so our people know their mental health is a priority.   Whether virtual or in-person, at Tessian, we’re Human First.

As a founder, I knew from Day one how important our values were going to be in order to build the company we dreamed of creating. So when I began to hear murmurs late last year that not everyone at Tessian was understanding what our values meant for them, I knew it was time to investigate how our people were feeling and what we might need to do to revamp our values.   To me this listening exercise was vital because our values guide everything. They aren’t aspirational words hanging on a wall that no one understands; they’re the backbone of a company.   With this in mind, we went on a month-long journey of listening to our employees, and created values which are a true reflection of Tessian today. They’re actionable, intuitive and central to everything we do, from our recruitment process through to performance and development.    You can check them out in more detail below. But before I get to our revamped values, I want to tell you more about the journey we went on to make sure they truly reflected what Tessians care about.   Why do company values matter in the first place?   Values aren’t just a corporate thing; values are crucial for both our personal and professional lives. They’re a code we live by, they define what’s important to us, and they help us make decisions day to day. Sometimes our values are so deeply ingrained, we don’t realize we’re using them every day to make choices.    At Tessian, we’ve seen our values as a North star from the beginning. They steer our decision making, serving as a code to help us make choices, especially when it’s not obvious what we should do. They help us hire the right people, individuals who care about the things we care about and can take Tessian in the right direction.  Our values also inform our performance reviews, development conversations, and how we reward, recognize and promote our people. Our values underpin our culture.    Why did we decide to revamp our values at Tessian?   We use Peakon, a tool that helps companies build and maintain engaged teams and great company cultures. It does this through employee surveys, which provide insights into how our employees feel about different things. Late last year, our Peakon data revealed a theme: our values weren’t understood by all our people.    We saw that:  People were being rewarded for different behaviors underlying our values (and these were in conflict with each other); and  Behaviors that were really important to us weren’t reflected in our values. In other words, we had a gap in our values. I wanted to do something to fix this. We ask Tessians to show up every day, living and breathing these values. If there’s confusion over what they look like in practice, we’ll all be rowing in different directions. Equally, as people join the team, if there are things that are important to us that aren’t explicitly reflected in our values, we run the risk of losing or diluting those things over time.

How did we revamp our values?   We knew we needed to re-work our values. The question was: how?    The most important thing was to get input from as many people as possible from all across the business: different genders, backgrounds, functions, tenures, and levels of seniority. That was the only way we’d get the values that accurately reflect Tessian.    We started by sending out a questionnaire to the whole company to understand from a high level what was most important to us. It included questions like:    What do you think of our current values (what values do and don’t resonate)? If you could add a value, what would it be? What do you value in yourself and your colleagues?    We received a high response rate, but we wanted to dig deeper. Next, we set up 1-1s with about half of the respondents to delve deeper into their answers.   We then aggregated all of this information into a pre-read to run a workshop with our Values Focus Group (this consisted of 15 people who had signed up to be our “Values advocates”). We followed this up with additional 1-1s with each of our Values Focus Group members.   All of this work meant that the whole of Tessian went on this journey together; our values were crafted from the top-down and bottom-up, so had a great chance of being “sticky”.    Having gathered so much input from across the business, we then started to reformulate our values with a clear view of what was truly important to our people. Here’s an illustration of the words that came up the most during our journey that guided us in our reformulation.  

Our new values A lot of interesting things came out of the listening tour. First and foremost was the fact that there was a “gap” in our values—this became a new value called “Human First”.  This value was the most prominent finding in all of our work; time and again people said how important treating each other with kindness, respect and inclusion is at Tessian. It was so clearly part of the fabric of Tessian. It also seemed like a huge miss to not have this as we are a Human Layer Security company which believes people are the most important part of every organization. With all this in mind, we knew we had to codify it as its own value.   Here are some tips we found worked for us when writing our new values:   Focus on the actual words your employees are using during the discovery process, and not words that are “hot” right now in your industry or the public generally. Staying true to your employees’ language when writing your new values will help them better resonate in the end.  Observe how the value is being embodied around you because so much understanding comes from the values in action; and  Don’t be limited by what you think your values are, or what you think they should be. Go in with an open mind and candidly narrate the values you uncover.  Without further ado, here’s the entire set of revamped values. They make me proud to be a Tessian, because I know that they reflect the real values and aspirations of all of our people.

Human first.   We approach everything with empathy and we look out for each other alongside our own wellbeing. Respect, kindness and inclusion are at the core of our company because our people are what make us Tessian. 

Customer centricity.   We fixate on our customers’ success. They’re the lifeblood of our business and guide our daily decision-making. Whether we’re launching a feature, or pursuing a partnership, we always ask “How does this help our current and future customers?” 

Positive mindset. Solution oriented.   We lead with a curious, positive mindset, and go above and beyond to find solutions when problems arise. When our solutions fail, they fail fast — we embrace the failure and keep learning, iterating, and improving.

Grit and perseverance.   We have sustained passion for achieving long-term goals. We see setbacks as opportunities to adapt and grow. We’re committed to building resilience and have the motivation to tackle big challenges that others might give up on.

We do the right thing.   We’re always honest and guided by integrity in every decision we make; with one another, with our customers, with everyone. We do what we believe is right, even when it means making difficult decisions.

Craft at speed.   We work with great care and skill, sometimes at an uncomfortably fast pace. Rather than aim for perfection in one at the expense of the other, we balance attention to detail with speed of delivery.

In December we successfully flipped around half a billion monthly API requests from our Ruby on Rails application to some new Python 3 applications. Now that the dust has settled, and we’re comfortable that all has gone well, I wanted to write up the details of the project, give a bit of a history of Engineering at Tessian, and share some lessons learned in the hope that others may benefit from mistakes we’ve made. In the beginning, there was Rails Long before Tessian became what it is today, most of our code base for our backend infrastructure was written in Ruby on Rails. This was the right choice of technology at the time; it allowed us to produce a reliable product while iterating quickly. But as we grew it became apparent that being able to share production code with our data science team (who predominantly work in Python) would allow us to move much more quickly. That was when we decided to build out some core backend functionality using Python 3. This would allow our backend code to lean heavily on various open source tooling for data science and machine learning. That decision was made 3 years ago and today, in hindsight, it still looks like the right call. However, and you may be ahead of me already here, deciding to start using Python did not magically get rid of all the Ruby code we had already written. That was the situation one of our Engineering teams found themselves pondering in August last year.  Deciding to migrate At Tessian our teams have themes to help define their place in the world. Themes are mini mission statements that ladder up to Tessian’s greater mission to secure the human layer. One team’s theme is “Tessian’s stellar security reputation aids growth”. Since the team’s inception, they had been focusing on building security features in our Python code, where a lot of backend development and data processing takes place. While debating the most important thing to work on next, we decided to dig in to some data. This showed that 500,000 API requests an hour were being handled by our Ruby on Rails application server. Looking at that number, coupled with the fact that we had grown the Engineering team 100% in the past year and hired 0 Ruby developers, it quickly became apparent that this part of our code base needed some attention. The following factors ultimately contributed to our decision: The proportion of Ruby experts in the company was depleting. Improvements to code linting, security frameworks were getting added to Python and not Ruby. Our Ruby app had not kept up with improvements we had made to monitoring and alerting. Ruby was the original code base and contained some of the oldest and least well understood code in the company. There were some tickets in our backlog around poor performance of some of the Ruby endpoints, meaning future development of them was likely. So the decision was made: we would port the existing Ruby APIs to our Python code base, allowing them to make use of our latest frameworks and practices. Path to migration Given the high volume of traffic and the importance of the APIs we wanted to ensure that we kept risk to a minimum when porting them. With this code came other challenges such as poorly defined interfaces and many different client versions.  After a few whiteboard sessions, we settled on a phased approach that went as follows. Phase 0 – Existing setup The original setup – clients talking to our Ruby application.

Phase 1 – Transparent proxying First we built a new Python application to transparently proxy traffic to our Ruby application. We slotted this in to the API flow. Because it just proxied traffic, this was a relatively safe operation.

Phase 2 – Response generation and comparison The next step (and we did this for each API that we migrated) was to implement the API and use live production data to compare “what we would have sent”, being generated by the Python App, (new_response) with “what we should have and did send” (old_response). By comparing the responses, we could catch errors in the implementation based on live production data and fix them. Note that this was not perfect; most of our APIs mutated state in a database in a way that was not idempotent. This meant that we never wanted both Ruby and Python to affect the database – it was either one or the other.

Phase 3 – Switchover Once we had confidence that the response being returned was correct, it was time to stop using Ruby to affect the database and start using Python. Note that because we did not want conflicts between Ruby and Python both altering database state, as we switched over, we stopped calling Ruby. As mentioned above, this had not been tested on production, so still had with it some risk. So we did this in a staged approach, first routing 10% of traffic, then 50% then 100%. Focusing first on our internal dog food tenancy.

And that was it! Once we had done this for all APIs the amount of Ruby code in production was drastically reduced. Retrospective At Tessian we believe that we will build the best teams and product by being open about when things go wrong; we also believe in creating a blameless culture. We suffered one incident as a result of this migration. This had a very limited impact on customers. It caused a minor degradation to our web UI only – not our predictions. We were able to retroactively fix the symptoms, but this was something that we took seriously. The issue was that one of our new Python APIs did not update a database column that the Ruby APIs previously did. In hindsight we think that our comparison framework gave us a false sense of security in the code porting. Our key takeaway was that next time we will have to be more conscious of what it would catch (us breaking our APIs) and what it would not (incorrect database updates).  If we were to do it again, we would do it mostly the same way, but with more thorough code review on these components. All in all we consider the project to be a success and believe that it will aid Tessian’s stellar security reputation thanks to the amazing hard work of the all engineers who worked on this project!

Tessian Data Scientists design the algorithms that are at the heart of what we do. We wouldn’t exist without our machine learning models, and it’s what our clients rely on day-to-day. But what does this mean in practice? Companies can leverage data science in a number of ways, and we think the role of a Data Scientist falls into three distinct categories: 1. You work for a business function analyzing & reporting on how to improve a key metric; e.g. increasing user conversion. 2. You are responsible for writing production models to enhance the main product; e.g recommendation systems for e-commerce. 3. You build machine learning models, which are the product the company sells. First, we love email More specifically we love massive enterprise email datasets. Email doesn’t have the best reputation with engineers – the protocol is ancient, poorly defined, even more poorly secured and email isn’t Slack. As a Data Science team we don’t think of email in terms of SMTP, but rather a beautiful, dynamic and pretty-huge JSON dataset that captures the intricacies of human-to-human communication. Email knows who you communicate with, what you communicate about, what clients you’re pitching, what projects you’ve just completed, who your team members are, your company hierarchy, (excitingly) the list goes on.

Of course, all this information is hidden, messy and unstructured But that’s where we come in. Using machine learning and NLP, we build bespoke anomaly detection models to prevent threats executable by humans (rather than code) to secure our client’s communications. We also care deeply about the end user experience of our products, which sounds obvious, but is much more difficult (and in our opinion, important) when machine learning is involved due to its black box nature. This means we spend a lot of time focussing on the explainability of our machine learning predictions back to the end user. For example, why does this email look misdirected? Why does this email you’re receiving look malicious? Notifications with context are more effective than lazy boilerplate warnings (the industry standard). Another exciting part of being a Data Scientist at Tessian is that we are always thinking about future products we should be building. The great thing about email data is that it’s not “opinionated” about the problem we are trying to solve, meaning we can experiment with solving different problems using the exact same dataset. Sometimes this involves us trying to find signal in the noise, like when we discovered strong-form spear phishing impersonation attacks were getting past existing defenses. Other times it involves trying to solve specific threats and problems brought to us by our clients. The highlight of my week is the Data Science Brainstorming session where we discuss all of our ideas for new products, current product improvements, as well as any new papers/tools that we’ve read about that might help us further our research and models.

One thing I’ve touched on a lot, but not specifically discussed is data And that’s why at Tessian it’s impossible to talk about Data Science without talking about Engineering. To train our machine learning algorithms we need lots of data, and to deploy and run our models in production, we need this data processed with minimal latency. Our Data Science team own the data and what we do with it. But to process, store and scale this data, we call in the Engineering teams to help. How Data Science and Engineering work together is a much discussed topic and one for which I believe there is no out-of-the-box solution. We’re still figuring it out and tweaking our process, but currently we follow a similar model to Jeff Magnusson’s (Stitch Fix). It’s explained here in Engineers Shouldn’t Write ETL. The platform and Engineering teams leverage their domain knowledge to build and expose data frameworks, empowering our Data Scientists to have end-to-end ownership of their work. This has the added benefit of freeing up Engineering teams to focus on building and scaling our core APIs, rather than maintaining fiddly data pipelines. We’re a friendly bunch of ambitious Engineers building breakthrough machine learning and natural language technologies to analyze, understand & protect enterprise communication networks. Tessian Stack Overflow     #engineering

Today we’re excited to open source our internal release tool – Catapult. At Tessian we run our CI/CD pipelines from Concourse. (Like many, we picked Concourse because it’s not Jenkins*, but we’ll save that for another blog post). Although Concourse is a fantastic build tool that cures a lot of headaches for us, as the creators will readily admit, it is not necessarily a tool with the most advanced security setup. As a company that deals with some of the world’s most sensitive data, this was not good enough for us. We wanted a release tool with security features like two-factor authentication and an audit trail that we had come to expect from other tools we use day to day. At Tessian we also empower our development teams to release and maintain their own services, so we wanted a system that allowed for permissioning. After some head scratching, it became apparent that we didn’t need to reinvent the wheel. By driving our releases from files stored in S3 and making use of Concourse resources, we could meet all of our requirements and more. This was our list of demands: • Fine-grained permissioning • An extensive audit trail • Flexibility • Two-factor Authentication • High Speed & High Availability • Usability So what exactly is Catapult? Catapult is two things: • a command line tool that manages state in S3 • a Concourse Resource, that consumes said S3 bucket The permissioning is all managed on the AWS side and left as an exercise to the reader. Command line The catapult command showing a new release In the background this is doing a number of checks. It’s looking at S3, git and our docker repository. Assuming they have the correct permissions, this will update a file in S3, which our Catapult Concourse Resource is monitoring. Concourse resource When the resource discovers a new version of the file, it will download it; create a new version of the Concourse resource; display all the above metadata; and – assuming it is set up to do so – trigger a new task. From here you can do whatever you want with the version managed in Concourse. What next? We think there’s plenty of work left to do on Catapult but wanted to share what we’ve built thus far with the world. We’re very keen to hear feedback, please send us a pull request or issue on Github! *We think TheNewStack give a nice summary of some issues we’ve had with Jenkins in past lives: https://thenewstack.io/many-problems-jenkins-continuous-delivery/       #engineering

On 23rd June 2019, we are celebrating the outstanding achievements of women engineers across the world as the sixth International Women In Engineering Day takes place. This year the theme is all about transforming the future so we’ve asked some of our engineers what they think the future holds for engineering and how we can get more girls into this exciting industry. Monika Pawluczuk, Developer Why do you love being an engineer? I get to create and be innovative. I can join a passion with work, and it feels like I’m doing something meaningful. How do we encourage more women to get into engineering? I think that we need more role models. There are so many strong women in tech that we can look up to from Ada Lovelace and Margaret Hamilton, to more modern examples like Parisa Tabriz, Radia Perlman, Allison Randal or Lyndsey Scott – yes, a Victoria’s Secret model that is also a programmer! I think the best motivation is seeing successful women in tech that we can strive to become one day. What do you think / hope the future of engineering looks like? I hope it becomes an environment that everyone can thrive in. Curiosity, courage and innovation are at the heart of engineering. I hope that, in the future, children’s education will change and kids will be introduced to creating games and robots much earlier on. Andy Smith, Head of Engineering What’s the best bit about being an engineer? Having to solve hard problems that you don’t know the answer to. It’s daunting at first but it’s hugely satisfying when your solution works. You may soon learn that it wasn’t quite as simple as you thought, but the learning experience of having your understanding of the problem evolve is rewarding. Why is diversity important in engineering? It’s just smart to aim for a diverse engineering team. If you find yourself trying to make an important decision with a group of people similar to yourself – it’s not uncommon to find that you all agree. A group of engineers all agreeing is generally something to be concerned about. We need different people to bring different ideas, and the only way to make great decisions is to have a broad range of input. We have the best outcomes when we disagree and debate. What do you hope the future of engineering looks like? Diverse. Cassie Quek, Data Scientist What’s the best bit about being an engineer? The best bit for me is being able to help build the tools of tomorrow that make a positive impact in the lives of others. How do we encourage more women to get into engineering? I think, as female engineers, we can be more vocal about our experiences. We need to show that there is an active community of women in engineering roles and that a lot of the obstacles we think would arise from working in a traditionally male-dominated environment are imagined. It’s also important to know that there will be plenty of support. What do you hope the future of engineering looks like? I would love to see the tech engineering scene become even more diverse in all regards – maybe one day eroding even the existence of any cultural stereotype. Ed Bishop, Chief Technology Officer Why is diversity important in engineering? The problems we are solving are diverse, so to build the best product and have the greatest impact, we need to have an engineering team that reflects that diversity. Otherwise you don’t have the right ideas, opinions and empathy at the table and your product will suffer as a result. What do you hope the future of engineering looks like? I hope that engineering teams of the future will also be diverse in seniority levels. Diversity needs to be reflected in junior hires all the way through to executives. That’s when teams, and products, will truly benefit from having all voices represented. Sabrina Castiglione, Chief Financial Officer and Chair of the WISE Young Professionals’ Board Why is engineering an exciting industry to be part of? A lot of engineering is about being creative and solving real problems that impact people’s lives – and even saving lives! From working on the systems that land people on space stations to writing the algorithms behind the software that is transforming our daily lives, engineers are working collaboratively and making a huge difference to what the future of the world will look like. How do we encourage more women to get into involved? I think a lot of the stereotypes about engineering don’t reflect the reality of what a vibrant, exciting, and impactful careers engineering can lead to. That needs to change. We also need to set positive examples for the next generation. As part of my work with WISE, I’ve been helping with a Harper Collins collaboration on the Tara Binns book series – including Tara Binns: Big Idea Engineer – to show Key Stage 2 girls that careers like engineering are for people like them. Johan Kestenare, Data Scientist Why is diversity important in engineering? Diversity is important in engineering, as in life. Both talent and innovation are not owned by one gender, and being able to share ideas with women as well as people from different cultures allows me and my team to develop our professional and personal skills. Some of best products and concepts are created by a team built on diversity. What do you think the future of engineering looks like? In the future, I hope we that won’t have to ask that question again simply because diversity in engineering wouldn’t be questioned. Diversity would have become the “norm.”     #engineering

Picture this: It’s 4pm on a Wednesday. While the rest of the working world is going through their midweek slump – clock watching and/or waiting for their boss to turn comments before burning the midnight oil – you are stepping in to the boardroom of a leading London law firm. In front of you, as you pour yourself a glass of sparkling water with a postcard panorama of the city skyline behind you, are the Managing Partner and Head of IT. They usher you into your seat. As you scramble to connect the various adapters into your MacBook, your mind is 100% focused on delivering a pitch on why their firm should today solve their biggest problem. You need to educate, persuade and ultimately introduce this organization to machine learning (sometimes, for the first time). As you load up your slides on Keynote, it’s show time. At Tessian, this is not a what-if scenario, this is just one of the daily occurrences as a Business Development Manager (BDM). I had the rare opportunity to be ‘patient zero’ for the Business Development function at Tessian. And it was – and continues to be – an unbelievably exhilarating experience. Every single exercise has value: multiple introductory emails to prospective customers, pitching and ultimately navigating organizations to implementation all help our company achieve our goals.

As a BDM, you are experiencing entrepreneurship in its most raw, gritty form. You are your own rapid-growth business within a rapid-growth business. You get to experience the glamorous highs – as detailed above – alongside the excruciating lows, all at breakneck pace. Industry-defining deals are the norm, and your targets have a direct impact on the products our team can ship, the services we can offer to our customers, and our ultimate mission to protect enterprises from threats executed by humans in order to keep the world’s most sensitive data and systems secure.

Given the nature of the role – a discipline in process, a fervent desire to do things faster and better, creative and strategic thinking, and collaboration through external stakeholder management – BD has become a natural breeding ground for commercial leadership at Tessian. It’s not just here, but across organizations: 20% of Fortune 500 CEOs have come from a selling/marketing background and there is a common adage in start-up world that an overwhelming amount of successful entrepreneurs have first built careers in sales. It’s true here as well – our CEO, founders, Head of US, Enterprise and Finance Directors, and myself (Chief Revenue Officer) have effectively all built our careers in some way as BDMs at Tessian.

Tessian is hoping to redefine sales and business development. We don’t believe in nor hire those who portray the negative stereotypes around sales. BDMs at Tessian are some of the brightest, hardest-working and most upstanding people I have interacted with in my career. It’s humbling to come in and work with these people on a daily basis and I am incredibly grateful that our team’s constant ambition is to outperform. I sometimes think of the famous Sheryl Sandberg quote to Harvard Business School grads: “If you’re offered a seat on a rocket ship, don’t ask what seat! Just get on.” As a member of the Business Development team at Tessian, we get to be right in the control room. And from our window, there’s an incredible view.

Cybersecurity has an image problem. To many, it simultaneously conjures up feelings of stale corporate software and cliched messaging rife with anonymous hacker and military-grade defense references. It’s also an incredibly crowded space with over 2,500 brands and platforms competing for every business’s budget. Most of these solutions are invisible to end users and have zero margin for error. Let that sink in for a minute. With that said, cybersecurity, specifically information security, is now seen as essential to an enterprise’s overall operations and bottom line; today CISOs report into Boards of Directors. The increasing responsibility (due in part to stringent data protection policies like GDPR), heightened risks of processing and storing sensitive data and the fact that no organization appears to be safe from a data breach has given information security a new purpose and place within the structure of a business. So is cybersecurity the place to begin or evolve your career in marketing or design? Compared to consumer tech, it doesn’t ostensibly offer the same opportunities to flex creative muscles or deviate from rigid B2B tactics. But because of the inherent challenges and the growing need for every business to adopt a comprehensive cybersecurity strategy, this is the space for creative disruption and fresh perspectives. At Tessian, we’re building a world-class Marcomms team with the ambition of bucking convention and reimagining B2B, SaaS and cybersecurity marketing. We’re proving it can be creative and calculated, inspiring and effective. Tessian’s mission is to keep the world’s most sensitive data and technology systems secure. Our job is to build a brand that embodies this mission, and more importantly, that captures the market’s attention and turns users into satisfied customers. Marcomms at Tessian is a multidisciplinary function comprised of wildly talented communications generalists, specialists and designers. Nearly everything we do is cross-functional, which means we collaborate with every internal team—with Engineering and Data Science to ensure we authentically communicate our technology and product offering; with Client Development to capture customer success stories; with Business Development to create compelling content and execute exclusive events that help nurture leads and gain new customers. Our core objective is filling the top of the funnel and delivering pipeline to the sales team. Our targets are big. We deliver them through a variety of strategic channel activities including events, digital marketing, content creation and PR. We have the freedom and drive to constantly experiment, measure and refine our efforts in order to optimize performance. We move fast, and our work satisfies the analytical and big picture thinker in each of us. I left Google a year ago to take some time off and carefully consider my next career move. I had a decade of experience in consumer brand and product marketing, working with incredible creative talent on exciting technology. I loved it and learned a lot. But over time I was missing a few things—real autonomy and accountability. I wanted to help build something from the ground up and to be responsible for delivering exceptional and sustainable results. I got my chance by joining Tessian. In just three months, I have learned so much, acquired more responsibility than I could imagine and, most importantly, I’ve started to assemble an extraordinary team of brilliant people from different disciplines, each of whom challenges me and makes me better at my job. Our goals for 2019 are bold and courageous. To achieve them, we are looking for key talent to round out our capabilities. Check out the open roles at tessian.com/careers. In the meantime, meet our Marcomms team and hear what they think of Tessian— “As a creative graduate having worked for independent studios and within in-house teams, building a design career at Tessian has been decidedly different. Cybersecurity companies face an uphill struggle when constructing the visual narratives that power their brands—the sector is filled with overly complex explanations of technology and iconographic cliché; the shield, the padlock, the lightning strike. Design at Tessian is instead always evolving and growing, and allows you to work in all areas of the company, integrating with sales to produce pitch decks, or with client development to produce workflow diagrams, or with operations and recruitment for branded collateral and event organization.” – Leon Brown, Designer “I joined Tessian in September 2017 as the first marketer, and it’s been astonishing to see how the team has grown. When I joined it was crucial to quickly kick-start new marketing channels, and show in a very quick way the positive impact marketing has on the company and how it aligns to business goals. Then it was about building a marketing function and processes which could scale. We now focus on hiring specialists and ensuring everyone in the team is aware of the direction they are moving in and how they can get to their desired destination. I truly believe you need to hire people smarter than you and get out of the way – it’s important to allow people to be effective and perform to achieve the best results. I thoroughly enjoy working at Tessian. Marketing has always been a passion of mine, but marketing for- and at- Tessian is a whole other feeling. It’s a joy to work with such clever and driven individuals to really understand how, as a team, we can optimise our key marketing activities to the point where we can make accurate predictions on how many leads, MQLs or even revenue each channel can generate. There are some unique challenges working in a startup, but they’re also some of the biggest selling points; there may not always be a set process or structure for things, but for the right hire it can be invigorating to set up the infrastructure for the marketing team. It’s something you will keep optimising; nothing is ever stagnant. Everything is possible, which can sound terrifying, but it’s one of the most exciting things about working at Tessian. We never say something can’t be done, but rather always work together to figure it out. We learn from every failure as much as we do success.” – Chandni Trehan, Marketing Manager “Joining Tessian has made moving from Los Angeles to London more than worth it. (Even in winter.) During the universally stressful college senior job search, my motto was high growth and high impact. After graduating from UCLA, I joined Tessian as the second full-time hire on the marketing team. In under six months, I’ve been given the chance to forge my own path: come up with an idea, organize the plan of action and execute. I own the space in which I operate, while working closely and cross-functionally with every team in the office, which offers both breadth and depth, as I continue to learn and grow alongside some of the sharpest, savviest people I’ve ever known. What’s it like being at Tessian, in one word? Meaningful. Every day, we walk into work with the knowledge that what we do matters. And that’s as hard to find as it is fulfilling. While rapid growth can sometimes translate to high pressure, I’m constantly grateful to be here alongside the inspirational people that I look up to in every way on our journey to make a difference.” – Bianca Butler, Marketing Associate “With nearly 4 years in brand strategy, I’ve been fortunate enough to work on brand building challenges in luxury retail, FMCG and, more recently, consumer technology. Working across categories has given me a varied and colourful marketing perspective, but I was looking for a role that would take me to the front line of marketing, a position where I could have a daily impact and to be in a team where we feel ownership over the brand we build. Tessian has been exactly that. The work is dynamic, immediate and tangible and gives instant results. Tessian manages to gather incredible minds from an endless range of interesting backgrounds. It’s a pleasure to work in such an energetic environment, and the excitement and dedication is infectious.” – Karina Ferdi, Marketing Executive “Before joining Tessian I helped run CyLon, a cybersecurity startup accelerator in which Tessian participated. I worked with the then-5-person team for a year and a half. After I saw the team leave the office one day to play rounders after work, I knew I wanted to join the team. As reductive as that may seem, it represented a culture where everyone was not just part of a company, but also a friendship group. I finally joined in December 2017, as the company’s first designer. What I instantly saw was where there could have been an informal division between the commercial and technology, there was respect. Everyone buys into the same vision and believes we are building something game-changing. Over the last year, my design journey has been incredibly diverse. I’ve been part of the company rebranding, have created exhibition stands and even outfitting our 11,000 sq ft office.” – Shane Wickramasuriya, Design and Brand Lead  

At Tessian, our engineering teams work to ensure that our backend systems have the capability to handle the workloads required by our clients. We do this in lots of industry-standard ways: continuous integration pushed to a continuous-use staging environment, unit and module tests, integration tests and high-load simulations. On the Node.is team, we needed a load testing service which could replicate email traffic above and beyond the 9 am problem (when everyone logs on at work and sends replies to their emails received overnight). Off-the-shelf load testers are typically designed for REST API traffic  —  hitting a server with http(s) requests until it breaks. We needed something smarter. Something that could generate high network traffic and still have the capacity to hold a responsive SMTP conversation for each connection. Like all good engineering projects, we began with the simplest of setups: using swaks to generate and send emails (the source) and a simple instance of Haraka (an SMTP mail server) running on Node.js to receive the traffic (the sink). Running the source and sink on separate AWS compute instances gave us a trivial-to-setup, rampable load tester. Executing swaks on a single core can generate and send around 27 emails/second. Coding a simple bash script to launch swaks processes across dozens of cores (AWS compute instances can give you up to 72 virtual cores) should have provided us with a cool 27 x 72 = 1944 emails/second. Of course, it didn’t. There are some basic overheads in this simple setup. Swaks is a perl script, so each time a message is sent, a new perl process needs to be started, the script interpreted and the process terminated. On the sink side, Haraka does quite a lot of processing of each email it receives — parsing the headers and message body, checking address formats and so on — none of which we really needed for our purposes. The overall throughput came out at around 450 emails/second. Not a bad start, but we felt like we could do better. First we replaced the Haraka sink with a much simpler Node.js server. We coded a net.Server instance and implemented responses for the 4 basic SMTP commands: MAIL FROM, RCPT TO, DATA and QUIT. We didn’t include any validation of the received data — we run different tests for that — because we wanted pure performance. The server recorded various statistics along the way (clock time, data transfer rate, active connection numbers, etc) and console.log()’ed them out each time it received an email. In its entirety, the completely functional (but not exactly RFC-compliant) Node.js SMTP sink server was coded in just 9 functions and 200 lines. Back to the test. Re-running the 72-core swaks script with the new Node.js sink didn’t do much to help the maximum rate with small messages (which still peaked at around 450 emails/second); it did, however, make a big difference with larger messages. By losing the message parsing on the sink side, Node was able to make full use of its multi-connection network streaming capability and keep the maximum incoming rate for multi-megabyte messages. Looking at the server load figures, it was clear that the sink server was busy — but not too busy. The numbers of active connections were averaging just 6 with small bursts into the dozens. Time to focus on the source. Coding a new Node.js module to load and send emails over SMTP was simple enough. Around 100 lines of code later, a fully functional sending script, complete with terminal-configurable options to choose the size of message and destination server was built. Firing up an instance of it on a single core achieved a pretty smart 1426 emails/second (10K messages transferred in 7.01 seconds). We then fired up sending instances across increasing numbers of cores until we plateaued at ~4700 emails/second — more than 10x over the first setup. For context, that’s more than our company’s total current internal email traffic over a 24 hour period, squashed down to 1 second. This is one of many reasons we love using Node.js; its ease and efficiency in handling high-performance network connections is unrivaled, and without it, it’s difficult to imagine the lengths we’d need to go to in order to achieve simple high-throughput load testing of our email servers. Of course, the load tester is still being worked on (there’s more to squeeze out of it), but for now, we’re pretty happy with its performance.       #engineering