Human Layer Security Tessian Culture
Why Customer Centricity is So Important At Tessian
By Samantha Holt
27 August 2020
We believe this whole-heartedly at Tessian. That’s why we’ve made Customer Centricity one of our six company values, and why we’re making it – along with being Human-First – our focus going into Q4.  So, what does “Customer Centricity” actually mean?  It means that our customer’s success doesn’t sit with one functional team. Instead, it’s the entire company’s responsibility. It’s embedded into every role, across every team. It’s a part of Tessian’s company culture. Whether we’re launching a feature, or pursuing a partnership, we always ask “How does this help our current and future customers?”  Keep reading to find out why customer-centricity is more important now than ever, what we’re doing internally to ensure we’re being guided by this value every day, and what we learned from Nick Mehta, a guru of Customer Success and the CEO of Gainsight, during his live discussion with Tessian CEO and Co-Founder, Tim Sadler.  Why are we focusing on customer-centricity now? It’s been a tumultuous few months for businesses around the world which means that two of our values are especially relevant: Customer Centricity and Human First. They go hand-in-hand. Nick explained why.
Instead of just looking at the effects of COVID-19 and the economic downturn from our perspective, we’ve stayed laser-focused on what our customers are going through. The ultimate question that we’ve asked ourselves – and will continue asking ourselves – is “How can we best support our customers through this period?” How can we help? How can we show real value?  As we’ve said, we believe this is the responsibility of all Tessians. Nick does, too. “It’s not just about the customer success function or customer-facing roles. It’s all roles. Customer Success if about end-to-end customer experience, but everyone in the company touches that. In Finance, part of the customer experience is the invoice you send them and the collection emails you send. Those things matter a lot.  If you’re in Legal, the terms in your contract affect the customer experience. Are they friendly? Are they easy to understand? Even if you’re not talking to a customer every day, you can still look at customer data to help you do your job better,” he said. What are we doing internally to make sure we’re being guided by these values?  Here are steps we’re taking this quarter to show our commitment to our customers: We’re creating a more human experience for our customers. We’ve been thinking deeply about our customer journey during this period, in particular the AE-CSM holdover. We want our customer’s experience to be as seamless – and as human – as possible. This influences how we communicate, when we communicate, and the ways in which we demonstrate value. It all comes back to being human-first and, as Nick said, “treating customers not just as a transaction or a deal, but as a group of human beings”. We’re empowering all Tessians to understand their role in customer success. During our Town Hall, we asked everyone at Tessian to take this quarter to reflect on this question: How does your role impact our customers? We’re encouraging even those employees who aren’t in customer-facing roles to explore the challenges our customers are facing and what we can do to best support them. We’re also kicking off a Customer Success Book Club. Our first pick? Nick’s latest book “The Customer Success Economy”. This way, all Tessians can understand how to apply customer-centric principals to their specific role.  We’re immersed in customer feedback. We are taking the time to find even more ways to communicate with our customers during COVID, even without face-to-face meetings. We want to make sure we understand – at all times – how their priorities are shifting. That way, we can anticipate their needs and continue delivering an amazing customer experience. We’re setting company-level OKRs focusing on Customer Centricity. While creating all of these initiatives and putting them into action are steps one and two, we have to somehow hold ourselves accountable. That’s why we’ve set company-level OKRs. Now, individuals, teams, and entire departments across Tessian have goals set around Customer Centricity. These will be reviewed throughout the quarter to make sure we’re always demonstrating this value and putting our customers first. The bottom line is: We’re guided by our customers and we want to support them today and in the future, wherever and however they’re working.  What can other organizations do to make sure they’re focusing on their customers? COVID has impacted all of us and while customers are certainly looking for value, they’re also looking for a human touch. Empathy goes a long way. Here are some questions to reflect on: How can we break down silos in our company to ensure customers are at the forefront of every decision? In what areas of the business could we show more empathy to our customers, and err away from treating them as a transaction or deal? How can we reach out more frequently and regularly to our customers in a human-first way to ensure we are showing value?
Tessian Culture
Our First Growth Framework – How Did We Get Here?
By Jade Jarvis
21 July 2020
Tessian has just finished building our first-ever Growth Framework for our Engineering team. At the same time, we’ve also introduced Internal Levels to represent different stages of progression and identify key milestones as our Engineers develop and grow.  We see this framework as a guiding North Star for Tessians to trail blaze their own career. Tessian’s values ensure we achieve against the expectations outlined in the framework in the right way, and they are embedded throughout.  Why did we do it?   We’ve had feedback in the past about not having clear progression paths for our current team and – at the same time – it’s critical we understand what “good” looks like at each level for new team members. So, what problems is this new framework going to solve for us?  Our Engineers know what their career at Tessian could look like.  Introducing levels means we can celebrate promotion more formally.  It will support future hiring so we can find the best people to join us.  What does it look like?  There are levels which show the milestones of development at Tessian. As our engineers develop and grow, they progress through these levels.  How do they know what it takes to get to the next level? Well, that’s where our Growth Framework comes in! The framework defines competency clusters which are then broken down into further competencies that outline the  key behaviors expected at each level.  Let us introduce you to our Competency Clusters (and Competencies)
How did we do it?  Our Engineering and People team partnered on this and garnered insights not only from Tessians, but also by exploring best practice in our industry.  We have a culture of collaboration so it was important for us to hear directly from our Engineering team to learn more about their perspectives. We spoke to as many engineers as possible to find out what makes a great engineer and a great framework.  We also reviewed successful frameworks in other tech companies to get a strong sense of what has and hasn’t worked for others.  Here’s a step-by-step of our actions:  Information-gathering  We researched open sources and, by comparing and coding, we found that there are similar core competencies that appear in the majority of frameworks. We whittled it down to seven possible competencies; Craft, Impact, Execution, Leadership, Advocacy, Continuously Improves, and Communication.  Explore workshops  We ran a series of workshops with our Eng leaders to really dig into what’s important for them. In the first workshop, we shared the seven possible competencies and, in breakout groups, we discussed the competencies. We asked ourselves two key questions:  For Tessian: How important is this in helping us achieve our business goals?  For our Tessians: How meaningful is this for individuals in their careers?  We then brought everyone back for a group discussion and shared our thoughts from the breakout groups. As expected, we found there was a lot of cross-over amongst the competencies and what they mean to us.  From this first session, we had two main takeaways:  We needed to ensure that we created clear competency cluster definitions that describe exactly what that competency means to Tessian.  We could chop and merge some of the 7 possible competencies clusters to identify our core competencies.  In our second workshop, we shared our findings and introduced the rescoped and refined competencies. This was where the idea of Competency Clusters with Competencies within them were born.  Our four clusters became: Craft, Impact, Delivery, and Communication.  From this session, we gained better understanding about our competencies, but had feedback that perhaps the names of the clusters didn’t feel quite right.  We wanted our clusters to be action statements, so:  Craft became “Master your Craft” – broken down into Technical Skills, Continuous Improvement and Security.  Impact became “Make an Impact”– broken down into Teamwork, Influence, Accountability and Customer-Centricity.  Delivery became “Get Stuff Done” – broken down into Delivery and Autonomy.  Communication became “Communicate” – broken down into Information and Feedback.  Building the behaviors  At this point, we were in a good place with our competency clusters, competencies, and definitions. It was time to build the specific behavioral indicators that sit under each competency and each level.  We knew from our previous workshops that – while we were getting some really useful comments – it was sometimes quite difficult to capture them all verbally. So, we tried out a live commenting activity. It worked brilliantly and captured the diversity of thought amongst all of our engineering leaders.  We shared the draft framework with our managers before the session. Then, during the session, we asked managers to spend the first 20 minutes making live comments on our Google sheet. Afterwards, and as a group, we went through each of the comments, discussed further, and made notes for action.  Iterations  But, we didn’t stop there. We had a few more manager workshops where we had cycles of gaining feedback > making amends > sharing back.  When we got to what we’d call a ‘final draft’, we asked the wider Engineering team for volunteers to join a focus group to get their feedback. This was an energizing session and was the first time the wider team was able to see the framework and overall, the response was really positive. People really cared about understanding how this tool could be used to support their growth at Tessian. One nugget of feedback that came from this group was that our Competency Framework sounded very formal and not very inspiring, and so, this became our Growth Framework. This really felt like it was more representative of what we want to use it for.  Defining our levels  While we were finalzing our Growth Framework, we were also identifying what levels and job titles would make sense for Tessian. Again, we looked at what our peers were doing (using progression.fyi), so that whatever we landed on spoke the same language as the rest of tech. This also ensures that it’s on par with appropriate expectations in the market so it’s easily comparable with other companies. Testing, testing!  This is arguably the most important part. We had to see if the framework actually worked in practice. We had meetings with individual managers to work through what level each of their team members were currently delivering to. And, to ensure a fair and transparent process, we had a group calibration session to discuss the larger team. In an effort to ensure the same approach was being applied to every assessment, we asked managers to use a traffic light system to review their direct reports against each competency. The traffic light colors indicate: “They are consistently demonstrating this behavior” (green) “They demonstrate this behavior from time to time, but not all the time” (yellow) “They are currently not demonstrating this behavior” (red) Go Live The final tweaks were done, wordsmithing complete, and design decisions made. Finally, our framework was published on our internal Wiki for everyone to view.  All managers had discussions with their direct reports to understand where they think they currently sit against the framework, and we will finalize trial levels over the coming weeks. The word “trial” here is important. We’ll explain more below. What comes next?  Collaboration and shared accountability are critical to our engineering culture at Tessian. So, for the next few months, our team will have what we’re calling “trial levels”. This means that we won’t confirm final levels until we’ve used the framework in practice for a couple of months, and our team has really had the opportunity to see how this works for them before providing feedback. It’s a process! We’re beyond excited to see how this framework will continue to support Tessian to create a world class engineering organization that not only builds amazing products, but that enables engineers to thrive and grow in their careers. Watch this space as we share more news about how this has worked for us in practice and key insights gained!   And, if you’re interested in joining our team, see our open roles here.
Tessian Culture
Launching Plus, A Tessian LGBTQ+ Network
By Leon Brown
30 June 2020
Across continents, the Tessian community is formed of diverse and intersectional people collectively working to secure the Human Layer. But, this month we’re proud to honor the contributions of LGBTQ+ Tessians and the importance of freedom of sexual orientation and gender expression in the workplace. With Human First as a core value at Tessian, 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 humanity is what makes us who we are. That’s why we’re launching Tessian Plus. And, we’re thrilled that within one month of launching the initiative, the group already holds more than 10% of the company — a significant minority and higher than the expected average. The Plus mission Plus is formed around a core mission to:  Ensure an inclusive and respectful environment for all employees Raise awareness of, and represent the views and issues of, LGBTQ+ employees Provide a support network for LGBTQ+ employees Create opportunities to socialize with other LGBTQ+ employees Offer confidential support when needed Provide guidance to Tessian as an employer on policy and how to enhance its diversity strategy What is Plus? Plus is an employee-led LGBTQ+ resource group for anybody identifying as LGBTQ+. The group operates as a “safe space” for all Tessian LGBTQ+ employees to network, socialize, and share experiences behind closed doors. With Plus, we’re proud to create a private community for employees to express their sexual orientation and gender identity. And, by building from the ground-up, we will form a vocal committee of LGBTQ+ employees who can advise Tessian’s leadership on policies+, diversity initiatives, and how to operate as a point of contact for employees experiencing homophobic, biphobic, or transphobic bullying and harassment. It’s important that these channels are private. Why? Because even though we enjoy a culture of general acceptance of LGBTQ+ professionals in the workforce both in the UK and US, keeping the community private and confidential ensures it’s a safe space – especially for those individuals who aren’t as comfortable wearing their identity on their sleeve. That’s why it’s essential that we always work to preserve peoples’ right to decide when it is right for them to publicly disclose their identity.
Why are we launching Plus now? Last year marked the 50th anniversary of the New York Stonewall Riots — a pivotal event in the modern fight for LGBTQ+ rights in the US and worldwide — during which black and latinx trans women led days of riots against police in response to an unlawful police raid on The Stonewall Inn, a bar primarily serving the marginalized LGBTQ+ community in New York’s Greenwich Village. Globally – from the UK Gay Liberation Front, to the Lavender Menace, and to Black Power groups – Stonewall was a symbol of struggle against systemic oppression. In the months that followed, and frustrated with discrimination in the justice system and public harassment from police, LGBTQ+ figures and people of color led the frontline in protests that created an intersectional movement across activist groups that exists today in the form of The Stonewall Foundation. From the following June, in commemoration of Stonewall and for the continued fight for LGBTQ+ rights, a Christopher Street Day Parade was held to celebrate the LGBTQ+ figures and people of color who dedicated their lives to furthering the rights of humans worldwide. This has continued every year since and is why we celebrate Pride Month in June. Though we have made huge strides towards equality for LGBTQ+ communities in the last fifty years, particularly in the UK, with same-sex marriage equality and employment equality — for true equality to be eternally ours, we must use our privilege and right to protest to continue the tradition of Pride Month. This year, of course, is different than years before. Our remote “new normal” has presented a challenge to the typical vehicles for LGBTQ+ visibility. Pride floats are digital, and events are canceled, leaving people isolated from their usual support networks. We must therefore work harder than ever to bring the LGBTQ+ community together, around a core mission of inclusivity and family. So, this June – and as a proud Tessian LGBTQ+ community – we are coming together to celebrate the contributions of LGBTQ+ Tessians and support freedom of sexual orientation and gender expression worldwide and form the Plus employee resource group. We’re providing LGBTQ+ Tessians with a safe space to socialize, celebrating LGBTQ+ history, and sharing experiences within the LGBTQ+ community.
Tessian Culture
Our Journey To Revamp The Tessian Values
By Tim Sadler
11 May 2020
As a founder, I knew from Day 1 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.
Tessian Culture
Safely migrating millions of API requests
By Andy Smith
10 March 2020
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 Culture
Data Science at Tessian is all about Passion And Curiosity
13 September 2019
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
Tessian Culture
Introducing Catapult: Tessian’s Very Own Release Tool
30 June 2019
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
Tessian Culture
#TransformTheFuture: Celebrating International Women in Engineering Day
21 June 2019
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. I wish I could have Lego Mindstorms or Kano PC when I was growing up! 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
Tessian Culture
Building a Bold and Beloved Brand
By Kelli Hogan
12 December 2018
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  
Tessian Culture
Building an Email Load Tester in Node
01 April 2018
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
Page