Posted on

“Proactive Security at Slack”: Suzanna Khatchatrian with Slack (Video + Transcript)

Like what you see here? Our mission-aligned Girl Geek X partners are hiring!

Transcript

Angie Chang: So we have Suzanna joining us — she is a Senior Manager for the Product Security Foundations team and at Slack. She’s built a brand new team within Product Security that’s focused more on proactive security measures by delivering secure by default libraries and services for Slack. So, welcome Suzanna.

Suzanna Khatchatrian: Thank you, Angie. Thank you for nice intro. Hi everyone. Nice to meet you virtually. I’m so excited to be here. Before I start talking about Proactive Security at Slack, I want to also join all the other ladies who spoke before to congratulate you with International Women’s Day. I’m so happy to see that it’s becoming a bigger and bigger event in United States. When I moved to US 25 years ago from Armenia, it was a big event there and it is still there big event, but now I see it getting more and more recognized internationally in this special United States. It’s really special to me, so, Happy International Women’s day to all of you. So as Angie said, I am the Manager for Product Security Foundations Team at Slack, and here, I’m going to talk the next 20 minutes, what we do at Slack in terms of a proactive security measurements especially around product security.

Suzanna Khatchatrian: Quick introduction and background, just in case, we… By the way, I heard lots of great love and feedback in our chat talking about how much you love using Slack, the tool. That’s great. Thank you so much. So, in case of some of you never heard about Slack, quick intro. Slack is basically a collaboration tool that makes your work life much simple, much pleasant and much productive… And more work life, meaning not just your corporate work, it can be anything to do with nonprofit organization, your fun activities, you are planning to do something with your friends and the use cases go forever. So basically, it’s an amazing collaboration tool to make your work done, right? And what we do here in the Slack security team, we want to make sure that we keep that tool for you to be safe, secure, and make sure that your data is safe with you. So basically, we are providing the collaboration platform to make sure that everything, what you do, it is Slack secure and pleasant.

Suzanna Khatchatrian: And what’s our strategy? We provide lots of best spoken reviews, we do lots of automation, ongoing education and production ready components. Basically, anytime we release something for our engineers to start using it and I have a use cases to go through one by one how we do that. Before that also quick history. Today… This year, we are celebrating Slack’s seventh anniversary and as we celebrate Slack’s seventh anniversary, we also have a great history of the security, right? So first actually security, the way it launched our first security engineer was our CTO, Cal Henderson. In 2014, he basically aligned the Bug Bounty program for Slack via HackerOne and he was the first person who was actually triaging the security issues. And then in 2015, as the Slack was growing, they hired the first Engineering Manager who basically started putting plan together and charter for the product security.

Suzanna Khatchatrian: He started hiring more engineers and doing some basically other automations around security development life cycle. As Slack start growing and team growing, in 2018, the current Director of Product Security, Larkin Ryder, took the ownership of the Product Security pillar and she realized that as we’re exponentially growing, we need to make sure we put more measurements in our proactive security, so it’s important to have our traditional product security components in place, such as reviewing, providing consultations, providing some scanning and automations, but we need to make sure that we also look for classes of vulnerabilities and come up with proactive measurements. With that, they hired me in the late of 2019. They hired me as a founding manager for Product Security Foundations team.

Suzanna Khatchatrian: So, what is Foundations team? Just a quick thing is, as I mentioned, we are basically building secure by default libraries and services. We’re providing future proof for Slack, the product, and how we do it, we basically write the code as any other development organization, and we work with other engineers to make sure the code is utilized and used safely by our engineers.

Suzanna Khatchatrian: And how we decide to what kind of work we want to work, what classes of vulnerabilities we want to address. So that’s pretty straight forward. In the beginning, obviously we wanted to make sure that we look at our code base, we understand our potential big classes of vulnerabilities and figure out the best approach, how to build new libraries and services.

Suzanna Khatchatrian: As the team became bigger, as our services became more mature, we also done lots of data analysis, gathering lots of interesting information so to make better data-driven decisions such as our incidents that our back boundary reports, our data that comes from our tooling automations to better understand the classes of vulnerabilities and come up with ways how to solve it and we also marrying that with OWASP top 10. So OWASP top 10, which is The Open Web Application Security Project, those are the known vulnerabilities and we wanted to make sure that we have the right services and libraries to address those issues. And obviously, sometimes also customer demands come our way too, but we’re not feature-facing team, we are more backend team basically working on a future proof and that’s why we are not doing lots of… We don’t have product management working with us, basically we act as a product manager for our team.

Suzanna Khatchatrian: But with that, we also use Slack’s design principles. The most important things, which is very… To make sure that we align with our organization, same way as other engineering teams do, we want to make sure all the libraries and services we’ve write, they don’t make… They are very simple and engineers don’t have to think how they code the service or the library. It has to have great serviceability components in terms of, for us, making sure that our reliability is always up and we don’t want to boil an ocean, we want to make sure we have small, rapid development, prototype the way, do the experiments, learn from it and then move on.

Suzanna Khatchatrian: And most importantly, especially in the security team, we don’t want to reinvent the wheel. If there are all these tools and services there that we can reuse, we definitely going to do it instead of writing from scratch on our own. And the biggest one I want to highlight is the take bigger and bolder steps and that’s basically figuring out like, what can we do? Maybe something that we can invent, we can put lots of efforts to, but if in return we’ll get lots of great benefits securing our product.

Suzanna Khatchatrian: Okay. So as I mentioned, I’m going to talk about the top OWASP top 10 vulnerabilities that we’re trying to prevent with our new secure by default libraries and services. The first one I want to talk about, Broken Authentication and Broken Access Control. That’s a big one. Authentication is very important. It’s also scary. We need to make sure the right people are authenticated to our platform and we make sure that people don’t automatically get these and get reset their passwords or get their password to get stolen or hacked. So what we do, so, first thing about our Crypto library, that was actually the first library that we released for the foundations team. And the… Basically the purpose of this, we know cryptography is very complex, it’s very challenging and we don’t want our engineers, backend engineers, to think about like what type of hashing algorithm to use or what type of encryption algorithm to use.

Suzanna Khatchatrian: We want to provide a library with the right help or functions to do all the job for them. So they don’t have to think about it. They don’t have to unintentionally introduce some potential problems and bugs, and that’s how we introduced our Crypto Library. This is a also great example as an impact for our Slack’s Better Engineering Initiative. So basically, what is a Slack’s Better Engineering Initiative? Whenever you go, you touch a code, you leave that code much better and you don’t try to fix it like small thing, you want to fix it up a very bigger way so it can be used for other engineers, much better and much safer and secure way. So that’s the great impact of Crypto Library. We also made sure we have linters so all the new engineers who come, who trying to use the old libraries that have a linter in place, or they know they have to use the new one.

Suzanna Khatchatrian: The next one is about Magic Logins. So what is Magic Logins? Magic Logins is a very… It’s a unique thing for Slack, but also for some other web applications. But for Slack, basically, if you don’t want to use your password and you can use this Magic Login to authenticate yourself. Obviously, it’s a powerful tool, but potentially also can have a security problem. So when we were looking at our code base, we realized that it has some [inaudible] and legacy code patterns that we wanted to fix it and make it better. And that’s what team actually done. So basically first step was reviewing the code, understanding what’s happening and then providing better documentation, providing better test case coverage, and also framework, which will be much simpler and easier for our engineers to use. This was also amazing core foundation for other future authentication hardening efforts.

Suzanna Khatchatrian: Let’s talk about Injection and Cross Site Scripting. The first example, which is like basically a very important project that our team worked on is Magical Images. So what this does basically, anytime you go to Slack, you upload a video, you upload any type of image, right? A PDF file, your Excel documents, et cetera. It going, it is going to thumbnail that image or that document and basically it goes through Image Magic Library, which used to be called directly in our webapp. So what our team has done, basically, isolated that call to a separate service. That was the brand new service that the team put together last year, beginning of last year. And that was right before we ended… Like we were entering the COVID era. Basically everyone started using Slack, so the usage of slack was exponentially increasing.

Suzanna Khatchatrian: And that was even more scarier to make sure that our brand new service scales and doesn’t produce any serviceability issues and definitely, we didn’t want to make sure we produce any type of outages. So, amazingly, as we launch this service last February and March, it was already in full protection, especially whenever you are uploading files and thumbnailing and we had zero incidents. And the reason why, because the team really put lots of efforts, making sure we had extra test case coverages, making sure we have feature flags and making sure we are going to the production on gradual steps. So right now the biggest impact is basically, we’re processing approximately 300 requests at the peak and image thumbnailing, or any other forms, and which is equivalent to 15 million requests per day. What it does, it dramatically reduces security risk when you are thumbnailing images.

Suzanna Khatchatrian: So what HTML Sanitizer does, basically, whenever you go and post a link in your Slack channel or somewhere, it unfurls the information. So that unfurling basically it has HTML tag. So our service basically makes sure that all these tags are properly sanitized to prevent any potential Cross Site Scripting or Injection Security vulnerabilities. The good thing about this library was that it actually got open source. So other people can come now to Slack HQ repository and use that library if, especially if they are using Hacklang … And I know it’s not many companies use Hacklang, it’s probably Facebook and Slack, but anyways, so it’s there, you can use it and you can contribute it. And this was our first virtual internship project to basically this done by our interns and if you search, use blog on virtual internship at Slack and security, you’ll find all the details about this project and how this project was impactful and meaningful for our interns who are coming back as full-timers to Slack and work for our team this summer.

Suzanna Khatchatrian: Sensitive Data Exposure, that’s another very important security type of vulnerability that, especially with GDPR that came in two years, couple of years ago, and the California data privacy act, European data privacy acts. We know we need to make sure that our customer data stays with them and secure and logs obviously are very powerful tool for our engineers to understand if something goes wrong, but we want to make sure we don’t unintentionally log something that we didn’t want to log. So sensitive information can be channel names, file names. All these information, we don’t want to make sure they are not in our logs. So basically, we wrote a tool to do that, to detect automatically we unintentionally log this type of data and we make sure that it is out of our serach, we get an alert and we take care of it immediately. And there was an amazing talk about just this project by Ryan Slama, who is the engineer in my team.

Suzanna Khatchatrian: So if you are interested in, he did this talk in the Loco Moco Security Conference, so feel free to go and search and look the details about this project. Security Misconfiguration, that’s another important thing. Like you can unintentionally do lots of mistakes and we want to make sure we detect that. For these type of vulnerabilities, we have tons of tools that we actually purchased, or we use as an open source. So, but I’m using just one example, which is a tool the team wrote. Obviously, Slack is on AWS infrastructure and provisioning process can be very complex. So people can unintentionally, basically, bring their own points without proper authentication.

Suzanna Khatchatrian: Obviously, all our sensitive services are behind authentication services, point authentication, but sometimes for some testing purposes, this and that, developers can make mistakes. So basically a range is built to prevent that kind of mistakes because this type of defects we we’re getting from our bug bounty reports all the time, the reports coming… So the bug bounty researchers, this was the easy way, very easy way to detect and find the open end points without proper authentication and we were giving lots of bounties to the researcher, so this was… We knew if we put the tool together, we can easily fix this problem.

Suzanna Khatchatrian: Okay. So the last one I want to quickly talk about, Using Components with Known Vulnerabilities. Again, this is… I’ll talk a little bit about Twistlock. So Twistlock is a tool we purchase from Palo Alto Networks, which basically scans for vulnerabilities in our Kubernetes infrastructure and we didn’t want to invent, we knew, we actually spent lots of time putting pros and cons of all the existing tools there in the even open source, free tools that we can use and we came out with the Twistlock, which provides amazing infrastructure. It provides good reporting that we could easily integrate to our CI pipeline and make sure that we have our infrastructure, Kubernetes infrastructure, without a third party vulnerability. So as we launched this product, we already found dozens of vulnerabilities that we prevented, right? Which could bring buffer overflows or Denial of Service attacks.

Suzanna Khatchatrian: Ossify is another tool. This is another internship project was done on vulnerabilities, but this was the vulnerabilities in our code libraries, not the infrastructure. So this was internship project done by our interns, two summers ago. Another great conference talk about that, 10,000 Dependencies Under the Sea. So I will highly encourage you to go look at it. This was taught, presented at DevCon last summer and with that, I know I only have one more minute. So I just want to say, okay, what’s next? What we are planning to do. There are still… We’ve, all the tools that I talked about or services libraries. It’s like probably 50%. We’ve done more than that. But I wanted just to highlight a few key of them and the most important thing we want to continue our working on the project that produce big impact.

Suzanna Khatchatrian: So we want to harden our authentication, authorization, code base, or we are working on the 2FA hardening close right now and client hardening. We’ve been… The first few years, we’re focusing on [inaudible] backend. Now, we want to start to put some focus on the client side from the security perspective and also look for more types proactive security, such as Early Cross Site warning systems and do… Continue our education and evangelism both internally to our engineers in the backend, as well as to the external community and put lots of focus on efforts on Better Engineering, because all the projects for Foundations team is all around Better Engineering, making the code much better, safer, and proficient to use.

Suzanna Khatchatrian: With that, I want to thank you all for your great time and I’ll go and look, if you have any questions, I’ll answer them. Thank you so much and we are hiring.

Girl Geek X Elevate 2021 Virtual Conference

Like what you see here? Our mission-aligned Girl Geek X partners are hiring!

Posted on

“Modernizing Mobile Codebases”: Tracy Stampfli with Slack (Video + Transcript)

Like what you see here? Our mission-aligned Girl Geek X partners are hiring!

Transcript

Sukrutha Bhadouria: Tracy’s a senior staff engineer at Slack. Prior to Slack, Tracy worked at Adobe for many, many years, specializing in client networking and support for streaming audio, video, and screen sharing. Tracy lives in San Francisco with her husband and two kids. Welcome, Tracy.

Tracy Stampfli: Yes. My name is Tracy Stampfli. I’m a senior staff engineer at Slack. I lead the iOS infrastructure team. iOS infrastructure basically handles things like networking, and data syncing, and all the stuff that’s a bit under the hood of the app, supporting the UI and the features.

Tracy Stampfli: I’m going to talk about modernizing mobile codebases, but I’m really going to talk about modernizing and refactoring codebases in general. I hope that a lot of this talk is actually generally applicable and not just about mobile.

Tracy Stampfli: I’m going to talk about some things we’ve learned from doing a rewrite, or at least a partial rewrite, of both our iOS and Android codebases at Slack. Why did we think this was necessary? What decisions did we make about how to rearchitect our code? What has made this successful, at least so far? It’s still in progress.

Tracy Stampfli: Why did we decide to do this? Well, Slack’s mobile codebases had not really had a big rewrite or refactor in a long time. Slack’s been around for about seven years, and on iOS, we hadn’t actually done a refactor in that entire time, or a major refactor. Android had done one about five years ago, but that’s still a while.

Tracy Stampfli: Both of these codebases had a lot of tech debt. They had a lot of obsolete design patterns that didn’t match up with how we do things now. There were a lot of inconsistencies, you know, five different ways to do the same thing.

Tracy Stampfli: That made it really confusing for new engineers and hard to onboard, because it was hard to figure out what the right way to do things was. The code was fragile and too tightly coupled, which made it easy to inject bugs.

Tracy Stampfli: All of these things added up to slow down feature development. That became a really big problem. Mobile development was starting to be a drag on feature development in general at Slack. That was something we knew that we had to tackle and do something about.

Tracy Stampfli: We decided we really needed to prioritize addressing this tech debt, and invest in more modern architecture, and improve our development practices to speed things up.

Tracy Stampfli: Where deciding how to do this, there are a number of options. We’re going to do a big refactor, so how are we going to do this? We considered a few things. We could do just a full rewrite of our mobile apps. There’s some nice aspects of that. You get to just toss out the legacy code and start afresh, new project, just start going with new patterns, do it the right way that you’d like to rewrite all the features.

Tracy Stampfli: But obviously, there’s some risks with this as well. If you’re going to start from scratch and just fully rewrite the app, you have to bring it all the way up to feature parity with your existing code. For a product like Slack, that’s been around for a long time and has a lot of features, that’s going to be a really massive task.

Tracy Stampfli: While you’re doing that, you have to maintain two codebases. You have to keep the new codebase … There’s going to be feature development going on, so you have to be doing dual feature development in the old codebase and the new codebase.

Tracy Stampfli: Overall, this is just a very big, risky bet. What happens if you don’t ship that new, modern codebase for some reason? You’ve wasted a huge amount of work. We decided this was a bit too risky for us.

Tracy Stampfli: We considered some other options. When you talk about speeding up mobile development, one option that comes up a lot is sharing code. There’s a number of ways to do this. We could share code between iOS and Android. We could share code between the mobile apps and the desktop. There’s different frameworks for sharing code. You can share UI code or business logic. Slack actually tried to do some shared business logic a few years ago across the clients. It didn’t actually work out too well.

Tracy Stampfli: There are, again, some benefits here. Obviously, there’s this benefit of not rewriting the same feature or the same logic three times, or however many clients you have. You can also, hopefully, maybe share some developer resources across platforms if you go this route.

Tracy Stampfli: But there’s also, again, downsides. Shared code complicates your tooling. It makes things like just debugging, building the CI system … All of those things become more complicated. Also, the big danger is that, if you share code, you might lose native look and feel or native performance. This is a big issue for mobile.

Tracy Stampfli: We really want to take advantage of the latest and greatest features that each of the platforms has to offer. We want our iOS apps to feel like great native iOS apps, and same with Android. We want performance to be great on our mobile platforms. This was something that we were definitely worried about.

Tracy Stampfli: Also developer sentiment about this idea was just not very good. Our developers were just not excited about doing shared code. If the developers aren’t excited about it, it’s unlikely to be successful.

Tracy Stampfli: What’s left, basically? Well, you could refactor your existing codebase in place, essentially rebuild the airplane as you’re flying it. This is the option we ended up going with. There’s some, again, benefits and downsides to it.

Tracy Stampfli: Benefit. Reduced risk. We were basically having to refactor and ship this codebase continually. We just have one codebase, so at any given point in time, it always has to be shippable, because we have to keep releasing it.

Tracy Stampfli: We get faster payoff, because as we’re modernizing that codebase, it is continually being improved, and everyone working on the team is getting the benefit of that improved codebase as we go along. We don’t have to do this dual codebases, try and develop things in both thing, which seems very challenging.

Tracy Stampfli: But it does mean that we don’t get to just get rid of our legacy code. We have to actually deal with it. We can’t get rid of the tech debt. We have to migrate and rearchitect our existing codebase.

Tracy Stampfli: We launched this thing called Project Duplo. You may have noticed, there’s a Lego Duplo theme to this presentation. That’s because, as I’ll talk about a bit more later, one of the big themes of Project Duplo was modularization, or breaking down the codebase into smaller building blocks. Duplo are the larger Lego bricks, so yes, basically a big theme about breaking down the app monolith.

Tracy Stampfli: This was a big rearchitecture of both of our mobile code basis that we launched a little while ago. It was coordinated across both mobile platforms. iOS and Android came up with proposals together, did an investigation together, scoped this effort together. We’re now running the project together. This was all a coordinated effort.

Tracy Stampfli: The goals were, number one, improved developer velocity. Start shipping features faster. But also adopt modern design patterns, bring some of the patterns in our app to more in keeping with current mobile development practices.

Tracy Stampfli: And really enable larger teams. Obviously, the mobile teams of Slack have grown a great deal since the company started. We hope they’re going to grow a bunch more. The patterns that work for smaller development teams don’t necessarily work for a team of 40, and what works for a team of 40 may not work for a team of a hundred. So we really wanted to enable our growing development team.

Tracy Stampfli: And also set us up to adopt future technologies we might be interested in. Like right now, we aren’t actually using SwiftUI, but we might want to in the future. We want to have an architecture that keeps that door open, and allows us to have that possibility.

Tracy Stampfli: This project had three phases. The first phase we called stabilization. The idea here was to complete a bunch of ongoing migrations and refactors that we already had in flight, things that we’d started, but then didn’t have the resources to finish. Again, that was really leading to inconsistency, so we wanted to remove the worst of the tech debt, the worst of the anti-patterns, and just clean the codebase up to set us up for the rest of the project. This phase had very well-defined work streams and really clear metrics for success, so we really could track our work very well.

Tracy Stampfli: I’m not going to get too deep into the details of what we actually did on each platform, due to lack of time. But this is just some highlights of some of the top goals on each platform.

Tracy Stampfli: On iOS, we wanted to move to being 100% Swift. We were already about 80% before this project started. And we wanted to finish some migrations onto some of our infra frameworks. Similarly on Android, you’ll see these common themes of finishing migrations, finishing adoptions of different patterns and different frameworks, and breaking down some of the infra frameworks to be more usable.

Tracy Stampfli: The second phase here was modularization. Here, we’re getting into the building blocks. The idea here is that we had already somewhat modularized our code. We had on both iOS and Android. We had some code that was split off into frameworks, but we wanted to go a lot further in that direction, because there’s a lot of benefits to this.

Tracy Stampfli: By breaking the code apart into smaller frameworks, and breaking up that big app target, you reduce interdependencies, you remove this tight coupling between features that can make things more fragile and introduce bugs. You enable …

Tracy Stampfli: You have to have separation concerns, because you’re actually separating the code out. This enables developers to work better, independently from each other, and also improves the build times, because if you’re building your feature in a framework, as you make changes, you only have to rebuild that framework and not the entire app target.

Tracy Stampfli: The third phase was modernization. This is the one where, again, we’re really trying to look forward and think about what architecture patterns do we want to adopt that will make us compatible with current industry trends, but also will set us up for the next five years of app development.

Tracy Stampfli: We got into this project. As we got started and were going through the stabilization phase, we realized that actually this whole three phases thing wasn’t such a great idea. We realized that we should actually combine our three phases back down into two, and combine the modularization and modernization phases, because we realized that, if we’re doing these separately, you would refactor some code to split it out from the app, then modularize it, and then you would refactor it again to modernize it. That was going to entail a lot of wasted effort. To avoid refactoring things twice, we combined these phases and just made it a two phase project. So now it’s just stabilization and modernization.

Tracy Stampfli: As we were deciding what we were going to do for our modernization, and trying to decide what patterns we should pick, we did a lot of research with our developers, talking to our developers, doing focus groups, doing polling, trying to figure out what are the current pain points, and what did developers want to see out of this project. What did they really want us to do?

Tracy Stampfli: What we heard from them was interesting, because we didn’t hear that they felt super strongly about one particular feature architecture, or exactly how we did dependency injection. What we heard from them was that they wanted us to increase what you see here, CPR is the acronym we came up with, consistency, predictability, reliability. That was what was important to them, improving these things.

Tracy Stampfli: Consistency. Making it so that all the features all are built in the same way. So it’s easy to tell, if you look at another feature, that is built the same way the other ones are, the ones that you have built. So you’re familiar with the code. It all works the same way.

Tracy Stampfli: Predictability. Making things like routing and deep linking understandable. Making sure that the code actually works the way you think it’s going to work. Removing unintended effects where making a change somewhere in the product for some reason breaks something somewhere else.

Tracy Stampfli: Reliability. Again, making the code less fragile, so we’re spending less time on regressions and incidents and things like that.

Tracy Stampfli: So this was really what we wanted to focus on. How do you do that? Well, we realized that if we wanted to increase consistency, we couldn’t just do that by coming up with some feature architecture pattern and expecting every developer in the team to implement it exactly the same way. You can’t just hope that it’ll work.

Tracy Stampfli: You have to enforce these things through things like templates, and linting, and code generation, and basically making it very easy for developers to know what the right thing is to do, and to do that, and much harder for them to do things that we don’t want to do, and re-introduce inconsistencies and anti-patterns. If we’ve decided we don’t want developers to use singletons, we need to add a linting rule that actually prevents that, versus just hoping that they won’t.

Tracy Stampfli: What did we end up deciding to as our main goals for modernization? Again, not going to get very deeply into this, but on iOS, this big push to break down the app into, again, service and feature modules. So increased modularization. We did decide to adopt a new feature architecture that’s VIPER-like. We’re adopting Combine.

Tracy Stampfli: This last one is actually pretty important. We’re switching to using Bazel, which I don’t know if folks are familiar with it, but Bazel is a build system that you can use in place of Xcode or alongside Xcode. It deals better with highly modularized projects, projects where there is many, many frameworks. Bazel handles that pretty well. It also has a build cache, which means, hopefully, again, we’re going to see improved build times, both locally and in CI, by having a better caching of build artifacts.

Tracy Stampfli: On Android, again, similar themes. Completing modularization on that side as well. Adopting some new frameworks and libraries to do things like networking, and JSON parsing, and configuration changes. And building abstractions around startActivity and onActivityResult.

Tracy Stampfli: Why has this project been successful, or has it been successful? Well, we started off with the stabilization phase. All goals of that phase were completed on time for both platforms, 100% completed everything. So that was certainly successful.

Tracy Stampfli: We are now in the middle of the second phase, the modernization phase. That’s still in progress, so there’s a bit of a caveat here. We’re on track, but there’s still a ways to go. But we’re successful so far.

Tracy Stampfli: Why has this been successful? Number one, it was an engineering-led initiative with executive prioritization and resourcing. I think both of these things were really important and really key to the success.

Tracy Stampfli: This has really been an engineering-driven, IC-driven driven project. It was engineers who came up with the initial proposals, who did the research, who figured out what the problems were and how that we should solve them, and who came up with all of the scoping and projects and proposals that have led to what we were actually doing as part of the project. So very much not a top-down project.

Tracy Stampfli: It was very much driven by engineers. But it had executive prioritization and resourcing, which is equally key. This isn’t something that you can do as a side project. It really needs dedicated resources. It needs executives to sign onto the fact that we’re going to do this in place of doing something else, in place of doing feature work or whatever. So we have to have that buy in that this is the right thing to do, and we’re going to get the resources to do it properly.

Tracy Stampfli: Along with that, sponsorship from key engineering leaders outside of mobile helped us get that buy in. We had principal engineers and key managers who were willing to say, “Yes. This is super important. This is the right thing to do. We need to do it now.” That helped us get this backing that we got to actually do the project correctly.

Tracy Stampfli: Additionally, splitting the project into a couple of phases was really helpful, because having this initial stabilization phase, we just knew what we had to do. We were getting rid of tech debt. Things were really well-defined. We just had to execute on it. That gave us time to do R&D for the later phase.

Tracy Stampfli: So during the stabilization phase, we were able to do the investigation, and the prototyping, and figure out what should we do for modernization, and make sure that we had all of those things set up, and all of our scoping and all of that by the time we hit the modernization phase.

Tracy Stampfli: Finally … This one is very, very important. This has been a very metric and data-driven effort. We really wanted to have very clear metrics to measure our progress, what we’re doing, how successful we’re being. It wasn’t just tracking with Jira or whatever. We were actually running scripts on every file in the codebase to track, how are we doing with these migrations, what progress have we made, where are we. We had a lot of dashboards and graphs.

Tracy Stampfli: This is an example of one of … For each of the goals that we had, we would have a dashboard saying where are we with this in terms of progress on this measure. That allowed us to do things like see if we were falling behind or we’re doing fine. We could switch resources between different work streams if we needed to, if one of them wasn’t doing as well.

Tracy Stampfli: On this particular graph, you could see it doesn’t quite go to zero at the end. That was because we had ported the code to Swift, but some of it was still behind feature flags, as we were rolling out those feature flags when this snapshot was taken.

Tracy Stampfli: But basically, this was very, very helpful for the initial phase of the project. We are continuing that in the modernization phase. We’re really trying to come up with very clear metrics for each of our goals, so that we can track it and see that we are being successful. That enables us to do resourcing planning and all sorts of things that are very, very helpful for the success of the project.

Tracy Stampfli: That is the end of my presentation. If you have … I don’t think we’re going to have time for questions, but feel free to reach out to me. I’ll try to respond in the chat if folks have questions. Feel free to connect with me on LinkedIn if you want.

Tracy Stampfli: Also, as other folks have mentioned, Slack is also hiring. We’re hiring on the iOS team. We’re hiring on Android. We’re hiring on other teams as well. If you’re interested, please check out the careers page at Slack.

Girl Geek X Elevate 2021 Virtual Conference

Like what you see here? Our mission-aligned Girl Geek X partners are hiring!

Posted on

12 Product Design Leaders To Follow In 2019

Love building digital products with amazing user experiences? Product Designers as a job title has blazed a trail in tech for the past decade with the rise of Facebook VP of Design Julie Zhuo leading the industry.

We look to Product Design leaders at companies of all sizes to find insight in their careers and map the rise of Product Design as a profession. Lucky us — many of these leaders speak publicly, tweet and share their expertise and thought leadership.

Here are 12 Product Design Leaders to Follow in 2019:

Christine Fernandez – Stitch Fix VP, Product Design

Christine’s Proudest Moment: “There’s so much work that I’m proud of, but my biggest accomplishment is definitely the teams I’ve built over the years, and helping some of the best designers I’ve had the pleasure to work with grow into leaders. Design now has such an important seat at the table – at the executive level, in boardrooms, and shaping the future at the most innovative companies. It’s been quite a journey, and I’m so grateful to have been a part of leading that change.”

Christine Fernandez is a Vice President of Product Design at Stitch Fix. Previously, she was Chief Experience Officer at Art.com, Head of Design at Uber, and worked as Creative Director at R/GA, frog, Razorfish, Schematic and FCB. Connie holds a B.A. in Graphic Design and a minor in East Asian Studies from University of Pennsylvania. Follow her on Twitter at @ctfernandez and her product design thoughts on Medium.

Connie Yang – Coinbase Director, Design

Connie’s Proudest Moment: “I scaled a team from 3 to 20 in a year – including establishing the functions of User Research, Product Writing, and Brand Design. I did not expect to do that, nor did I think it was even possible. You never know until you actually try.”

Connie Yang is a Director of Design at Coinbase. Previously, she spent six years at Facebook as a Product Designer. Prior to that, she was a UI Director at Twist and PopCap Games, Art Director at ReignDesign and began her career as a Graphic Designer working in advertising. Connie holds a B.A. in Graphic Design and a minor in East Asian Studies from University of Pennsylvania. Follow her on Twitter at @conniecurious and her product design thoughts on Medium.

Erica Weiss Tjader – SurveyMonkey VP, Product Design

Erica’s Proudest Moment: “Landing this role as VP of Product Design at SurveyMonkey 2 years ago – not only because it’s a great opportunity with an amazing company, but also because this role represents a shift in my willingness to take risks, aim high, and flex my leadership muscles.”

Erica Weiss Tjader is a Vice President of Product Design at SurveyMonkey. Previously, she spent six years at Quantcast as the Director of Product Design, where she was responsible for building the design and research functions. Prior to that, she was an Interaction Designer and User Researcher at Move, eBay and Yahoo. Erica holds a B.S. in Cognitive Science and B.A. in Communication Studies from UCLA. Follow her on Twitter at @ericatjader and her product design thoughts on Medium.

Huda Idrees – Dot Health CEO

Huda Idrees is CEO at Dot Health. Prior to founding Dot Health, she was Chief Product Officer at Wealthsimple. Prior to Weathsimple, she was a Product Designer at Wave, an Interaction Designer at Shaken Media Collective, and an UX Designer at Wattpad. She began her career as a Web Developer. Huda holds a BASc. in Industrial Engineering from University of Toronto. Follow her on Twitter at @hidrees and her product design thoughts on Medium.

Irene Au – Khosla Design Partner

Irene’s Proudest Moment: “I had the honor and privilege to build the industry’s most influential and talented design teams over the last two decades. At Yahoo! and Google, we established the gold standard for user experience and design for the internet that continues to shape the profession in this industry today, and we elevated design’s strategic importance in both companies.”

Irene Au is a Design Partner at Khosla Ventures. Prior to Khosla, she was Vice President of Product at Udacity and build and ran design for all of Google and Yahoo! for many years. She began her career as an Interaction Designer at Netscape. Irene holds a M.S. in Mechanical and Industrial Engineering from the University of Illinois at Urbana-Champaign, and a B.S. in Electrical and Computer Engineering from the University of South Carolina. Follow her on Twitter at @ireneau and her product design thoughts on Medium.

Julie Zhuo – Facebook VP, Product Design

Julie’s Proudest Moment: “Helped Facebook scale from 8 million college students to billions of users worldwide.”

Julie Zhuo is a Vice President of Product Design at Facebook. She started as Facebook’s first intern in 2005, was hired as a product designer at Facebook, and has been working at Facebook for over a decade. She published in 2019 “The Making of a Manager: What to Do When Everyone Looks to You.” Julie holds a M.S. and B.S. in Computer Science from Stanford University. Follow her on Twitter at @joulee and her product design thoughts on Medium.

Katie Dill – Lyft VP, Product Design

Katie’s Proudest Moment: “My great achievement and greatest joy has been the teams I have had the pleasure to build at Lyft and Airbnb. Great things come from great teams, and my focus as a leader has been finding just the right mix of folks that can come together as one to build lasting change. A strong culture full of people that inspire each other and elevate each other’s work is the best thing I have ever built.”

Katie Dill is a Vice President of Product Design at Lyft. Prior to Lyft, Katie was at Airbnb as a Director of Experience Design. Prior to that, Katie worked at frog design for five years, where she began her career as a Design Analyst. Katie holds a B.S. in Industrial Design from Art Center College of Design, and a B.A. in History from Colgate University. Follow her on Twitter at @lil_dill and her product design thoughts on Medium.

Kim Lenox – Zendesk VP, Product Design

Kim’s Proudest Moment: “I have had the privilege to nurture a number of burgeoning designers into design leaders. Seeing how they grow their careers, take new leadership roles and bring their own contribution back to the design community is one of my fondest rewards as a design leader.”

Kim Lenox is a Vice President of Product Design at Zendesk. Prior to Zendesk, she was a Director of Product Design at LinkedIn. Prior to that, she was a Senior Manager of Interaction Design at HP Palm. She has held a number of roles in research, interaction design and UX Design, and has consulted and freelanced. Kim holds a B.F.A. in Photography from San Jose State University. Follow her on Twitter at @uxkim and her product design thoughts on Medium.

Kim Williams – Indeed Senior Director, UX Core

Kim’s Proudest Moment: “I have had the honor of orchestrating Design and Brand Systems teams at brands that focus on connection. First at eBay, and now at Indeed, where I am proud to be building a team of talented product designers, technologists, and creatives. My team inspires and challenges me daily, as we work on creating experiences that further empower job seekers during their job search.”

Kim Williams is a Senior Director of UX Core at Indeed. Prior to Indeed, she was at eBay for two years, working in roles from Head of Brand Systems to Creative Director for eBay’s human interface group. Prior to eBay, she was as a Creative Director for Oglivy & Mather, Serious-Gaming Agency, and Weber Shandwick. She began her career as a Designer for consumer goods companies. Kim holds a BFA in Visual Communications with an emphasis in Graphic Design. Follow her on Twitter at @kimwms_.

May-Li Khoe – Khan Academy VP, Design

May-Li’s Proudest Moment: “Despite having worked on so much of Apple’s product line and have a pile of patents as a result, I’m proudest of putting pink hearts and technics 1200s into MacOS, and building a diverse & inclusive kickass design team at Khan Academy.”

May-Li Khoe is a VP of Design at Khan Academy. Prior to Khan Academy, she was at Apple for over seven years, working in roles from Interaction Designer to Senior Product Design Lead. She began her career at IBM as a Research Assistant for three years, and was at MIT Media Lab as an Undergraduate Research Assistant for three years. May-Li holds both M.Eng and S.B. in Computer Science and Electrical Engineering from MIT. Follow her on Twitter at @kayli and her product design thoughts at Medium.

Ratna Desai – Netflix Director, Product Design

Ratna’s Proudest Moment: “My greatest achievement has been to build diverse teams and create the conditions necessary for design to live alongside technology and business strategy. Both at Netflix and Google, I was able to connect individuals to the right opportunities within very different organizational cultures. The key has been to lead with authenticity and adapt my approach to complement the culture and design’s relationship to other functions. The successes have come when open-minded, passionate and hardworking teams selflessly collaborate to do their most meaningful work. I’ve had the privilege of witnessing the best product ideas thrive, transform industries and shape society.”

Ratna Desai is a Director of Product Design at Netflix. Prior to Netflix, she was at Google for four years leading multidisciplinary UX design teams. Prior to that, Ratna was at frog design for six years as a Creative Director, an Art Director at Gap and Korn Ferry, and began her career as a Marketing Associate at the Wall Street Journal. Ratna holds a B.S. in Graphic Design and B.A. in Rhetoric & Communication from UC Davis. Follow her on Twitter at @RatnaDesai1.

Susan Dybbs – Collective Health VP Product & Design

Susan Dybbs is a Vice President of Product & Design at Collective Health. Prior to Collective Health, she was at Cooper for four years leading the interaction design team as Managing Director. Prior to that, Susan lead UX consulting for a few years. She began her career as an User Interface Designer at Microsoft. Susan holds a M.D. in Interaction Design from Carnegie Mellon University and a B.A. in Design, Urban Studies, Psychology from New York University. Follow her on Twitter at @dybbsy and her product design thoughts on Medium.

Product Designers – We Want To Hear From You!

Tell us about your Product Design experience, resources, and nominations!

Thanks to Samihah Azim, Women Talk Design, and Latinx Who Design.

Stay up-to-date with Girl Geek X! To get notified of future events and news, join our mailing list!

You can also follow us on LinkedIn, Facebook, Twitter, YouTube, and Instagram.