Moving Fast and Scaling Things: Signal Sciences

These days, successful companies grow incredibly fast, and tough challenges can often come up with both the way we build software and the way we build our teams. Nobody knows this better than the people who lead technology teams.

We sat down with Hala Al-Adwan, VP of Technology at Signal Sciences, to discuss their product, how their team has grown (they’ve tripled in the past two years), and how they’re using the best tools available to realize their company’s vision.

This interview has been edited and condensed for clarity.

Aaron Upright: Can you tell us a little bit about Signal Sciences? Tell us about your vision, how DevOps has become really important for companies of every size, and how that fits with your vision.

Hala Al-Adwan: The need to build and deliver applications rapidly, get feedback from customers, and then quickly iterate means that agile methodologies can no longer just be around the development lifecycle, they actually have to be across the entire technology lifecycle. DevOps brings agility into the operational aspect of the entire technological stack.

When you introduce agility into an infrastructure which was a lot more rigid previously, there is always the concern about introducing vulnerabilities because you are moving so quickly. Signal Sciences was conceived by our founders while they were at Etsy, because they were moving into the “DevOps in the cloud” realm really quickly. They needed a toolset to protect their web applications, APIs, and microservices; a tool that not only protects you, but also empowers you to see what’s going on in your applications, and act rapidly to secure your vulnerabilities.

We work closely with tech teams that have DevOps in the cloud to make sure they’re able to still stay secure while moving as rapidly as their business requires them to.

Aaron: Building your technology team is obviously a big part of the success of your business. How do you approach designing your technology team?

Hala: You need to be adaptable and deliberate. One thing I’ve learned is that there is no one-size-fits-all when it comes to how you design your technology organization. Even within our company, things tend to change pretty frequently.

In the last two years, Signal Sciences has more than tripled in size, and our technology team has quadrupled. Our organizational structure changes very frequently, and it changes to meet the needs of our business and the needs of our team.

What’s most important is to understand your company goals, business goals, and the people on your team. If you have a handle on those things, it’s a lot easier to think about how you want to approach your organizational design.

And as the team grows, with every new person that we add, the dynamic of the team tends to change, so we have to flex with these changes while still maintaining our core principles of transparency, accountability, empowerment, and visibility.

Aaron: What challenges have you faced as you’ve grown?

Hala: When we first started the company, the majority of our technology team was remote, and that was perfectly fine. We were small, we were scrappy, we were building the product and innovating on it pretty quickly. And at that time, everybody had an area of ownership, and they just ran with it.

As we started growing, the team grew both remotely and locally in Los Angeles, where we’re based. Part of the challenge was finding remote people who are independent while working remotely, who could also communicate and advocate for themselves.

Working remotely isn’t just a matter of being able to log into your computer and do the work. It’s actually being able to solve problems, communicate, and resolve things remotely. It is important that you are comfortable advocating for yourself. So finding people with the right technology skills as well as those soft-skills was one of our biggest challenges.

Then as the team started to grow, people began taking on more ownership, and we had to figure out the best way structure who owns what, in a way that empowered our engineers to own their functions of the stack.

Aaron: What processes or tools make it possible to work with remote employees, maintaining visibility and communication?

Hala: We aim to define a vision and goals for the individual so they have clarity around what they’re supposed to implement and execute. If there is ambiguity around their role, it’s really hard for them to execute, and it requires a lot of back and forth.

For us, communication tools are incredibly important. We use Slack for our day-to-day communication, and then we use Zoom for video conferencing. We also rely on the right tools to help us manage our projects and the tasks that are involved in them. We use GitHub as our primary code repository, but we also use GitHub Issues for tracking bugs and for all our project management as well.

We use ZenHub as our project management tool on top of GitHub, which has really empowered us to introduce the right levels of agile methodology depending on what the team needs. The tools we use need to be lightweight, so that we don’t introduce another path that an engineer has to go through.

Some of our teams follow a Kanban-style approach to the tasks and projects they work on, and ZenHub lets us to do that. We also have teams that are Scrum-oriented, where they have weekly meetings, they plan their week, and they estimate what they can accomplish in that week. ZenHub allows us to do that too.

Aaron: That’s great! Let’s talk about methodologies for a second. You mentioned that some of your teams use Kanban-style, and some use agile. How do you make that choice?

Hala: I think the key is just to provide the right tools, encourage the framework, and allow the teams to choose what is going to make them most successful.

Our technology operations team, which includes DevOps as well as our IT teams, use a Kanban style. The nature of their work tends to be very interrupt-driven and there are many small tasks that pop in all the time, so Kanban-style just works for them.

Our feature development teams use a weekly Scrum, where they meet, they discuss the goals of that week, and then, they break that down into tasks. We’re still working through the best way to estimate and be able to accomplish all the goals that we have in one task, but we’re getting there.

Aaron: How often does your team ship new versions or new features? Do you have a desired pattern that it follows or does it tend to follow your overall roadmap?

Hala: We try to ship as quickly, in as small a component as possible, across the board. That’s really important, because it allows us to deliver new features and product enhancements to our customers as quickly as possible.

We utilize the feature flag methodology, so we’re constantly deploying small changes but that doesn’t mean they’re turned on for everybody. We have what we call our deployment lifecycle, where we ship continuously. As soon as something is done, it’s checked in, reviewed, and then it gets deployed. When we feel that it is ready from a product delivery perspective, we are able to feature flag it on for a portion or the entire set of our customer base.

Aaron: Since you ship so frequently, how do you approach CICD and how do you introduce automation into your workflow?

Hala: We’re not as perfect as I would love us to be, but we have some huge goals that we want to accomplish. In my mind, if an engineer is doing something more than once, it should be automated. And that applies across the stack.

Even within our DevOps and infrastructure world, we aim to have everything scriptable and automated. In a perfect world nobody ever logs into a server to do anything; everything just happens in an automated fashion through the toolset that we have. We are a little ways away from that, but that’s definitely the direction that we’re moving.

In terms of CICD, some stuff we have homegrown, like our deployment tool that we built in-house. We use other tools like Jenkins, but the idea is to remove friction from the path of our engineers and to empower the engineer and Ops engineer at the same time, so those are our automation goals.

Aaron: How do you address security internally at Signal Sciences?

Hala: Our company was started by our founders who built these tools specifically to address security needs, so security is part of our DNA. We don’t really think of security as something that we have to think about, it is just part of how we develop, and it’s part of how we do operations. It’s part of everything we do.

Security is everybody’s responsibility. And we actually use our own product to secure ourselves, that’s how much we believe in it.