In this session, Anna Fuller discusses the important factors to consider before leaving a company, such as personal finances, family obligations, health, and legal status. Throughout the talk, Anna provides practical advice and recommends resources for further learning.

Transcript:

Anna Fuller: Awesome. Thank you so much, Angie. I’m excited to be here with you all. And while I get my slides up, I’m just going to publish a quick question so I can see what type of folks we have in the audience. So, I’m curious. I’m going to be talking today about leaving big tech to found your own company. And I just want to know of those of you in the audience who’s thinking about it, who is actively acting on it, and who is just here because they’re curious. So, if everybody could go ahead and vote, I’ll give you guys a few seconds. Okay. All right, so, we have a lot of folks who are in the thinking about it and curious stages, which is great.

All right, so I’m going to go ahead and hide this poll. You can keep answering, I think, throughout this session. But let me bring up my slides. All right, great. So today I’m going to be talking about starting a company, and specifically, how to start a company when you are leaving another company. So, who am I? I’m Anna. I’m a two-time founder. I’m currently working on a company called Halo, which is weekly flash deals for new moms. If you yourself are a mom or if you have mom friends, please head on over and sign up. I used to be a product manager at Google. And previously, I have a lot of startup experience, mostly on the product side and mostly in e-commerce and consumer.

Okay, so today we’re going to talk a little bit about that all-important question, when is the right time to leave your company? We’re going to go through the basics or what I call the important stuff, the meat of creating that new startup, so idea, traction, team, and funding. If we have time, we’ll go through some of the tactical stuff, but I’m going to leave them behind for you on slides so you can always come back. It’s basically the logistics of setting up a business and all the different software tools that I recommend. And likewise, if we have time, we’ll take some questions at the end.

Okay, why am I here today doing this? So it’s been shown that female-founded startups actually return 2-1/2 times the amount of revenue of others, but still, unicorns only have 14% female founders, only 6.2% of the CEOs in the S&P 500 are women, and under 3% of VC funding goes to women. These numbers are terrible. We need to do something about it. The thing that I would like to do to try and help enable you guys to come out and make these numbers better is share some of the hard-won early lessons from starting a company so that you can hopefully shortcut that process and get there even faster.

All right, let’s dive right in. So, first up. When is the right time to leave the security of your company, your current company, and start your new company? Okay, let’s think through a few things. What do you need to have in place before you leave? There is one thing on this list that everybody needs to have in place. It’s fully required. The others are going to depend on you. So, the stable personal foundation or your personal runway, this everybody needs to have locked into place. What do I mean when I say personal runway? Let’s look at a couple of different things. Think about your finances. What is your monthly spend right now? How long can you make it, how many months can you make it with the savings that you’ve accumulated, and how comfortable are you with burning down some of your personal savings?

Think about your family. Do you have any obligations right now? Are you caring for parents? Do you have young children? Are you thinking about starting a family? You can do a startup with all of those things. I have a toddler, and I’m doing a startup. But for you, you may want to just understand what that looks like and when you’ll be most comfortable to branch out on your own. So, health, make sure you’re in a good spot. Startups are really hard. They take a big toll both physically and mentally. So, just make sure you’re in a good spot with health. And then, lastly, consider your current legal status. So, if there are some folks who are here that are being sponsored or on visas, just think through those implications and make sure that you’re set up for success when you do decide to leave.

Okay, so we’ve got that one locked down. The reason I call it your personal runway is it dictates how much time you have after you leave your company before you need to have your startup providing that stability. And this depends on the length of your runway and also your own risk tolerance. So if you have more runway and a greater risk tolerance, you’re out the door. Go ahead and leave now, and you have time to figure it out. But many of us have a shorter runway. We want to check off a few more of the below before we actually leave our company. And I have the asterisk here. Don’t forget to check about your moonlighting policy. A lot of big tech companies will let you work on your own side projects, but you just need to disclose it. So, just read the fine print there and make sure you’re on the right side.

So think about these next four things, idea, traction, team, and funding, really, as things that we’re going to progressively de-risk. And you may choose to leave your company before any of them are de-risked, or you may choose to wait and leave until they’re largely de-risked, but it’s a gradual process. Okay, let’s talk about this. This is the important stuff. This is the meat of building your business. The idea, this is something that occupies an out sized mindshare. I think before you actually start a company, you have this idea of the founder, and they have this brilliant idea that comes to fruition, and they bring it to market, and everybody loves it. But that is a total myth.

In fact, I think too much emphasis on the idea is actually a bit dangerous because the reality is that as you get in and start working on your startup, the idea is going to change, and you don’t want to hold onto that too tightly. What you really want to focus on is the problem that you’re solving for your customers and how you can best solve that. And that’s likely going to change quite a bit.

So when you look at this handy little chart of this wood carving, at the end, you can see a fully formed statue. We do not want to start there. Don’t assume that your idea is what you’re going to ultimately build. Instead, start on the left side where you see this progressive, this outline of a wooden block that’s going to progress through the stages. So, how do we progress it? It takes a lot of time and effort. And to be honest, this is work that you’ll be doing over the course of your startup.

So, start with a problem area. How do you choose a problem area? Ask yourself a couple of questions. What are you the world expert in? It doesn’t have to be mind-blowing or groundbreaking. It’s just what is your expertise. If you were to start a consulting business tomorrow, what would people actually pay you money to do? Because odds are, if you were to solve that problem for them, there are some problems that you could solve for other people in that domain. So, think about that. Also, think about what are problems and frictions that you encounter in your day-to-day life. And then, lastly, make sure you pick a domain that you’re comfortable spending the next 10 to 15 years in because startups are long, and you don’t want to be bored. You want to be passionate about what you’re working on.

So in the next step, you’re going to navigate what we call the idea maze. So, really, what this is, it’s just understanding what the array of solutions that are already out there in existence are, and how are they solving the problem? How are they not solving the problem? You want to go out and talk to people in your space. You can talk to experts. You can talk to potential customers. You can talk to competitors. Just understand the lay of the land. And then start on your customer discovery. And this is where we start this lifelong journey of a startup because you’re always doing customer discovery. You want to get out and talk to your customer.

So refine your solution, move on, test prototypes, refine again, build your MVP, refine again, go to market, refine again. It’s just a constant loop of refining until you’re solving more and more of your customers’ problems, and what you end up with could look very similar to what you thought it might look like or it could look totally different. So, in startups, we have a phrase called pivoting. Sometimes, you just need to read the market and do a hard pivot, and you’ll find some other problem to solve. A book that’s super helpful as you think about customer discovery and idea validation is called The Mom Test. Go out and get it. It takes about four hours to read, and it’s going to really demystify that whole process for you.

All right, so traction. There’s really this continuum from your idea through validation and traction. But traction similar to the idea has this sort of mythology about it. It’s like, “Well, do you have any traction yet?” So, let’s break it down a little more. Traction itself is too vague. Let’s think about a couple of things. Why do you want to see traction? Is it because you want to de-risk the idea for yourself further, or do you want some validation that this is the right solution to work on? Is it because you want to get investors? Is it because you want to start getting revenue to fund your operations? All of these are valid things. But it’s important to understand why you want to see traction because we’re going to use that to understand what to measure and how much traction you need.

So, in terms of what’s important to measure, this depends totally on the startup that you’re building, but there’s a couple of key metrics that we always tend to go back to. One is users or customers. I differentiate the two because users are just coming back and using your product, maybe not paying directly. Customers are people who are paying you directly. We also want to look at maybe average contract value or gross merchandise volume if you’re a marketplace, anything that indicates that you have money that is either coming in or about to come in the door.

And then how much do you need? This is a really difficult question to answer. You need to set reasonable milestones based on your goals. And one thing to keep in mind is that this hockey stick growth is just not going to happen right away. So, try to prevent getting into the trap of thinking, “Oh, I’m just going to wait to bring on my team,” or “I’m going to wait to fundraise until I launch because then it’s going to be through the roof.” That’s probably not going to happen. So, set measurable, realistic milestones for yourself. I get asked a lot, and I think about this a lot as a founder, “How much traction is enough for fundraising?” And here I’m specifically talking about VC-backed companies.

This is not a straightforward answer, unfortunately, but there are some tactics you can take to figure out what the right answer is for you. So, first off, ask other founders. If you are in a B2C space versus if you’re in a B2B space, the metrics for raising that first round of capital are going to be much different. So find other founders in your space who have maybe just raised their first round and go and ask them. Ask them what the process was like. Ask them what their strategy was and what their metrics were like. Read funding announcements. TechCrunch is going to publish articles about companies in your domain who have just gotten funding. Read those to understand what their current status is. I would say there are two things to keep in mind here. One, founders like to paint a rosy picture, so take what you read with a grain of salt. And two, funding announcements can sometimes come months after the actual round happens, so they may have progressed a little bit further in that time.

And then, lastly, talk to investors. Reach out to investors in your domain. Let them know that you’re not fundraising right now but that you want to get their feedback and you want to get their input on your idea. Then, talk through with them what do they like to see before they write their first check for a company. Other ways to validate your idea. Like I mentioned, it’s sort of a continuum. You want to go through discovery, validation, and, eventually, real traction. So, discovery, there’s a number of ways you can actually figure out whether your solution is going to resonate without even writing a line of code. You can do surveys. You can do customer interviews for that qualitative data. Or you can set up what we call a fake door test where you put up a landing page with a call to action.

Let’s say, “Buy this product.” And you just measure how many people click “Buy the product.” And, of course, you don’t have the product yet. So they land on a page that just explains, “Hey, we are in the process of making this. We want to make something excellent for you. Enter your email address, and you’ll be the first to know.” So, we’ve gauged their demand because they were ready to buy even before we have the product itself. When you move a little bit further into the validation stage, you may want to run a beta with a small, trusted group of customers who will give you good feedback. You may stand up a wait list, people who enter their email address. That’s sort of giving up something of value to them in exchange for getting your product in return. That’s a good way to gauge demand.

Or if you’re in the B2B space, maybe it’s letters of intent. These are just letters that a company will write, or you can send it to them. They’ll sign, saying, “Hey, when you build this thing, I want to try it out,” and it’s not binding. So, it’s low risk for them that you can gather these to understand who your initial design partners will be and show some demand. Then lastly, real traction, customers and growth. There’s nothing that there’s no other secret sauce there. You just need to bring in people who are getting value from what you built. A really helpful book here is also called Traction. I highly recommend this.

Okay, moving on to team. So the traditional sort of triad that you might hear of in a co-founder relationship would be this hacker, hustler, hipster combo. And really, what that means is you need somebody to build the product, you need somebody to sell it, and you need somebody to design the user experience. Now, you don’t need a separate person for each of these things. Maybe you as the founder have two of the skills, and maybe your co-founder has two of the skills. So between each other, you have this overlapping skill set. But you do roughly need to know who’s going to build it, who is going to sell it, and who’s going to be responsible for that user journey.

So, to think about here, what are your own strengths? What do you bring to the table, and where do you need help? I would recommend getting very creative here because think scrappy. You’re going to leave your big company where you have a person to work on every small thing, and they’re a subject matter expert in that, and you need to be comfortable with wearing multiple hats. You might need to be comfortable with understanding what is good enough for now. Maybe you are a product manager, but you can do some wireframes, and so that is good enough to translate to a developer to have them help you build the initial product. Think about how you can get to your end goal and validate your ideas as quickly as possible.

Then, also, contractors and interns are a lifesaver. So, if you have no idea how to market something, you can look to hire an intern marketer who will get a lot of value from helping you in addition to you getting value from them helping. Do you need a co-founder? This is a big question, and I think this presentation is too short to answer it here. But I will just point out that co-founders are great ways to bring on a supplementary skill set for equity in the early days. They have skin in the game. And you don’t have a lot of resources, so you need people to contribute who have real skin in the game.

Also, founding a startup is an emotional roller coaster. So, having somebody there who can go through those ups and downs with you is essential. But make sure, on the other hand, that you’re not just bringing on a co-founder that you don’t know very well because it really is akin to a marriage. It’s going to be a relationship that you need to foster over the next 10 to 15 years of your life, so think carefully there.

Funding. Okay, a very important question. Why do we care about funding first off? So it’s not to say, “Oh, I raised this round of capital.” It’s because you need to fund your own company operations. You need to fund your own personal runway. Eventually, you’re going to run out of your savings. You need something to supplement that. So, let’s think through a couple of different types of company funding. So, we have broken down into three. Venture-funded, this is your typical equity VC-backed company. The exit event here is usually an IPO or a sale. And what to think about for this category is you’re going to go through multiple rounds of funding, so the founders will get diluted. You have to have an exit before the founder realizes all that value. So, you’re not going to have these yearly cash flows. There’s going to be a lot of pressure for growth, and billion-dollar outcomes are expected.

It’s really this big swing all-or-nothing thing. You’re also probably going to need to be full-time before you get that first check. Boot-strapped, usually this is the situation where a founder will put in initial capital, and then it really could go either way after that. It could be venture-funded. It could be revenue-funded. A lifestyle company, think here, these are if you’re going to start a physical business like a restaurant or if you’re starting a passion project like a blog. It’s any type of business that is not the sort of typical venture-backed Delaware C-Corp style business. This is usually revenue or potentially debt-funded. The business pays for itself.

A couple of key characteristics. It will have regular cash flows. So you can get this to a point where it’s actually paying you to operate the business, and you can start taking cash out of it. It’s usually more aligned with a more sustainable growth pattern, and you can start this as a side hustle.

Angie Chang: Thank you, Anna.

Anna Fuller: Okay, how are you-

Angie Chang: [Inaudible 00:17:42] time. We’re out of time.

Anna Fuller: Okay. Great. Okay, well-

Angie Chang: Thank you so much for your-

Anna Fuller: Yep, no problem. If you guys want to download the slides, feel free to grab this deck. And I’m always available for more questions.

Angie Chang: Great. And you can always hit replay in this Airmate software and they can just re-watch this session and get this QR code.

Anna Fuller: Awesome.

Angie Chang: Thank you so much.

Anna Fuller: [inaudible 00:18:08].

Nas Hajia emphasizes the importance of thinking like an architect and developing customized security solutions that fit the specific needs of each company. Hajia explains the elements of a risk statement and the importance of including them in a risk-based decision model. She also outlines the steps of the solution development lifecycle, including understanding the business model, defining the problem statement, and developing, testing, and deploying the solution.

Transcript:

Nas Hajia: Thanks for the introduction and thanks everyone for joining this session. My name is Nas Hajia, and we’re going to talk about Next Gen Solutions: Leveraging AI for Smarter Security Risk Decisions today. Amanda gave a great introduction to me, I’ll just go over some of my background highlights as well here. I’m a security architect. What I do is both on the product architecture side of things and enterprise architecture topics, both of them. I started my career when I was in Canada. I started from research and then I made my way to very different industries from telecommunications to financial. I moved to data industries where the business model was basically just acquiring and selling data again. About two years ago, I moved to the Bay Area. That’s where I’m living right now, and I work for an awesome company called Autodesk. I have my contact information there as well.

I’ll promise you that the QR code is safe. If you’re a trusting person, you can use that to find my LinkedIn page. I’m not sure if we have enough time for a Q&A today, but if we don’t, feel free to contact me on LinkedIn for any questions you may have on this topic or anything else. I want to start by this sentence because this is what will basically form the whole presentation today. I mentioned that I’ve worked in a couple of different industries and the one thing that’s always been true there is that you may perceive that a certain problem is the same across different companies, but very rarely can you actually implement the exact same solution in different companies in different situations and scenarios and try to get the same level of success or satisfactory measurements there.

What I want to do today is, instead of telling you what solution you should implement to get the best results, I want to walk you through how to think like an architect and basically be able to come up with your own solution that fits your own needs in your company and based on the problems that you are facing today very specifically. Let’s start from a quick poll. You should be able to access the poll if you go to that fourth or fifth option in your screen right now. We’re talking about risk-based decision making, so we, of course, need to know what a risk statement is first of all.

Take a look at these options. I can read them out loud while you’re going through them and we’ll see what the results are going to be. These are all statements that you will hear in many different security discussions in a company, by the way. None of these are fictional. I’ve come across these all the time. The first one says a company’s EDR solution are not scalable. Only 60% of managed devices can be set to have appropriately configured EDR agent. Second one is, we anticipate increased incidents in the next six months and we should proactively prepare by amplifying your security controls.

Option number three says, the absence of robust email-based data loss prevention controls increases the likelihood of disclosure of sensitive information due to human error, thereby compromising data confidentiality and exposing the organization to potential financial penalties. Option four is leveraging sophisticated email-based email security tools will minimize the risk of successful phishing attacks. The majority of you answered correct. The right one is option number three, which is obviously the longest answer as well. The reason for that is, each risk statement, there are three elements that it definitely needs to have. First element is the event. That’s basically the conditions that must be present for the risk to occur. The second one is outcome. What will happen when the conditions are present? The third one is the impact. What harm will it do and why should we even be concerned about that?

Optionally, you can add likelihood, risk factor, security controls to add to some of the other ones as well. This one is very important and we’re going to come back to this, and the reason for that is these are all the things that we need to include in our risk-based decision model. I’ve come across quite a different use cases for this topic specifically and also other ones as well. Unfortunately, not all the use cases that are proposed, they end up being successful. Some of them are rejected by either architecture boards or leadership. A lot of them could have actually had a better journey if they had gone through a solution development lifecycle phases here as well, because it’s one thing when you put together a POC or you want to test something in a sandbox environment and it’s a completely different thing when you want to implement it in an enterprise environment where, let’s be honest, the conditions may not be ideal.

The dependencies are a lot and you may have to consider a lot of integration prerequisites as well. The steps that we should start from before you start anything is you have to understand your business model, the existing architecture and processes very well. Then you want to move on to defining your problem statement. Next step is defining your solution goal and requirements. Step number three could be optional, but I usually like to start from this. This isn’t designing the solution itself. It’s a very high-level ideation of what the solution could look like, and then, based off of that, the next step you want to define your dependencies and prerequisites. Then finally, I’ve combined a couple of different steps here as well. You want to develop, train, validate, measure, improve, and deploy.

If you look online and if you try to do your own research or see probably different variations of the solution development lifecycle here, but what holds true is that they’re all going to be some sort of variation. This is basically, the difference will be based on how you want to differentiate between the steps. This is, I think, a good model to go forward with our talk today.

Let’s start from the defining our problem segment. We’re talking about risk-based decision making, so we have to start with the five Ws. That’s basically saying, the who part of the problem statement is any personnel who’s responsible and accountable for making and implementing security impacting decisions. That could either be leaders, that could be developers or operations team, people who are implementing patches or people who are making strategic decisions. The what of it is the fact that there are too many risk factors and they’re not standardized and they apply to a wide range of assets. It makes it difficult for manual process to pick up all of this. The win of it is actually, I would say that’s all the time because any decision we’re making could have security impacts as well.

The where of it could be is actually all of the assets on a company. Every single asset in a company could either have risk impacts or could be a risk source itself. The why of it is that, well, we want to make decisions that are aligned to business goals and at the same time we want to make sure that we’re efficiently using our resources. For some use cases, it’s not feasible to spend, for example, a whole year to make a decision and in some other cases, even spending one hour to make a decision is too long. We need to be able to find the right balance there. If we want to look at, let’s start going through the very high-level, what the solution would looks like. This is simple for a reason. You may want to think that’s what we’re trying to do here.

We have some sort of black box, some sort of operation and data analysis happens in it, you feed it some input, it spits out a certain output. The problem solves, you’re making your decision. Except that there’s a couple of problems here. One is that, we have no idea what the brain of the operation, the data analysis part of it, the security data analysis part of it looks like. The input gathering itself is actually quite difficult. It’s not just one. There are way too many and we’re taking a look at that in the next slide as well.

There’s a problem with the output of it as well. A problem statement, as you saw, it’s a bit too generic. It’s a very big problem and there are many, many different elements to it. Unless we break it down, we won’t be able to say, what are the outfits that we expect here? Another thing to keep in mind here, that the output can never be the decision itself. The output is only a decision aid for the human users and the human decision makers to utilize and facilitate the process.

Let’s take a look at some potential inputs that you want to look at. I’ll give a disclaimer here that this list is by no means exhaustive. It’s just intended as a way to show you what are some of the difficulties that we’re dealing with. The inputs come from all of the company’s assets, whether that’s people, process, technology, devices, data, all the events, millions and millions of events that are happening daily in a company, and it could include a combination of business and security data that is measurable. Something like what’s the customer usage rates and the number of users in a company, what’s the business reputation? What does the market look like? And then the security side, it could be anything from office type of security data like, let’s say, sensors and IOT devices to access events and security events.

We have application firewalls and code access and new vulnerabilities on anything that comes up. All of these have different resources, all of these have different formats, they’re coming from very different places. The idea is to combine all of this and give it to one centric model. In practice, that’s just incredibly difficult. If we want to consider think again to our solution development lifecycle phase, the next step was defining solution characteristics and requirements. There are some solution requirements that are applicable to most solutions anyway, regardless of whether it’s for risk-based decision-making or not.

For example, it needs to be functional, it needs to be learnable, maintainable. For this topic specifically, you have to be careful that your solution needs to be repeatable as in the exact same inputs should always give you the exact same output. It has to be interoperable, reusable, and there are a couple of other use cases that you want to consider. Those would be very specific to your use case. For example, you want to consider what is the amount of human interaction and decision-making power that you want to give to your human users. Or, what is the balance of accuracy versus performance of a solution that you’re comfortable with? Depending on who your main audience is or if you want to have different audiences, you may want to think about separating your security and business criticality criteria as well.

We looked at the problem, we looked at what our solution should have. Now, let’s talk about why we think AI could help with some of this. The big problem is that I mentioned with the input, there’s just too many security data. For difficult-to-find data, human-created processes and manual processes, even if they’re automated actually or human users, they will have blind spots. But at a well-implemented and well-designed AI model will not have that. That’s definitely one of the good things that we have to keep in mind here.

Second one is that your AI model would understand your entity state and posture. It could definitely, that’s a big could, but it could definitely speed up your process as well, and it could help you with training the people for any growing sophisticated attacks and the dynamic environment that the security risk sources are. You can, of course, also use AI bots for real-time adaptive security, and if you wanted to do that by using your human personnel, that would’ve been much, much more difficult and time-consuming.

We’ve talked about solution criteria and we talked about designing our solution for a very specific goal. We need to be able to test it and measure its success as well. First thing that’s important is to make sure that your solution is passing your repeatability test, and then you want to make sure that you’re testing it for very different threat scenarios as well. Then, some of the other thing you want to measure and test against, they could be based on the functionality of your model and you have very specific AI and ML measurements like accuracy scores and precision scores and learning rates that you might want to consider. But also, you want to think about what the goal of your solution was. For example, if your goal was to increase the average time that it would take your company and your personnel or the risk owners to remediate critical risk, that would be a good measure to consider here as well.

Now, let’s go through very quickly some of the lessons learned I’ve come across in my experience. First one, this could definitely, when it comes to your solution, make it or break it as a knowledge base and what your existing data architecture and governance looks like. If you don’t have that, then a hypothetical use case that works in sandbox would not actually be able to satisfy your requirements in an enterprise environment. You want to be very clear about what your impact criteria and definition is. Again, how much business criteria do you want to have in your model and how businessy do you want the output to be?

Next one is that you’re creating a solution for a very specific use case, and even if the measurements are great in terms of functionality, if it’s not actually being used in the environment and if it’s not something that there’s interest in your organization to adopt, that’s going to be a big problem. There’s going to be a question of why did we start with this anyway? Have those discussions early on as well.

Another thing is, if you’re starting everything from the scratch and you’re building it in-house, the time investment that goes into it could be so much that would skew your return on investment numbers. The time that you’re putting in and the time is one of the very important resources for any organization, that has to match what you’re getting out of your solution as well. Next one is talent and skillset. You can have a great use case, but if you don’t have the right talent and skillset in your organization to both design and implement it and also maintain it afterwards, then it will stay in ideation phase. Last but not least, like any other initiative, stakeholder management and expectation management becomes very important.

When you’re working with your stakeholders, you have to be able to convince them that the solution you’re proposing is actually satisfying a need of theirs. Then, when you’re talking with them and you’re negotiating with them, you could have stakeholders at both end of the spectrum, so you could have ones that think AI will solve all of your problems, and then you can have stakeholders that are extremely fearful of AI and think that it’s the greatest evil, for lack of a better word, and you need to be able to find the balance and to convince them and negotiate them and persuade them of the benefits of your solution as well.

Couple of considerations for any AI model, for your AI-based solution model is that AI hallucinations I think they will happen, so be aware of them and put appropriate guard lays in place. If they do happen, patching them is still an open problem and we don’t really know how to address them. Next one is with using AI, you may have new threat vectors. You may want to consider adding detective and preventive controls and including some very specific language and line items around that in your center response playbook, privacy and data protection, and then using how your data is being used and accessed and what the data lineage looks like is, of course, very important whether you’re using a third party model or if you’re building your own.

Now, the next one, very important to keep in mind is that there is no solution that is a hundred percent accurate. There is no solution that you can say never fails. Instead of designing for a fail-safe solution, you may want to think about designing solutions that are safe to fail and make sure that you have contingencies in place. Just to continue very quickly, since no solution is fail-safe, if you put your solutions on a critical path, there’s always a chance that they will lead and result to incidents, so be aware of that and have those discussions early on and see whether you’re comfortable with that or not. The other consideration is that there are some very good third-party solutions out there and it’s not always as easy as just going in and adopting them. Sometimes the cost that comes with them and sometimes they’re not very available, it makes it difficult for them to be immediately usable for your organization.

We talked about what problem we want to solve and how AI goes into that, but if we want to do it the other way and we want to say we want to use AI, we want to see where to use that in the security environment, we have a couple of good options that I don’t think we’ll actually have time to go through, so I’ll quickly go to the next slides. The most important thing in this presentation that I want you all to go away with are these points that I’ve put here. When you’re designing a solution, always be very careful with all the steps. Don’t skip anything. Always play the devil’s advocate and make sure you are considering and actively thinking about what parts of your solution could fail and document them. Make sure that you’re aware of the fact that there isn’t one solution that can solve or your problems. Plan for all your dependencies. Okay.

Amanda Beaty: We have a hard stop. I’m sorry.

Nas Hajia: Okay.

Amanda Beaty: All right. Thanks everybody for joining us. Thank you so much, Nas, and we’ll see you all in the next session.

Nas Hajia: Thank you.

Olivia Ouyang discusses how to leverage design thinking in the job search process. She shares her personal experience of being laid off and finding a new job within two months using this strategy. Design thinking is a five-step process that involves understanding the goal, identifying the problem, being creative in finding solutions, testing those solutions, and iterating as necessary.

Transcript:

Olivia Ouyang: Sorry about the long description about myself. Actually, this is highly relevant to what I’m going to share today, about how, not just for any designer, actually for anyone who is job searching, right now, how we can actually leverage some of the strategy I will share next, to help you to land on your next job that you really want.

Hi, again. I’m Olivia, and as you probably can catch some of the keywords that inform intro, in the past four or five years, I have a course of different startup experience, various sizes and industry. And a lot of people ask me, “Oh. How can you just jump from, for instance, a consumer banking app, selling to an enterprise global trade, whatever, logistic kind of platform? How do you make that connection, and make the dots?” And this is what exactly I’m going to talk to you about.

Unfortunately this also, I went through that personally this year in January. I got sudden layoff, and the situation I face because of some of the visa situation that I have to really quickly figure out. This has ended up, I landed out my current job within two months, also leveraging the strategy and process I will introduce next.

With this talk, I’m going to introduce the process. It is called, Design Thinking. I am sure a lot of people, especially in tech, are pretty familiar with this. But how do you actually apply this in terms of a job searching progress, is something we’ll be interested. And after all of that, I will want to share some personal perspective in terms of, if you unfortunately have to go through the layoff process, and have a stressful timeline, how do you manage the burnout, and some tips that really can help you to go through this process.

Next, I’m going to introduce this amazing problem-solving process called Design Thinking, again. It’s a five-step process. Basically, I would say, not only I use it every day in my work, and also I use it on my daily life as well. For anything, small and big, you really can just start it from understanding, “Okay. What is the goal here? What do I really want to achieve?”

And next up, rather than jumping to a solution right away, you want to understand, “Okay. What is the problem here? I can’t get it.” And trying to understand much of the context and constraints and everything. And then, you can start being really creative, saying like, “Oh. With all of the resources I have, with all the tools I can access, what are some of the way I can potentially try to get my goal?” And then, with a bunch of the lists, and then, you can just try out and test. If you are an engineer, I guess a more familiar kind of way to think it is, whenever you are writing a code snippet, you’re definitely going to test it, and then get the compile results, so that you will know what to try next. It’s basically like that.

In terms of for a real job searching process, first off, you want to understand, “Okay. What’s your job searching goal?” The key message I want to emphasize here, the job searching is not a one-way problem. It’s actually a two-way communication, which is a match and fit process. When you’re being evaluating as a candidate, you are also need to evaluating the other party as a company. It’s important to understand, what do you really want, as a job seeker, and then, think about what you can offer to actually really stand out from other candidates.

With that in mind, you can set a goal. Remember, we need to understand the goal first. You can make a list of the next job you want to land on. For instance, I wanted to go smaller or bigger company, specific industry you’re interested in, team culture, the management style, so on. Everyone has a different priority list in this goal list. And you can always adjust as you go through this looping process, and evaluate as you go in the job searching process.

Next step is actually to think about, “Okay. This is what you want, and what I can offer.” This is not just simply list every single thing you have ever done in the resume, but really, really think through what that experience mean in terms of the skillset. You can quickly match that up to any job description you are seeing on the job posting. That will make the hiring manager easily to understand why you are a good fit.

Talk about my own experience, because I have an engineering background. Before, when I was searching for the new grad first design role ever, I need to tell a really good story in terms of how my engineering background will actually help me design. I highlighted, strong logical thinking skills, and my capabilities of communicate really effectively with other engineers because of my background.

Similarly, when I’m looking for the other job in enterprise space, and no experience in designing for platforms and so on, a really complex domain, I actually highlighted my startup experience, and how I deal with all of the ambiguity in such a small team, to show the potential I can deal with unknown spaces, even though this is a really complex and unknown space I have never worked in the past.

Next up is to define. We talk about your needs, and also what you can offer. Next step is the reality check, really, to understand, what is the job market really like? This is an example that I use personally to evaluate myself as a designer. And this is actually coming from one of the company I really, really like. They really being transparent and show this metric of skill metric on their website, and show, “Oh. This is what we use to evaluate everyone in the team, and we are looking for someone who can compensate all of the skillset to this team.” I do this to myself to evaluate how good match I am in terms of to the team, if I really, really like to join it.

And next up is, you can do another exercise is to make another list that, “There’s some of my strong suit of the skills, and also some of the skills I want to develop.” And also, what is your career interest, and things you want to try out next. And the more you can find a match in this inner cycle between you and the target job post, the better fit for both of you, of course. This is a good exercise you can be evaluating and iterating.

From Step Three to Step Five is really a loop. You need to constantly adjust, and then, take that feedback, and then, tweak a little bit, and try the other thing throughout the entire process. And it works through the entire job searching funnel, as well. I can give you some example from really beginning.

First job, you just starting to say, “Hey, I wanted to land an internship or a new grad job, or my next role in a certain timeline.” And you need to plan it backward, to say, “Okay. I initially think maybe I need a couple of two weeks for my portfolio, my resume, and then some times for technical, and then, some times prepare behavior, so you have that rough timeline.

You can idea it in terms of, what are some way I can be creative to plan that and evaluate that. And then, later on, when you put into practice, to build all of the things, you will know the gap between what you thought you could do versus the reality. In recording your process, you can come back, and then tweak it, and then to make a more realistic timeline for yourself.

And same thing apply when you get stuck in a particular interview round, you can do that, too, for saying, “Oh. I have my draft, and then I start sending out a lot of application, but why I’m not getting any screening calls?” You might want you to think of, “Okay. There are some other things I probably can try other than direct applications. I might also want you to be really active on the social media, LinkedIn,” and then share about your experience, your skills to catch more potential hiring manager’s eyes.

And when you’re doing a referral, is there some unique message you can help to try and send it out? And also, linking outreach, what are some different message you can play around that will help you to get more feedback, or some private talent pool that you can join, and reach out to those VC funds, talent pool share, across the portfolio of the companies. Those are some of the creative way that could get you more exposure. I’m just making example here.

Of course, you can use the result of, are you getting more calls, and what is the feedback for the outreach, to evaluate how effective different things you have tried. And the other example, similar to the last one is, for example, you are getting stuck with the technical interview. Other than just waiting for the next opportunity, of course, you can try, “I can probably just record my own session if no one’s practicing with me.” You’ll be amazed by how many thing you can cut that you get stuck, just by recording yourself. And also, you can help others to prepare interviews and then learn from how other peoples respond. Anything they can improve and then reflect upon on yourself, as well.

Of course, depends on the actual interview, and even mock interview feedback, you can quickly iterate on, what I can improve next. And along this way, actually because AI tools are so blooming right now, I remember when I got laid off personally, almost a year ago, I’m basically still using the old methods of writing everything on pen and paper, and putting all together things in the Figma tool, which is the public tool designer all use, and of course a lot of documentation, and all of that. But today, really with ChatGPT, and a lot of other AI tool that can help you mock interview, I will not say they replace your own role as a job seeker to make your own material, but they can really help you quickly to put up the first draft, so you don’t get stuck in the blank canvas struggle, I would say. But at the bottom line here, job searching problem is still finding the right match. This tool doesn’t change the fact that this is the problem you’re going to solve.

And lastly, I want to share some of my personal notes. And this is more callback to early on, when I’m saying I have some visa sponsorship needs, and also with a tight timeline. I would say, transparency really goes a long way. I personally learned the hard lesson. If you ever invest in particular situation where you have a clear bottom line about, “I need specific support. I really can’t go onsite every day. And I have a compensation bar,” or whatever thing, where you, in a really later station interview, you need a deadline, and then close it very fast, and so on. Really, really be transparent on the first call with HR. Because if you are being transparent, then they can help you the best as they could, and also it save both of you time. It’s much, much way better than you’re at a later offer stage, and then figure out there is something you can’t agree on in the very beginning, but you already both spend that much time to get through everything. That will be a really sad and unfortunate situation.

Next up is, of course. Talking about burnout. I also personally have that as well. And you probably often hear about people saying, “How can you give constructive feedback?” And thinking the other way around, how you can take feedback constructively. What that mean is, for saying you failed the interview today, of course you will feel sad, everyone will, no one will like the feeling like, “Oh. I just failed.” But you can take a while and accept the fact that, “I’m really sad.” Acknowledge that, “I didn’t do well today. But okay, what have I learned? Is that because I’m not prepared enough, so that I learned from today’s lesson that I needed to spend more time prepping certain problems before going to the next interview. Or I shouldn’t probably rush to schedule that interview that early, if I’m not prepared. Because it’s wasting both of our time as well.

But if really the feedback that the other party give you is, “Oh. We are really looking for the candidate that have specific skills or experience,” that you wouldn’t be able possibly get in such a short time, that is not a good match. Or if they just tell you, “Sorry. We just filled it with another candidate, upfront.” That again, is not your fault. You really need to understand what is actually the reason behind it, and then turn it to a really actionable item for you to move on, and really use every failure as a stepping stone for your next interview, and eventually get you to success.

To close that note here, I talk about how you can use design thinking, which mean you can think like a designer even you’re not, to trying to problem solve every single little thing during your job searching process, to really customize that to your own goals and needs. And also for tips here, really trying to be smart, leveraging a lot of tools to help you get started faster, so you don’t have reason or excuse anymore to procrastinate. Also, I talk about how you should be really transparent with the hiring managers, so that both parties can move on really smoothly. And lastly, how to take the failure and feedback constructively, so you can always take away and learn from every single interviews that you have, so you can perform better, and know yourself better next time.

And this is all my session, today. I know we don’t have time for Q&A session, but if you do have any follow-up question for me, you want to chat with me more, feel free to contact me here with my contact info. But with that, thank you everyone for attending my session. Really happy to be here. Thank you.

Amanda Beaty: Thank you so much, Olivia.

Thanks to everybody for attending. And we will see you in the next session.

In this session, Michelle Maraj discusses the importance of data visualization and how it can be applied to any job. She uses the example of her travel blog to demonstrate how data points can be interpreted differently depending on the context provided. Michelle also discusses various job roles in data visualization, such as dashboard developer, data analyst, and journalist, and highlights five key skills for data visualization designers: data skills, statistics, knowledge of tools, design skills, and storytelling skills.

Transcript:

Michelle Maraj: Thank you so much. And thank you everybody for choosing to join my session today. Really appreciate taking your time to join me.

Well, I’ll get into a little bit more detail about my history in the field, but before we get started, I did want to give an introduction as far as why data visualization is important and why it can really be applied to any job. And so even though there are some roles out there, I personally am in a role that does center around data visualization, I do believe there is a very cross-disciplinary skill that you can build that can be really contributional to nearly any type of career.

So thinking about why data visualization is important, an example I want to use today is my travel blog. I personally love to travel. It’s one of my favorite, I guess, hobbies, and I did have a travel blog for a few years. So if I was looking at the statistics on my blog, I noticed that in March 2023 I had 16,000 views. So when I give you this data point, this is one piece of data, one row of information, you don’t necessarily know what to do with it. Is 16,000 a lot? Is that a little? What exactly are you trying to tell me? And so even though data can be valuable, it’s not going to be actionable unless you provide additional context around that data point.

So what I’m going to do is I’m going to put it into a data visualization and show you that, compared to last month, I am seeing a slight increase in the views on my blog. So you can see that in March 2023, I had 16,000 views, compared to February, I had maybe 15,000. So this would be a great visualization to show the steady growth in my blog over time. And maybe I want to make the argument that we need to invest in more writers or we need to start making more posts because travel blogging is improving, people are getting more interest in the blog.

However, if I look a little bit further back and expand my dataset, and compare it to, say, March year over year, what I might find is that the 16,000 is really great compared to, say, 2022. But compared to March 2019, my views have actually dropped quite a bit. You know, we had the COVID pandemic and so a lot of people were not traveling as much and not really looking at travel blogs as frequently.

So there are a few different arguments you can make here. You might say that travel blogging is slowly coming back, and so, again, we can still make that investment. Or maybe the story we want to tell is we want to pivot niches. Instead of focusing on travel, because we’re not reaching our full potential here, maybe we want to go into lifestyle or cooking or things like that. And so it’s really tricky because, again, it’s the same data points, the data is correct and accurate, but the data visualization that I show tells a completely dramatically different story.

And the question is, which is the chart that I should show? So that’s why data visualization skills are so important, because it comes down to that designer, that analyst, to make these different types of decisions. Depending on what type of story that you want to tell, you can, I want to say manipulate the chart to show that. And so, again, the data is accurate, but choosing what type of data to show and when and how just completely changes your story. Again, it’s really tricky to tell what type of chart, because both would be correct in this scenario. It just depends on what you’re trying to say.

So data visualization is so important because, no matter what role or industry you’re in, you’re going to be using data and you’re going to have to communicate in some way. And so your data vis skills is really that art of figuring out what’s the right format, what’s the right data, and getting it to the right person. And so making sure that you have that right context so that your story is understood.

So today in this talk, I do want to go through my experience in the field of data vis, what jobs exist, what skills you need if you’re interested in pursuing a career in data vis, and then how to build a portfolio. So for me personally, again, my name is Michelle Maraj and I am a full-time dashboard developer. And so what that means is that my users are people within our company who are looking at data, and so I’ll put together a type of view where people can go in and really look up data that’s relevant to them, whether that’s filtering down to certain market or region or maybe pivoting the data in a way that makes sense for their role.

So in my role at Gigpro, I do Tableau dashboard development where I support teams across a variety of different departments. And so that’s marketing, sales, operations, finance. It is a startup, and so we are helping build dashboards for pretty much anybody who needs data. Before that, I was working at Lyft, again doing Tableau dashboard development, but specifically for finance. And then prior to Lyft, I was in consulting where we were building dashboards for pretty much anybody who needed it.

I did not study data visualization in school. My background is in information system. So I did have that data background, but a of the stuff that I learned was actually on the job through consulting. As I was practicing those skills, it’s something that I started developing. So I love talking about data visualization. I think it’s just such a cool field to be in.

What jobs are there in data visualization? Now, I mentioned that data vis skills are going to be helpful across a variety of roles and industries, but if you are super, super passionate about it, like I am, there are a couple of jobs where it is going to be a much larger portion. So I mentioned being a dashboard developer. So a dashboard is, again, a view where people can interact with data, and so it is sort of a user experience development type role. I personally use the tool Tableau, but there are also similar tools such as Power BI, Looker, Data Studio. It really just depends on what the company is using and what tool you’ll need, but that would be dynamic report building.

Another different type of role that is really going to use data vis skills is going to be either a data analyst or a business analyst. And so you’ll find these types of roles, again, across nearly any industry or department. So if you have an interest in, say, fashion or home goods, you can probably find an analyst role in those different niches and really drill down into data related to those. And so as an analyst, typically what you’re going to do is you’re going to be responsible for pulling data out of a system, cleaning it, manipulating it, and then presenting any findings. And so typically, with an analyst role, you are creating static visualizations that are going to go into maybe a report or a presentation.

Another area where we see a lot of data vis skills being used is with journalism. Though you might have seen, maybe, infographics online, or even a lot of articles that are starting to incorporate charts to help better communicate stories. So I think that the journalism field is one of those where it’s growing quite a bit as far as thinking about how we can incorporate data into communicating a little bit better. And so those are three main different types of roles that you can look for if you are interested in a data vis role. But again, there are lots of other jobs where you’ll probably use data vis skills in them.

So if you think that the field of data visualization is interesting, let’s say, for me personally, I grew up loving technology, loving my computer loving video games. I considered being a graphic designer. I also really like math. If you’re interested, I think that data vis is one of those fields that really just combines all of those different types of interests. And so if you are interested in pursuing a career where you’re really using data vis skills, what kind of background would you need, or what could you work on to improve?

So I think that there are really five key skills that will help you be a really strong data visualization designer. So the first skill that’s really helpful to have is data skills. So knowing SQL, understanding data vis, figuring out how to get data out of different systems, how to manipulate it for analysis is going to be really, really valuable. Because no matter what type of tools you end up needing to use to create your data visualizations, you’re probably going to have to format your data into some form so that way you can get it into the tool in a way that you can create your visuals. So having that data background is going to be really helpful.

Then you’re going to want to think about statistics. So I didn’t necessarily… I’m not a data scientist, you don’t necessarily need to know how to do regressions by hand or anything like that. But having that background, depending on the type of role that you have, can be very beneficial to create either really complicated data visualizations or really just help you summarize your data better. Because with data vis, you are summarizing data points. And so thinking back to school when we had to figure out the differences between mean, median, and mode, and trying to figure out which of those is going to be the most effective, those are the types of decisions that you will make as a data visualization designer. How you want to aggregate your information and what types of summarizations are going to be the most accurate and the most valuable.

Then you’re going to want to think about what tools you’re going to use. And so this is going to really vary across different companies. I mentioned that I’m a Tableau developer, and so Tableau is my area of expertise, and I’ve really built a lot of Tableau skills. But, if you’re interested in, say, maybe a specific company, not every company is going to use Tableau. And so what I do recommend is looking at job postings for the companies they’re interested in and seeing what types of tools they’re currently using. Because even if I go to a company that doesn’t use Tableau, and I can’t always convince them to purchase it because that’s a pretty big investment, and so making sure that you either are building skills in a tool that companies are interested and use, or making sure that you can be flexible in the skills that you’re building.

So, for example, being flexible between Excel or G Sheets is going to be really valuable because a lot of companies will use one of those. But then also thinking about, even if you are a Tableau expert, at least being familiar with maybe how Power BI works could be helpful in your job search.

Then coming back down to it, we’re looking at design skills, and so thinking about how to make your charts visually appealing. Because if you think about, say, Excel, you can create a chart in Excel and it’s going to give you some type of basic chart, but what are the chances of you leaving the chart the way it is? You’re probably going to want to make some edits to it, whether you’re cleaning it up or moving chart junk, changing the colors, things like that. And so understanding different design elements will make your charts more visually appealing.

And then finally, storytelling skills. And so it comes back down to understanding your audience and understanding how you’re going to need to communicate your data is going to be helpful so that way you can communicate it the most effective way. Some of your users might like a dashboard where they can interact and drill down, but others are going to need a presentation or a printout of the data. And so knowing how people are going to consume your information is going to be really valuable so that you can put together the best visual for them.

So how do you practice your skills if you’re interested in this field? I do think that you can read books, take courses, and then, honestly, it just comes down to practicing, as I said. So, if you’re interested in different vis books, these are some of my favorites that I would highly recommend. So across the top, Alberto Cairo is one of my favorite authors that really gets into the psychology of how we are, how we read charts, how we interact with data and art. So love, love, love all of his books.

If you are going to be creating static charts, and so whether that’s charts that you’d put in a report or presentation, Storytelling with Data by Cole Knaflic is a wonderful resource with a lot of really, really practical tips. Nathan Yau’s Data Points is another book. He’s a data journalist, and so that’s a great example of how you can use data vis to communicate stories. And then Steven Few’s book Information Dashboard Design is one of my favorites if you are building dashboards where people are expected to interact with your data and drill down. So love all of these different books.

As far as courses go, again, there’s lots of free resources online. I know that with Tableau specifically, Tableau does have their videos online and free so you can follow along. So I recommend that.

But then when it comes down to practicing, this can get tricky because you think, where do I find data? How do I practice? Coming up with the case studies can sometimes be the hardest part, so I do recommend different community driven programs such as Makeover Monday. So you can Google this, but what they do is it’s a group of volunteers that find a chart that could use some help, or, essentially, a makeover, and they’ll share the chart, share the dataset, and then it gives the community an opportunity to try and recreate the chart. And so this is really great because not only do you have data to work with, but you can also see what other people are creating and get some ideas and inspiration from that.

So creating a portfolio. So let’s say you have been practicing, you’ve been building those skills, and now you want to share your work with the world. And so, again, a portfolio is going to be really, really valuable if you are interested in pursuing a career in data visualization. And so, for me, as a Tableau dashboard developer, I like to show examples of my Tableau dashboards because that shows the employer that I’m telling the truth on my resume and I do know how to create these visualizations and I can really show off my skills. So if you are looking at a specific tool like Tableau, you can use Tableau Public where you can post your dashboards and essentially build up your portfolio that way.

You can also use social media. And so you can use LinkedIn, or there’s actually a really big data vis community on Twitter, and you can essentially build up your portfolio by posting screenshots of your work or links to your work across those different types of platforms. Also, I personally have a personal website where I’ll put my visualizations and it’s called TheChelleCurve.com. I believe there’s a link in my profile here in the chat. But, essentially, what I do is I have a blog where I will post, well conferences that I’ve been to, but also some of the work that I’ve done as far as data vis creations, and I’ll put a little bit more detail as far as either how I got the data set or why I made certain design decisions. And so I built my website on WordPress, but again, there’s a lot of great resources out there.

And if building a website’s a little bit too intimidating, that’s totally fine. You can also put together just a Word DOC or a PDF of your work, and then you can upload that to either a job application, typically there’s room to upload additional materials, or you can upload it to, say, your LinkedIn, and that way people can see your work that way.

So if you are interested in this field of data visualization, a couple of things to remember from today is that, again, data visualization is such a valuable skill to have, especially in this tech world. However, with all of the data we collect, data is only going to be helpful if you can get it into the right format in the right hands. And so if you are presenting, say, a chart to a CEO, if he’s only going to read your emails, he’s not necessarily going to visit a dashboard and spend the time to drill down, then you need to make sure that you are summarizing the data and putting it in a format that they can read.

And then, again, data vis can be valuable to any rule. Data literacy skills are going to be valuable no matter what type of industry you’re in. And so, again, highly recommend at least freshening up on those skills. But if you are interested in pursuing a career in data vis, you just continue to learn, read those resources, practice, build a portfolio, and that way you can show future employers the work that you’ve done and what you’ve been working on.

So, again, thank you so much for attending my presentation today. If you want to connect, my name is Michelle Maraj. This is my website. Thank you, Beth, for sharing the chat the link. And then I can also… Happy to connect on LinkedIn or answer any questions there. Thank you again and hope y’all have a great afternoon.

Angie Chang: Thank you, Michelle. That was a really great talk and we’re going to end the session and go to the next one. So thanks everyone.

In this session, Duaa Gettani discusses the importance of standardizing UX research and the different stages of UX research teams. Gettani explains that research can be engaged at any point in the product development cycle, from foundational to generative to evaluative research, and suggests standardizing research processes and normalizing research’s impact to incorporate research at all stages.

Transcript:

Duaa Gettani: Hi. Thank you for that lovely introduction. Thank you all for joining, and thank you all for joining a talk on standardizing UX research. I know that doesn’t sound that exciting, but I will do my best to make it exciting. So we’ll get right into things. I know we only have 20 minutes.

Just a quick intro of what I’ll be discussing. I’ll briefly introduce myself, talk about what the importance of talking to users in different stages of UX teams and how that manifests itself in different structures of UX research teams.

So brief introduction about me, I do come from an academic background. So I know a lot of folks in the UX field come from very eclectic backgrounds. There are more traditional human-computer interaction backgrounds, but I come from an academic research background. This is some of the research that I did at the Institute of Transportation Studies where I got my MS in transportation and some of the publications that I worked on and the research that I worked on there.

I talk about this as a way to reflect on how I got into UX. So I come from an academic UX background and wanted to get into a research space in tech and found UX research as a great way to compliment my experience. So just a quick overview of my career trajectory. I started off as a research coordinator at Google and then a research associate at Waymo and then a UX researcher as well as an ops manager. So I did help with the ops management at Lyft, the operations that are associated with UX research. Then my current role here as a Senior UX Researcher.

I think a lot of folks probably joining this talk may have a question as to how I made that transition from academia into UX. My answer to that is that what I did was that I started off by joining in as a contractor at these specific companies. So the companies here in the box are the ones that I joined as a contractor. I think that’s a great way to introduce yourself into the UX space, to understand if it is a value to you and something that you’re interested in continuing, and a great way to network and get to know other folks in fields that you would potentially want to grow within. So just wanted to give that quick overview of how I transitioned into UX in case it’s beneficial to anybody.

I will get right into what I wanted to speak about today. So just talking about research as a researcher. We understand that basic research is about talking to users. So within a UX space, within a product space, the crux is that talking to users and conducting user research is essential for creating products to meet user needs that are easy to use and have a greater chance of being adopted and successful. So setting up processes allows everyone to benefit from talking to a user. So to prevent that ad hoc talking to users and have a structured standardized process in connecting to users.

So the first layer of the onion is talking to the user. If we simplify it, that first layer is just talking to a user. That surface level way to learn about products is to just simply talk to a user. Why they use a product, how they use a product, who they are? Within Square, where I’m currently at, our users are sellers, so people building products for people. So this next layer is understanding a user’s needs, goals and behaviors. Digging a little deeper, within Square we learn where seller’s pain points are, what are their goals as a business and as small business owners?Then where you’re trying to get to, that crux is to understand a user’s pain points and address them, building a seller focused culture for us at Square across all functions in Square banking. Then that center, that sweet spot here is where we want to get to continue to build empathy.

So when we’re talking about research, and we’ve all probably seen this similar structure and we’re understanding at what stage should research get involved in. The short answer is research can be engaged at any point in the product development cycle. From foundational, so learning about people and their problem space to generative research where it’s prioritizing challenges to solve and focusing more on the solution space and then that evaluative research where you’re more tactical and iterative. So research is not meant to be a one-off surface, but rather part of an overall process. Ideally, we incorporate research at all of these stages, both when we know what to build and when we can have something we’re iterating on. So how can we do that? By standardizing research and having and normalizing research’s impact.

So where you want to be and where it’s okay to be. So we know that research structures in different companies can be very different, and that’s okay. So research can have impact at any stage. So I have this oversimplified structure of where you’ll find yourself as a UX researcher jumping into a company. So sometimes you’re the sole researcher, sometimes you’re in a mid-sized team, two to five researchers, and sometimes you’re a fully embedded team, and this is ideally where every researcher wants to be. There are challenges at each stage. So I’m going to cover a few of them, but mostly focus in on the mid space, where a lot of researchers end up being.

Sole researchers, there can be probably the biggest challenges with one researcher is that educating on how research works within your company and having impact to drive growth and drive the growth of the research team as well as prioritizing projects that will allow for that to happen. Then where we will focus today is that mid-size team, and that’s where I am Square banking. The challenges here is that you may or may not have an ops person to help with structuring the projects and there’s still challenges with prioritizing and balancing projects and balancing prioritizing the right projects and consulting on other projects.

So where do we start? There are two ways to begin to, at least the way I see it is, two ways to take in research. You either have a road mapping process, which you can combine both of these processes, and a research intake form, because a lot of the times priorities within the company change, projects change and you may not stick as strictly to the road map as you would hope.

So we’ll start with the research intake process and including this road mapping process. What we do, at least with Square, we align research road map with the product road map. This is yearly, quarterly. It’s not a one size fits all. It’ll depend on what stage of the product you’re in.

So with the stakeholder alignment process we do is that we meet with stakeholders. We then ask about various aspects associated with these wants, and we then align on timelines, priorities in a general way, and we input that into a road map that can be referenced for all stakeholders.

Then the other way to intake these research requests is an intake form. This is a lot of the times a way to allow ad hoc projects that may come up outside of the road mapping process. So road maps change, projects pop up, and that research isn’t aware of, and we want to make sure that research is always aware of these projects. So who fills out these forms? It could be a product manager, it could be marketing, it could be designers. So we have them fill out the background objectives, the impact that they hope to see out of this project to allow us to see if this is a project that we would find value in partaking in.

So inputs to consider when scoping a project, the purpose. So consider whether the work is tactical, low level, reactive or strategic, and where in the product cycle it is, whether the work is, again, low level reactive, or whether it is strategic. So we ask these questions, why are we doing this? Why do we want to know? What do we want to know? Where are we in the product development cycle? Then we think about company priority. Who is involved? Is this a high company priority? Is this a low company priority? Then the timeline, is this something that research can actually get involved with? Does research have the bandwidth for this? Will we have time to complete this project in time for a potential decision and to consider the amount of time and resources that this project will take away from other projects? The level of involvement. How much research support is required? Is this something that research can just support in a way of reviewing research plans or help in other ways, or is this something that requires research’s full level of involvement?

Then finally we look at the priority matrix and how does this fit into that structure of a priority matrix? When I say the priority matrix, I mean defining the involvement can be impacted by this priority matrix, which we folks have probably seen before. If the risk is high and the problem clarity is very low, that’s where we would want research to focus in on as much as possible and have research heavy. Because of such a high risk and low clarity, research has a great place to allow itself to be a part of the foundational structure of a work stream.

Then finally, when we were discussing defining the level of involvement, one way to structure this is to think about a full service model versus a guidance/partner, and finally a consulting/self-serve structure. So in a consulting capacity, in a full service way structure, we’ll start with that is the researcher takes on the project from start to beginning and takes on every aspect of the project, including the research design. Whether if there’s a vendor that needs to be involved in this creation of discussion guides, recruitment, the field work, everything. Then when you’re thinking about it from a guidance/partner perspective, you may have a partner heavily involved with the research with you, whether that’s a PM or a designer who is involved with the structure of the research plan involved with taking notes and synthesizing the presentation. It’s more of a partner capacity. Then there’s the consult slash self-serve model, and that’s where a researcher may not have bandwidth at all to take on a project and they’ll advise on the research approach and review any questions, discussion guides, test plans, and help with every aspect of the study, but not fully complete it on their own.

Then how does this work in practice? So I’m going to have a quick example here from Square. So a case study that I have here with Square, and this is a project that particularly came up in a road mapping in our road mapping process. The larger crux of the problem here was that multiple teams wanted to better understand the needs and perceptions and jobs to be done of Upmarket sellers as it pertains to Square banking. So we started off with meeting with stakeholders and differing stakeholders because this was such a topic that covers different product teams.

Then we scoped out these different aspects that we need to consider as the inputs for scoping. So this spans multiple product teams and impacts overall strategic, generic, and strategy early in the product development cycle. Then it can influence strategy. It was also a high risk and low clarity project. So it allowed me to think about this as a covered all of the higher levels of these inputs and made me want to really push for research to be involved with this project and invest a lot of research’s time and bandwidth into this project, because of it hit all of the inputs.

Then finally because of that, we decided that this particular project would be a full service research project, and this project would require the full support and complexity and all the logistics and it was worth the researcher’s time.

So the impact and approach of this research, what we ended up doing was we did desk research/a literature review, which you see here on the left. Then we did a question prioritization workshop with all of the differing stakeholders. Then finally a third step in this project was that we interviewed specific sellers who fell into that Upmarket category. Within these three different stages, we presented all of this data in a research deck and did a company share out throughout these different stages and also did a final share out as we went through with the different stages of this research.

Then just to quickly go over other practices to build out. When we’re thinking about research, we all see the value of those foundational projects, but the iterative launch evaluative research stage is also important. We just went through a foundational strategic project, but evaluative research can be just as impactful and important, can be a major contributor to justifying the increasing of headcount and moving your team towards more researchers. So small, but meaningful impact. You don’t always have to take on those strategic foundational projects for full service involvement projects.

So this is just a really quick overview of other ways to expand your research toolkit to document new processes, create those research templates and onboard research tools and vendors that you can easily access when needed.

Finally, advocating for research throughout research findings, whether that’s research decks, newsletters, and a research repository, and finally research readouts. That’s it. Gets you to that stage of making yourself that much closer to that goal of being a fully embedded researcher.

Amanda Beaty: All right. Well, thank you so much. You finished just in time, so everybody got to hear your whole talk. Thank you so much for taking the time to join us and thank you to everyone watching, and we will see you in the next session.

Liliya Sabitova, a senior product manager, discusses the importance of aligning personal values, skill sets, and interests with the right company environment for career development. She emphasizes the impact of business models, company size, and product maturity on the work environment, and highlights the significance of company culture in job satisfaction and professional growth.

Transcript:

Liliya Sabitova: Thank you, Angie. Appreciate the very warm welcome. Hello, everybody. As Angie said, my name is Liliya. And before we start, a few words about me. I’m a senior product manager with 10 years of experience working in different company sizes, startups, SMBs, and enterprises across B2B and B2C business models and in different industries, data, travel, media, et cetera. I worked in four different countries, and now I’m a senior PM in a big tech company in the Bay Area, California.

First, a disclaimer. In my talk today, I’ll be sharing my personal opinions and not the opinions of the company that I work for. So now that it’s out of the way, let’s dive right into it. Earlier in my career, I was approaching career development on an intuitive level. However, I soon realized that to succeed, just a skillset versus the job requirements match is not enough. A career journey is not a one size fits all scenario. Some individuals are happy in large organizations and some are happy in smaller companies too.

And to be honest, I’ve seen the opposite happening as well, where people can be miserable in either of the situations. So how to know what will work better for you? From my perspective, it varies depending on multiple factors. So today, let’s figure out together how we can maximize our chances of thriving in a workplace. So let’s start with the first slide. I hope you can see it clearly. It’s a little bit small as I can see now. So it is an enhancement of paradigm. On your screen, you can see an example of the skills self-assessment wheel for PM, designer, and that developer.

So I spoke with Angie and she mentioned that most of the participants represent those three different roles. So the framework I initially saw in the Mind the Product by Petra Wheel, who is an independent PM consultant. So I duplicated this concept for the designer and also for a developer. So please take your time to evaluate yourself potentially after our talk today. So this is an abstract example, but let’s discuss how it works. Along the edge of the wheel, we have different skills for given roles.

For example, for PM, we have the execution, data literacy, market acumen, strategy, et cetera. The center of the wheel is connected to each of the skills with a line. In the wheel center, we will have a zero score, and where the line connects to the edge of the wheel, we will have a 10. Thus, a person who does the self-assessment decides how well the skill mastery is and rates oneself accordingly. In this example, we can see that a PM is proficient in execution. Thus, he gave himself 10 out of a 10 score.

However, that same person needs improvement in the feedback synthesis as it’s below the five score. I propose to use an identical approach to evaluate how different parameters of the workplace itself resonate with your values. Therefore, instead of putting the skills along the wheel’s edge, put values like work-life balance, opportunities for growth, recognition, supportive manager, et cetera. And note that your expectations and values will probably change in the different stages of your life.

So reevaluate when needed. By understanding what is important for you on the values level, you’ll be more equipped to make a right call when it comes to choosing your next career opportunity. You’ll have an understanding of what is non-negotiable for you and what is not that important and thus not worth the sweat. Also, keep in mind that you yourself can decide what values you want to put along the edge. So it doesn’t have to be what I have proposed, but this is a good start.

So I invite you to take an opportunity and do this exercise in your free time. So now let’s move on to the step two. The step two is the business model, company maturity, size, and domain. Naturally, all of us have different interests, so we’ll be gravitating towards certain industries. Knowing where your interests lie will also help with your longevity and happiness in any given company since you’ll spend at least 40 hours a week, which is about 62.5% of your non-sleep weekdays, excluding the weekends, on work.

So one example that I would like to propose is that I’m personally interested in data and I get a lot of fulfillment from working in this domain. On the contrary, right now my values do not align with a tobacco production companies, so I can’t imagine working in that domain for myself. You can also do a little bit of a reflection and think about which domains are interesting for you. The company size will also impact the work environment. Large companies can usually provide more stability.

However, you’ll have to deal with a negotiations as most likely there will be significant cross team collaboration since one area can be owned by multiple teams. Therefore, alignment and meetings and agreements are needed. So understanding this concept is crucial in order to make the right call for your next career move. For smaller companies, you’re more likely to avoid company politics. But at the same time, there are also challenges. You’ll be most likely constrained with the resources and the pace might be quite aggressive.

So when you are evaluating those types of opportunities, having and realizing that this will most likely be the environment where you will have to work will also be helpful to making the right call. Now, let’s discuss the business models. So here you have the table where I have outlined some of the key or the major business models. B2B refers to business to business. And in such a model, a company is offering products or services to other businesses. In other words, other businesses are your customers.

One example could be Atlassian. Among other things, Atlassian offers software for project management to other companies to run their processes. So if you will look at this table, you will see some of the nuances of work in such type of a business model, so it will involve a lot of negotiation. It’ll require understanding of the business needs. Because compared to B2C, you will not be able to try the product on your own. And most likely, in order to really understand the business pain points, you will have to talk a lot with your stakeholders.

Thus, comes stakeholder management. Also, ability to communicate complex ideas effectively will be important, because sometimes the decision makers and people who will use your product are actually two different user groups. Also, integrations of various business aspects and technology will be crucial because you will have to integrate with existing technology that business already uses. Now let’s talk about the B2C. B2C refers to business to consumer, and one example of such company could be the Spotify, a streaming service for individuals to listen to music and podcasts.

So as you can imagine in this type of company, there will be a very big number of users, millions, so it will be really hard to understand what users want barely from the user research. So for this reason, data literacy will be very important. Also, in order to validate the solutions that you have developed, just talking with your clients like in B2B will not be enough. And also seeing how many solutions were integrated is also not enough. You will have to run A/B tests for validations of your solution.

Then also, it’ll be crucial to have a very agile and flexible approach to adapt quickly to changing consumer trends. And finally, compliance. Especially in the US, user data is very much protected. So for this reason, whenever you would want to roll something out, you will have to go through a number of circles before you will be able to achieve something. And finally, the B2G refers to business to government, and one example could be Palantir.

It empowers intelligence agencies like US Department of Defense to securely derive actionable insights from sensitive data and achieve their most challenging operational objectives. So you can see nuances here, but we’ll move on for the interest of time. Finally, let’s discuss the work environment depending on the product maturity. So here you also have a table. Zero to one refers to products built from scratch, and the environment there will require frequent pivots and changes in direction as the product concept is still being refined and product market fit is being searched for.

For this reason, for especially engineers, it might be quite challenging to join such a company because something that an engineer developed before potentially will be changed or not used or severely altered. So for this reason, it may cause frustration. Also, it is a very fast-paced environment with a focus on quick iteration to bring concept to the market. Now let’s talk about one to infinity. One to infinity products referred to incremental improvements to existing product, and the environment there will be much more predictable and more structured.

Thank you for your reactions. And it will most likely include a lot of cross-team collaboration, specifically at the large companies. It actually quite closely related with a company size. Okay, and also there will be a big emphasis on enhancing user experience and adding value to retain the customers. So you will keep improving what is already existent so there will be much lesser ambiguity. Also, the scalability will be the major focus. Since for zero to one products, you’re not really interested in scaling your products just yet because you didn’t validate the problem that you’re solving for.

One remark that I’d like to make here is that sometimes in larger companies you actually can find zero to one initiatives. There will be some departments who are working on exploration. However, it is rather rare. And most likely in larger organizations, you will be working on already established products. So this is something to keep in mind. So for this reason here, I have a little icon with the eyes so that you can think about and reflect how comfortable you are with the levels of ambiguity, how decisions are being made.

Are they top down or down up? How is the pace in the company? What is the scale of the problems that you have to solve? What the collaboration structure look like? Because if you understand what your expectations on the comfort level, the longevity and your happiness in the company can significantly be increased. So now let’s move on to the next topic, which is the step three, deep specialization versus the broad skillset. When making career decision, it’s helpful to realize that with current life expectancy and social security retirement age, we’ll spend about 40 years in the workplace.

So it’s not uncommon that interests and career aspiration will change. So let’s talk about some statistics that is not mentioned here on the slide, but you still can look at some of the visualizations here. Baby boomers career change statistics in 2019 show that they held on average 11.3 jobs between the ages of 18 and 46. So given the longevity and pivots of careers and employee type framework based on areas of expertise, skills across the topics, and leadership could help understand the possibilities of expertise development.

If we really, really, really oversimplify it, there are two primarily path: the specialist or the generalist. So you can see here an example for the domain experts and also for the broad skillset representatives. Also, here I added a book that has been recommended by Bill Gates regarding those two different specialist type. So I would highly recommend for you to check it out. Let’s talk about the specialists. They give deep expertise and authority in a specific domain, making them sought after in niche areas and often commanding higher salaries.

However, they have some limitations as well. In job market flexibility and risk obsolescence, if their skills become outdated, they will face significant consequences. On the other hand, professionals with a broad skillset adapt more easily to various roles offering a holistic view of projects and greater job market opportunities. This adaptivity is valuable in the rapidly changing industry, but it may come at a cost of being perceived as less proficient in any one area.

So for tech specialists, it’s choosing between the specializations and broad hinges and aligning personal interests, career goals, and the evolving demands of the tech landscape. So evaluate for yourself where you see the most return on your time investment and make a decision wisely. Finally, I would like to talk about the culture and why it is so important. Considering a company’s culture is paramount when evaluating new career opportunities. A company’s culture encompasses its values, beliefs, behaviors, and the overall environment in which employees operate.

It significantly influences job satisfaction, engagement, and ultimately one’s success in the role. So let’s look at some data. So we can see here that happy employees are more creative and usually exceed expectations, when disheartened workers are 10% less productive. Why is this data important? Because if you are interested in your career development, it’s important to evaluate the company. Company evaluates you, that’s for sure, but you also should evaluate the company.

Does it match with your values, with your interests, with your comfort levels? And based on that you need to make a decision. Because if you will be happy, you will be much more successful in the company compared to the situation where you’re not happy, not fulfilled, and feel like your skills are not being put into good use. So speaking of the skills being put into good use, here we see that employees are 10% more likely to search for a new job if they feel their current job isn’t putting their skills to a good use.

So these are some statistics that you probably need to think about before making a final decision about [inaudible 00:14:17] All right, so let’s move on to the next one also about the culture. So aligning with a culture that resonates with your personal values and work style not only enhances day-to-day job fulfillment, but also fosters long-term professional growth. In environments where there is a strong cultural feat, individuals are more likely to thrive, contribute meaningfully, and sees opportunities for advancement.

Therefore, a thorough understanding and assessment of a company culture should be a critical component of any career decision-making process. So now for the conclusion. So navigating career development, and let me get to the final slide if you would like to connect. So navigating career development is a multifaceted journey and a one size fits all approach does not really apply to career growth. The importance of aligning personal values, skill sets, and interests with the right company environment cannot be overstated.

Whether it’s choosing between a startup’s agility or an enterprise’s stability, a B2B or B2C model or the thrill of zero to one innovation versus the steady growth of one to infinity products, each choice shapes your career trajectory. The key takeaway is to remain adaptable, open to learning and to continually align your career choices with your evolving professional and personal goals.

By focusing on transferable skills and being mindful of the cultural feat with potential employers, you position yourself not just for job success, but for job fulfillment, a crucial distinction in the long arc of a career. So here you can see some of the resources that I would like to recommend. Please feel free to scan the QR codes. The first QR code is my LinkedIn, so feel free to follow and connect. And also I wrote a Medium article covering this topic in case you are more of a reader rather than audio receiver.

So feel free to check out the article as well with all the slides provided there too. And in terms of the recommended resources, if you are struggling to understand what is important for you, I would highly recommend to find a mentor, and there is a really great tool for that. It’s called Meander. There you will be able to connect with mentors and professionals from bigger companies, smaller companies, different maturity levels, et cetera. So feel free to check it out and find a guide for your career.

Then also, there are a few communities that I have mentioned here. First one is the Product School community. If you’re a product manager, you can get a lot of support from your peers. It actually helped me a lot when I just moved to the US and was looking for my next job opportunity. So I highly, highly recommend this community as well. If you’re a designer, feel free to check out Friends of Figma community. They have a very broad number of directions for the different specialties within the design.

And finally, to read the reviews and know a little bit more about the culture, I would recommend to also check out the Blind and Fishbowl. However, take it with a grain of salt because people are much more motivated to share negative feedback than positive. However, you take much more risk if you do not know the negatives compared if you do not know the positive. So it’s much better to be surprised with the positive aspects rather than to be discouraged with the negative things.

So check out that as well. And finally, Levels.fyi to know the salary and benefits comparison. So that concludes my presentation. Thank you very much for your attention. Angie, back to you.

Angie Chang: Thank you so much for the excellent talk and all the resources that you shared with us today at Elevate. I encourage people to check them out and take a picture of that QR code, go to that link. We’ll be moving on to the next session. So thank you so much and we’ll see you in the next one. Bye.

Liliya Sabitova: Thank you.

Dominique Simoneau-Ritchie discusses the importance of the technical project leadership role in engineering teams. She highlights four key practices that effective tech leads use: understanding technical debt and defects, establishing automated testing frameworks, aligning with technical decisions, and setting up scaffolding for quick feedback loops.

Transcript:

Dominique Simoneau-Ritchie:

Thank you. Hi everyone. Throughout my career, I’ve led, coached and mentored hundreds of engineers leading projects, and at Lever, Wealthsimple and now Affinity, I’ve introduced a technical project leadership role. So today I want to talk to you about that and to provide… And the reason that I love to do this is because it provides engineers with experience leading projects and true ownership. And I believe that ownership helps us ship the highest impact features for our customers. Because as engineers, we’re uniquely positioned to understand how to implement features really quickly while keeping our codes simple and maintainable. And as such, I’ll highlight four key practices that effective tech leads use, many of which I learned by observing teams and tech leads and leading projects myself.

So first, a quick note on the role. Like many titles in tech, Tech Lead lacks a common definition. It may not even have the same role from company to company or even from team to team. I personally prefer establishing this as a temporary role for the duration of a single project. It creates more experience and more opportunities for people to gain that experience leading projects from a technical perspective, which in my opinion is a mandatory skill for wanting to progress from one level to the next. At Lever, we already had tech leads and actually a couple of them had burnt out because they led every single project at the time. And so I named this role Project Lead to really imply that it’s meant to last for the duration of a project. At Wealthsimple, we were familiar with the term DRI so I called it Tech DRI. And now at Affinity, I’ve introduced the role as a Tech Lead. In some companies you might be a team lead leading a project or in a smaller team, an engineering manager leading a project. So regardless of your title, if you’re leading a project, then some of these are your core responsibilities here and this talk will be relevant for you.

And for this talk, I’m going to choose to focus on the technology aspects of the role. And the reason for this is that no one else is going to ask you to do this. It might seem obvious that Tech Lead is literally the title, but many companies are very product driven and don’t naturally create the space or the expectation for engineers to invest in technology and so they end up shipping with lower velocity and lower quality as a result. As engineers, it’s tempting to start to plan work exactly the way that your product team thinks of it to get to customer value faster, because it seems faster, but often it’s not. And as someone leading a project, you have the greatest ability to ensure that we’re constantly improving our architectural foundations and the developer experience so that we keep being able to innovate and build quickly in the future and not just for one single project. Don’t wait for somebody to ask. This is a mindset that you can apply to any test that you’re working on, big or small.

So I’m going to focus on a few proven techniques to set up the technical aspects of your project in such a way that everyone on your team ships with high confidence and quality, by understanding tech debt and defects that will cause slowdowns and problems later, establishing automated testing frameworks, data and examples required to make it mandatory to add automated tests as part of every single code change, aligning with technical decisions across your organization to make progress against your engineering strategy, and finally, setting up scaffolding to ensure that all developers have quick feedback loops.

So let’s start with technical debt. It’s important to take a look at any debt related to the scope of a project that you’re about to kick off. In product management, we often do a thing called lit review, which is to look at all of the customer enhancement requests, user research, feedback that have come around this area related to the feature that we’re about to build to inform what we’re going to build in the scope. And here, from a technical perspective, we can do the same thing. So look at all the manual tasks to understand how to automate them, to remove the need or to build the feature into the product. So for example, at Wealthsimple we built a brand new mobile app that customers had to sign up and onboard into. And so as part of that, the identity team started looking at where they had issues with regards to identity and settings that they could fit into the scope of the project. And so we were able to move over tons of manual tasks related to customer profiles, both into the app, but also into internal tools when it didn’t make sense to have that workflow be part of it so that those tasks, instead of going to engineers, now were either completed by our CS team or customers directly, which also created a better customer experience.

You can also look at Rollbar, Datadog, Sentry, at your alerts and monitors to understand that there are a lot of performance issues, timeouts, 500 errors, things that are related to these areas as well because that will inform how you build your data models and what changes you might want to make as you’re building either on top or adjacent features to what exists.

Look at existing but also fixed bugs. Are there patterns with recurring bugs, like you’re constantly seeing the same one or something related to an area that might indicate that you haven’t really designed a state machine and you should because you keep having these one-off errors? Or are there maybe bugs that are hard to fix? We had so many bugs at Lever that had 50 customer requests that we had difficulty getting to because the feature hadn’t been designed initially to solve for something. It just wasn’t possible to do with the current architecture. And then similarly incidents, postmortems, maybe the action items that came from those. Are there any that are still not resolved or not done? And documentation. So maybe your internal documentation for helping developers get set up and work in that area of the code or public documentation on the feature. A lot of developers will Google, “How is this thing supposed to work?” when they’re working on a new feature for the first time. And looking at the customer documentation and updating it is a great way to do that.

Talk to your cross-functional peers and PMs. So don’t do this in a vacuum. Go do a quick review, see what exists, and then share your learnings with either the PM, the designer, your data scientist. They’ll be able to add missing context and they might have additional use cases from customers that help justify an increase in scope. And so this is really not a, “Oh, I’m going to go do all these engineering things all on my own.” This is truly about bringing your knowledge and the technical aspects to the table and making sure that you agree on what the right scope is for the project.

And also when it comes to tech debt, it’s a really good idea to pick one to three high priority bugs that multiple customers have requested and to fix them upfront. A lot of engineering managers actually already kind of do this without proactively planning for it. So they’ll know, “Oh, I think this person’s going to end up working on this area of the code next, so I’m just going to keep sending them bugs this way.” And so what I’m proposing is that you do this proactively when you kick off a project. And the outcome might be that you onboard really successfully and you get context in an area of the code that you didn’t understand before or didn’t know the complexities of, you realize why these bugs aren’t fixed, and you address that as part of the technical design for the feature that you’re now building. You didn’t design the state machine correctly maybe so there’s constant edge cases to address.

You might also just fix customer bugs that people have been asking for for a long time. And if you understand enough about where you’re going, you could potentially even be refactoring to make it easier to build on top of. And finally, sometimes the outcome will be, and I wish it wasn’t often the case, but you’ve identified something worth fixing, but it’s much bigger than you thought and it doesn’t really fit into the scope of the project. And that’s okay. That’ll happen sometimes, but at least you’ve learned and you’ve gotten context that’s going to inform what you’re going to be building as part of this project.

Now, automated testing, it’s also sometimes a debt if you haven’t done a lot of it. It deserves its own focus because it determines your ability to confidently make major changes in existing areas, but also to ship really quickly with high quality anything that you do within the scope of your project. You already probably know this, but these are some of the reasons that make it worthwhile to focus on automated testing, but not just to do it as part of your project, but to do it upfront. So not later, but really, really thinking about it proactively. You’re less likely to introduce regressions. You increase confidence refactoring your code. Your tests act as documentation for developers that are joining if you end up having developers joining later on, and then it’s easier to onboard developers because of that. And it’s required for continuous deployment, which even if you don’t do today, is eventually probably going to be required. And doing it now will help you as you increase your technical foundations.

And so when I say automated testing in terms of setting up your project for success, what I mean is everything required to make automated testing just part of every PR and part of every small piece of the feature that you implement. So that might mean an initial subset of stubs, mocks, connections to real data, at least one test of each type that you plan to support, maybe a unit test, an integration test, end-to-end tests. It could also mean test coverage. We’re building a brand new product, which is part of our core app and monolith at Affinity, and as part of that, we’ve decided to enforce a certain amount of test coverage because it’s net new, it’s really easy for us to enforce it pretty high right now. And so before we even build all of our features, we’ve put in place what’s required to make it possible to do all of these kinds of tests and to measure and get to, I think it’s a hundred percent actually, I don’t know if that’s too ambitious, but that’s what we’re setting it at to start.

And finally, and this is where it actually might feel not natural, put test cases in for existing features. And I have a really good example of this. At Lever, we started a project built on top of a feature called Offers, as in job offers to candidates, a recruiting tool, which was created over six years ago. Offers had very few automated tests, I think it might’ve been written by the founder. And getting into the right state to test required a lot of manual setup on your machine, which was really not obvious. And no one on the team had ever worked on Offers before.

So one of the first tasks that the tech lead assigned to someone on the team, so small aside here, you don’t have to do all of the things I’m talking about yourself, it’s really great to distribute this as part of the planning for your team, was to create two happy path end-to-end test cases for the existing feature. This had multiple benefits. The developers working on the tests learned how Offers currently worked. By running them automatically as part of continuous integration, we increased the confidence of all of the developers and also decreased the chance of introducing regressions. We established a pattern for our end-to-end tests, which made it easy to add new end-to-end tests as part of the project, finally, that’s the last thing we did. And so this is a really good example of the kind team leverage that a technique can generate when they empower everybody to contribute and they proactively plan for the type of technology and type of work that we’re going to want to do next.

So that brings me to engineering strategy. And you might think I work at a company that doesn’t have a strategy, but all engineering teams have a strategy, even if it’s accidental, not documented, or maybe only one team knows about it, maybe there’s one team making really forward-facing decisions and then they go in and they make these decisions. But the reality is your company’s probably in the midst of converting code to a new language, trying to standardize on a single design system, maybe they’re adopting microservices or componentizing a monolith. Everywhere that I’ve worked, we’ve been in some sort of transition. And I’d argue that if you’re not, you’re probably creating additional tech debt with everything you build. Technology changes and it’s faster and it’s easier to keep up than to have to invest in some sort of full migration later.

So here’s some example engineering initiatives to get you thinking about what you could consider as part of the scope of your projects. So migrating to a new language, whether that be TypeScript or adopting GraphQL APIs, upgrading to a new major version of a library which might introduce API breaking changes that need to be made, adopting a new design system. So at Affinity, we’re currently standardizing on a single design system. And so as part of every project, we determine whether or not we should migrate all the way and if we should reuse existing components that are in the design system or if we have to introduce new ones. Changing coding patterns across the code base, for example, updating JavaScript code to use promises instead of callbacks, or we’re abstracting a lot of our backend logic at Affinity into service objects instead of directly being part of our controllers.

Generally, one team will do some initial work to identify these initiatives, put in the foundations, and then maybe make a decision, but then we’ll need, at an engineering level, multiple teams to adopt these as we update the code. It’s really rare, even in big companies, that you’ll be able to have a dedicated team that could completely run initiatives independently. It’s just impossible. You could not update every single GraphQL API for a product with one team sitting over here because they don’t understand the product. It makes way more sense to do it while you’re working on the forward-facing feature than to go and rebuild the thing that already exists.

So let me tell you a story about three projects and three different tactics. A successful tech lead understands the initiatives that exist in the company and then the technical decisions that other teams have made, and they look for ways to integrate that work into existing project in a way that propels the project forward while still slowing it down as little as possible. And so a few years ago at Lever, we were approximately 50% done converting our CoffeeScript code to TypeScript. This is pretty basic. Now you would probably automate this in a much more efficient way. But, I think it’s a really good example of how different techniques empower teams differently. We were all in, we were definitely going to replace it all, but we were against tight deadlines. We had really small teams. We didn’t have the budget for a dedicated platform team at the time. And so we had three different projects and two different teams that used different approaches. In the first, we had a less experienced tech lead and we didn’t end up converting anything to TypeScript upfront. And actually, all of the changes were made in our CoffeeScript files. And I’ll tell you, it was slower because we had developers that didn’t have experience in CoffeeScript and then later we had to go back and change it all. So it felt faster at the time. It was not faster.

In the second, the tech lead set up a new TypeScript file for all of the new code and just referenced that whilst keeping the existing CoffeeScript code. That was made possible because it was a lot of new features that didn’t require modifications. And then the third, we decided to invest upfront and we converted the entire file to TypeScript and the team was way more efficient as a result. In the end, we finally invested in a single team getting ownership, but it was faster because of the work we’d already done.

That brings me to scaffolding. And scaffolding is all about generally setting everything up for your project when kicking it off. And the goal is to make any major refactoring changes, put in place what’s required for engineering initiatives you’re adopting, make it easy to do automated testing, and run locally and in production. And the most important thing is to think about what’s going to set up your team for really fast feedback loops. And that means a developer being able to test a single line of code and as quickly as possible validate that it works. The tighter the feedback loop, the faster and safer that code ships.

And some examples of this are manually testing locally and on staging, setting up your local test data with different states. At Shopify, when I worked on draft orders, we created a bunch of rate tests to create orders in multiple states. You could just run it locally and really easily see if what you had built worked. And then a whole lot of other things related to automated tests, like even just being able to run a single one as fast as possible locally will help. And then whatever’s required to push to production from day one, feature flags, etc. The goal of scaffolding is to reduce feedback loop time so that issues can be identified and rectified swiftly, enhancing the quality of the code and the pace of development. You go faster, but it requires that upfront investment.

To wrap up, a successful tech lead balances short-term engineering investments to boost team productivity with considerations for individual project impact and long-term maintenance and velocity. And when you do that, you take into account the tech debt that you already have, you establish automated testing patterns, and you align with technical decisions across the org to make progress against your engineering strategy. And finally, you set up the scaffolding to ensure that all developers have quick feedback loops while addressing all of the above. Thank you. I’m happy to answer, I think I have one minute for a question. I see there end-to-end and integration tests. I think you have to define these for your org. There’s no common definition. Thanks, Laura.

Amanda Beaty:

Thanks so much, Dominique, and thanks everybody for joining us. We are out of time, so we will see you all in the next session. Thanks.

In this talk, Tal Flanchraych discusses five tips for supercharging your resume to increase your chances of getting more interviews. Overall, the goal is to make your resume stand out within the first five seconds and make it effortless for recruiters to say yes to your application.

Transcript:

Tal Flanchraych:

Thanks so much, Angie. I am so excited to be here as a long, long time supporter of Girl Geek X, but since times of the essence, I’ll get started. So this talk is all about supercharging your resume, five tips to get more interviews. It is not about having the perfect resume, it’s about getting a resume that will get readers and recruiters to say yes after scanning it for just five to 10 seconds, which is oftentimes all you get. And in 2023 that looks a bit different. So I will tell you a bit about myself for context and then dive in. So Angie already mentioned a bit about my background. One fun fact, I was actually laid off from Indeed this year and that’s how I started ApplyAll believe it or not. I literally got laid off from a job board. Try sugarcoating that one on a resume.

And one thing I want to share is that a lot of these resume tips are actually backed by data we have from ApplyAll on real resume outcomes from hundreds of our tech job seekers. We’re seeing who’s getting interviews and who’s not, and looking at their resumes to see what do they do that’s getting them that, yes from recruiters to get a phone screen. So let’s start with some real talk, which is that your 2020 approach won’t cut it in 2023. And it’s not just because 300,000 job seekers have been laid off. That’s one of the reasons of course. But what it means is that beyond just more competition for each role, it’s really changed how recruiters do their job. And to truly understand how to approach your resume in 2023, you first have to put yourself in a recruiter’s shoes and understand how they’re looking at your resume in the first place.

So your resume in 2020. As I was a hiring manager in 2020 and helped build our startups recruiting team and we’d be lucky if we got even 20 or 30 half qualified applicants for a role. So as a recruiter, you’re screening the three that look superficially qualified and maybe two others that are interesting but have less traditional backgrounds, maybe could be good candidates in a different way, but really the pickings were often slim because a lot of the best candidates were sitting around waiting for recruiters to hit them up on LinkedIn. And oftentimes you would just pray that the hiring manager likes at least one or two of these people because it’s so hard to get good candidates. And so having a good enough resume is often enough to get you the role. And also resumes were read much more carefully.

However, in 2023 rather than 30 applicants, you might have 2000. And after you filter down to the 500 superficially qualified ones by matching against titles and keywords, you’re just trying to survive as an overwhelmed recruiter. So you’re scanning the first 50 resumes for five to 10 seconds each. See what’s their most recent experience, does it seem at first glance, within 10 seconds does it seemed relevant. Let’s flag the top ones and take a closer look in order to select the finalists. But only 10 to 20 resumes may actually get that close read to get to do that last pass and decide who gets the phone screen. As for the other 450, the truth is they’re either put aside or declined. It’s bad luck. Oftentimes one’s resume may just not be at the top of the pile and it might not be seen.

So what does that mean? My goal in saying this is not to discourage you, it’s about giving you the perspective that the recruiter has. So you know that you need to stand out not within the first 30 seconds, but within the first five seconds and help them check the boxes they care about at first glance without making them think or look hard. And what this enables you to do is increase your luck surface area. So while luck is a huge aspect of the job search in 2023 when there’s so many talented qualified people, it doesn’t mean you can’t create your own luck. Increasing your luck surface area means giving yourself more opportunities to get lucky. Whether it’s exhausting your network by speaking to every human being you’ve met professionally, applying to 500 jobs. But it also increases your luck surface area to make it a no-brainer for anyone to say yes to your resume after a quick scan if you’re qualified for that role. So let’s dive into the tips and how you can increase your luck surface area by making it effortless to say yes to your resume.

So the first tip, and this is the thing that I see wrong with the most number of resumes, is making relevance clear by providing critical context. So when I see something like this and it’s a company I’ve never heard of, all I can think is I have no clue how relevant your experience is to my role. Is this a medical device company? Is it a SaaS platform? Is it a children’s toy company? Is it a startup with 10 people or is it a multinational corporation? How do I know whether you’ve been in environments that look similar to my own and similar to that in my role, are you familiar with our business model? Right now, this is a real customer resume, by the way. I just have no idea.

But look at it now. Now I don’t need to Google aware to try to find out what it is. Oh, it’s an early stage AI SaaS startup with 100 employees and this candidate owned an $8 million book of business in a sales role, including four Fortune 50 companies, which means that he’s worked with large enterprise at a small startup. So if I’m hiring at a startup, suddenly this experience is looking a lot more relevant to me because it means this customer probably knows how to operate in low structure, high ambiguity, fast-paced entrepreneurial environments. Oftentimes candidates will remove context in order to keep things vague to keep their options open. But the truth is trying to be everything to everyone makes you an obviously great fit for no one. No one will give you a chance in this market if you leave them to wonder, they’ll just decline you and find someone whose experience is obviously relevant for what they’re looking for.

So what this means for you is for each of your roles, add one to two sentences to provide context for the reader, especially for companies or products that they may not be familiar with. Even if you work at Google, what division and product did you work in? What is the business model of that product? Because that may influence how much you can hit the ground running at this new role. And also remove friction for viewers to learn more about your experience. If they are compelled by this, they may want to learn more. Don’t make them Google it. These small kindnesses like giving them a link they can click on, make it effortless for them to learn more about you and make it effortless for them to say yes. And it doesn’t mean you necessarily even have to write a huge paragraph about what you did.

So for example, if I’m recruiting for an early stage healthcare startup, my dream PM may be someone who has that early stage PM experience in a consumer health company. So if I see this person’s resume, I can just by reading this first line, which is what six words about what this product is and the stage it’s at, I immediately know that this person’s experience is intriguing to me. And just their first bullet, which says that they’re the first PM hired says a lot about them, that they’ve spent a long time working closely with founders in that entrepreneurial environment and was able to successfully launch a product that I can look up myself if I want to see if this is credible. You don’t necessarily need to write paragraphs to give context. This is a very short resume section, but for a relevant company, this is going to be extremely compelling.

And also knowing what the business model was. In this case, a marketplace makes it very obvious that this candidate as a product manager is probably familiar with the metrics and KPIs we’re going to care about and how to measure them. So next one is supercharging one’s promotions. We haven’t all been promoted, but those of us that have really need to stop burying the lead. People do not make their promotions obvious. Being promoted is one of the things that can make you look most desirable. And so you want to flex that as much as humanly possible. So if you look on the left here, you’ll see that this person has two roles on their resume. However, by repeating the company name twice, that’s Definitive Healthcare in red, it’s not obvious at first glance it’s the same company and the person’s been promoted. Use hierarchy, visual hierarchy to make it crystal clear that you’ve had multiple roles in the same company.

So look on the right, for example. By having the company name further to the left and a very different font and the two titles underneath with the dates near them, it becomes obvious at first glance that this person has had multiple roles in the same company, thus has a longer tenure there and has also been promoted. So they must’ve been perceived as a high performer, which makes them more desirable. So this next one is about supercharging your status signals by prominently name-dropping. This applies more to people who have worked at any sort of name brand company or even a startup that a recruiter may have heard the name of a few times. The truth is, brands carry a certain amount of status or authority whether we like it or not, whether we think it’s justified or not, because people perceive brands a certain way.

Think of your own stereotypes when you hear that someone works at Google or OpenAI or even just a hip startup that you know is growing quickly but don’t happen to know much about. You might be more intrigued. Most people would assume that you might be more competent at your job if you’re able to get higher there. Again, whether or not this is true, these biases are real and recruiters share them. So if you’ve worked at a name brand company, make sure that name is high up on your resume, bold it, underline it, make it impossible to miss. You want the first thing someone notices on your resume is that you’ve worked at a company that they are familiar with, if this is true.

So these two resumes are from the same customer. You’ll notice that on the left, well, it’s hard to know what to notice at all. There’s so much going on. And when a recruiter looks at your resume, the first thing they look at is your most recent role to see how relevant and compelling it is to them. And the one on the left, it’s very hard to tell where the first recent role even is. And you have to look all the way down to the bottom half of the first page to see that this person was in a sales role at Oracle, which is a very respectable company, very prestigious in the sales field, but it’s hard to notice that. Whereas on the right this resume that actually has gotten this user and this candidate interviews Oracle, being underlined and higher up on the page is one of the first things that pops when you first glance at this resume.

So be sure that anytime you’ve worked at, whether it’s a big name company or a startup that they may have heard in passing, don’t make it hard to find because it creates a halo effect that may really work well to your advantage. All right, so this is another big one, which is supercharging your credibility using stories and specifics, not buzzwords. You’re competing with hundreds of people who are also using ChatGPT to write their resumes. And the thing with buzzwords is that it’s hard to turn them into believable stories about what you’re capable of and what you bring to the table.

So let me give you an example. When a recruiter or hiring manager reads something like this, they think, why should I believe anything that ChatGPT wrote about you? This looks like it was just copied and pasted from some template for 2000s resumes. It’s extremely generic and provides no evidence that you’re capable of doing these things. I frankly am just not going to buy it. Even if you throw in metrics. Everyone at this point has read the articles about stuffing every bullet with metrics and they oftentimes look and read, forced and made up.

Real impact isn’t always easy to quantify in a tidy way. And we all know that oftentimes these things can be hard to measure. And if you don’t provide specifics as to what you’ve actually done, what relatable problems you faced to get to these metrics, I’m going to have a hard time believing that this is actually true and you didn’t just make up these numbers. So to give you an example of something that shows impact with a story and specifics, look at this person’s resume. This is someone who worked in government but actually got interviews for for-profit startups. If you look at the bottom two bullets, you suddenly read something and you’re like, this was unexpected. Wow. 80% of the team quit and she had to accomplish this impossible task. And she provides specifics about the exact tactics she used to accomplish it. Notice she’s not using any buzzwords, she’s speaking exactly the way she might speak to her friends about this. And suddenly you have something that’s relatable and believable.

And now I see this person, I think, wow, this story doesn’t seem like it could have been made up. I need to talk to this person. They sound like a superhero. Even this last bullet shows a ton of impact without even one metric. So focus on telling stories about impact. Humans relate to stories. So I’ve actually left the most controversial one for last. It’s about supercharging your job titles. And that does not mean misrepresenting your level. It doesn’t mean that you are a front end developer and you add the word director to your title.

It means that you’re tweaking your title to make it easy for recruiters who are oftentimes not sophisticated or not familiar with your field to say yes to you and remove any uncertainty or doubt for them that you’ve held the responsibilities in the job description. So for example, I saw this resume, someone who’s worked at Salesforce and their literal title was member of the technical staff. I had no clue is this person junior, are they a director? Do they have reports? Because I’ve never seen this job title before. It’s a Salesforce specific title and I could not figure out how to place this person. But then I asked them to give me the title they would be given at any other company in this role. Oh, it’s software engineer, it’s an IC software engineer role. Okay. That makes it much more clear what you do without me having to carefully read your bullets.

And as a recruiter who is not always an expert engineering, it’s very easy for me to match this title to the job description and assume you must be superficially qualified by your title alone. And so as I mentioned it’s unethical to completely misrepresent what you did, but to tweak your title to remove uncertainty is totally okay. Think of is it something you could defend in a background check where you’d feel comfortable explaining the situation? Put yourself in the shoes of a hiring manager. Would you feel lied to or would you understand? So for example, one example I give our backend developer versus software engineer, these can be used interchangeably at a number of companies. So if you want to create a variation of your resume that has your most recent role as software engineer instead of backend developer,

Angie Chang: [inaudible 00:18:42]. Sorry,-

Tal Flanchraych: It’s very [inaudible 00:18:44] explain for a background check. All done. All right, well it was,-

Angie Chang: I’m sorry. It’s time. Thank you so much. That was an excellent talk. I’m sure everyone’s going to want to connect on LinkedIn with you. You can share your slides and any resources there. Thank you so much. All right.

Tal Flanchraych: Of course. Got it. [inaudible 00:19:01]. Thanks so much everyone.

Sophie Novati, the founder of Formation, discusses the importance of understanding system design in engineering interviews. She explains that system design interviews test high-level problem-solving skills and real-world engineering experience, and emphasizes the importance of asking questions to understand the limitations and scope of the problem, as well as identifying technical challenges.

Transcipt:

Sophie Novati: Thank you so much, Amanda, for that wonderful intro. Thanks for everyone else for also being here in today’s session with me. I’m super excited to be here with all of you today.

And before I start, just wanted to say that please do drop questions as you have them throughout this talk. I know we don’t have a ton of time, but I’ll try to leave at least a couple of minutes at the end. And if not, I will definitely try to follow up with written or Looms or something, follow up to answer any questions that people have. Please ask them.

I think we mostly went through the intro already, so I’ll say hi again. I’m Sophie. I am the founder of Formation. We help people land top-tier engineering roles. This is just a really important topic for me because I remember starting my career as a software engineer at Facebook as a new grad just thinking that engineering was about just solving weird algorithms all day and coding, essentially.

And I distinctly remember throughout my career from Facebook to Nextdoor progressing to a staff level engineer transitioning into the mindset from being just a coder to being an engineer, which is really about building products that are actually changing the world and solving real user problems. And I think that this shift was the single most important change in my mindset that helped me become a way better software engineer, but it also made me just enjoy my work so much more. And I think that system design, understanding how your entire system works and the information, how it’s all flowing through the system to go from user input all the way to user response is very much part of that picture of progressing in your career as a software engineer. So anyway, to add a little bit to my background as well, I was one of those people that was very, very involved in our interviewing processes.

I was one of those people that did hundreds of interviews and I was very involved in thinking about diversity and onboarding and all things just bringing in new, great engineers related. And prior to starting Formation, I mentored at a bunch of different training programs trying to figure out why there was such consistently a skill gap I was seeing as an interviewer on my teams. And so I really started Formation because I just love the space and really want to spend my life hoping to create an impact in there. So I’m super excited to get to do this talk today. So today’s agenda, wanted to just really introduce you to the system design interview format. And this is roughly going to be the agenda. Obviously, it’s only 20 minutes, so you’re not going to become an expert at this at all by the end of it, but hopefully it gives you a little bit of sense of direction where to go.

So I want to start with talking about why system design as an interview format even exists, and from the perspective of your interviewer, what are they looking for, what are they thinking about? And then we’ll go through and we have this thing called the engineering method at Formation. And I’ll roughly just break down some of the stages of a system design interview. Note that these aren’t just orderly, like you do this, then this, then it goes back and forth between steps, but you slowly transition your way through these steps. And I’ll walk through an example as well. And then finally, I’ll leave off with a little bit of how do you actually prepare for this, knowing why it’s being done and what it looks like. Okay, so let’s get started. So the first thing is why systems design? So I think most people are usually familiar with coding interviews, so I’ll make a couple analogies.

But coding interviews, it’s really about testing fairly practical day-to-day coding skills. Now, I know the problems are oversimplified, so they’re not actually real problems that you’re solving, but it is fairly practical in that it is testing a skill that you will be executing every day, which is coding or most days. And system design is very much not that. It’s almost the opposite. It is really testing for high level problem solving and it is less practical because you’re not going to be building anything during a system design interview. You’re just going to be talking about a system in theory. And so it’s very high level problem solving. It’s testing for a lot of real world engineering experience, which is very different from coding, and so it relies on a little bit more theoretical stuff. And sometimes the system design is also meant to test for specific tech stack experience.

And this is sometimes, not always. Usually for specialized senior roles, system design will be very, very important because they might be looking for an experienced engineer who has worked with finance software specifically or security or some amount of obscene level of scale. And so for this in general, this is why I think it’s actually quite important, especially as you progress into your career, to really look at the job descriptions of the roles that you’re applying for, especially at these big companies where there are many job descriptions for the same level and each one might have a different thing because the different team needs a different skill.

And even if the interview format, like schedule is the same, like coding, then system design, then hiring manager interview, whatever the schedule is, the system design might heavily be influenced in terms of what the person is looking for based on the role that they’re trying to fill. And so really, system design also is the big seniority differentiator. So with a coding interview, it’s actually quite hard to disambiguate between a senior versus a junior engineer, but system design is where it’s at. And really, I like to say that it is trying to get a sense of how battle-scarred you are and the scale of problems that you’re really used to worrying about.

Okay, so how are we doing? So that’s the why behind system design. So let’s progress into the actual interview format itself. So the first step of the system design interview is somewhat, I find the scariest, to be honest, because it is often the time when you have the least amount of information. So classic system design interview, it’s like, hey, design Coder Pad and it is just incredibly open-ended and that’s it, that’s the prompt. And then you’re let go. And there’s a moment of just uncertainty because you don’t even know what problem you’re solving yet, yet you’re solving it. And so this step is really about discovering the limitations of the prompt on your own. And as part of this, you have to discover what is in and out of scope to be solved in this interview. And this is much more important in a system design than even in a coding interview.

This is an important step there, too. But you really want to be asking all kinds of questions and make sure you’re thinking about the system both at the macro level. So how many users are you supporting overall, right? What’s the scale of the system as well as the micro level? So what does the end to end end-to-end user flow look like? And the challenging thing here is that you don’t have infinite time, and so you also want to make sure you’re strategically asking the right questions in a binary search format so that you can quickly hone in on what it is that you need to focus the rest of your time on in this interview. And so quickly, to give an example, let’s go use our Coder Pad example. So what are some questions that you might ask for this? You might first ask, well, what coding languages does it support?

So briefly, what do you think about this question? I think that this question could be better, especially if this is your first question. And the reason is that by asking this first, it is implying that I think this is one of the core challenges of this problem, right? It’s like setting a code pattern. What coding languages does it support? And it’s like, oh, is that the most important thing? And I would say that this at the highest level actually feels like more of an implementation detail even though it’s a huge project to support many languages. But when we’re first starting off and slowly starting to expand breadth or depth first search of the problem space, it just feels like an oddly specific thing to ask about.

So a better question might be, Hey, do we need to support real-time collaboration? This is a fantastic question because it is immediately getting to the heart of why this prompt might be extremely challenging. If the answer is yes, we know we’re going to be spending a lot of time thinking about the idea of supporting real-time collaboration. And a few other good questions here are do we need to support code compilation or is it just display only? Do we need to be able to run structured test cases? Some things, like I’ve seen some products where you can input test cases and then it runs and tells you if it’s correct or not.

And then last one is, do we need to protect against anyone writing some kind of malicious code? Quick note on this, I oftentimes see junior candidates shy away from this phase because I feel like they’re nervous or panicking that they won’t be able to solve the problem they’re asking about, so they almost want to ask about things they are more comfortable with. And I would really urge you not to do that. Even if you have no idea how to do something, identifying the problems themselves can sometimes be just as important as identifying the solutions. And in fact, sometimes it is not an expectation at all for you to know the solution, but simply to identify the problem. I’m doing short on time, so I’m going to skip a little bit of the explanation as to why. But really here, focus on identifying where your major technical challenges are going to be through your questions.

And from there, we do have to come up with some form of solutions, right? And an important thing to keep in mind here is that there is no right solution for any problem and especially, especially in the system design interview. So try to reduce your stress. This is a conversation, not just a test of getting the right answers all the time. It is not about that. In a great system design interview, in fact, you should be offering up solutions and immediately almost critiquing your solutions to break down where the problems are. And I think I see people not doing this because it’s almost like, oh, well, if I attack my own solution, then I am not defending it and making it seem like the right answer. And that is very counterintuitive, but the right way to think about it. For example, let’s say we’re thinking about how to do session replay on Coder Pad.

And so the first thing that you’re doing is you need to be able to show edit history. And so it means that instead of storing the whole text document, you also have to store every single change that the user has been making in order to play it back in session replay. And so the second you think of this solution, you’re like, well, what’s wrong with this solution? What would cause this to be a problem or create a scaling bottleneck? And just a really simple one to me is now we’re storing a ton more stuff. We have to store maybe in a database every single character change.

And then there’s a lot of follow-up questions immediately. It’s like, okay, well, how long do we need to store this for? How much time afterwards do we support session replay? Do we have to be as live as character by character? Things like that. And then the answers to those questions can then inform the solutions that you choose. So from there, you have identified some problems, created some solutions, critiqued those solutions, and this is also a very hard step. I see people not doing this, which is making recommendations. Again, I feel like people think that we need to produce correct answers, and I almost see people asking the interviewer, do we do this? Is that the right answer? And actually here, in coding interviews, I would say it’s somewhat just about the execution sometimes because you’re producing correct code, but in system design interviews, you are literally being tested for your judgment. You’re being tested on which choice that you make.

And so the more decisive you are able to be and the more you’re able to create rationale for why this is a good solution, you don’t even have to have the best solution. It’s possible that you have other ones, the better it is. And by the way, a lot of times you’re going to make recommendations and your interviewer might challenge those recommendations. They might say like, well, what about this? And that does not at all mean that you’re doing a bad job. If you’re able to respond to it, then all you’re doing is participating in a very healthy engineering conversation, which anytime you’re working on products as an engineer on a team, that’s what you’re doing. You’re constantly being like, what about this? Well, that has this problem. What about this then? Well, that has this problem. Well, how about let’s approach it a totally different way?

And that’s how you battle test the solution that you want to implement. Okay, I’m not doing good on time. Making recommendations. Final thing is verifying your solutions. This is also I find a skipped step. So you just get to the end of the interview and you are starting to just say like, oh, we’ve done all the parts. From here, I would recommend for you to take a user job to be done and really show it how each user request will flow end to end through your system. I forgot to mention, actually, earlier step one, when you’re asking questions, by the end of it, you should have as output a list of requirements, product requirements, system requirements for the system that you’re building. And when you have that requirement, that should be written up so you can see it in the interviewer can see it the whole time.

And if you’ve done that, then here in your verified solution step, you should have a fairly easy job and you basically just want to go through each of the requirements and verify that your system supports the thing that you decided was a requirement. Okay, I have two minutes. Okay, so how do we prepare? So I want to talk about things that I’m seeing people not do. So I already see a lot of people reading and consuming a lot of material that is very theoretical. And by the way, all of that is super needed. There’s a lot of great fantastic resources on system design out there that I highly recommend to people. So what I want to share to add on to what people are already doing is I have a very strong sense that the most important thing to develop here is real engineering experience.

And you don’t necessarily have to be the person experiencing it, so you don’t have to be on the teams doing it, but you can really accelerate your growth by reading, learning, hearing about other engineers solving problems and hearing about their battle scars. So things I’ve recommended, reading engineering blogs from other top companies, talk to other engineers, build a diverse network of engineers that you can speak to and ask them, what are you working on? What are some of the challenges of that? Are you guys using AWS technology as well? Why or why not? And this is I guess the long-term solution that I would like everyone to do more of. In the near term solution, I think that system design, you can only bridge small gaps in a short period of time. And so for that, my top recommendation is don’t just consume in theory. System design is an entire interview of talking.

And so practice talking about real solutions. Super specific recommendation is find a friend, an engineering friend, come up with a prompt that is something you are familiar with, like a problem you have solved yourself so that you know it pretty familiarly. And then have your friend do the same thing and then trade stories. Okay, so I see that Amanda is back here, which means that my time must be just about up. So I am putting up my LinkedIn. Please feel free to connect with me and I would love to answer any additional questions. I’m taking note of all of the questions that are here and I’ll be more than happy to send follow-ups on any questions that you guys have. I’m so sorry I didn’t plan my time better, but it was wonderful being here with everyone. Thank you so much for your time. And Amanda, I think that is…

Amanda Beaty: These questions may disappear for you when we end this, but we will collect them and send them to you if they do.

Sophie Novati: Yeah, okay. That would be fantastic. Let me try to take a quick screenshot. Here’s a couple of good ones, but yeah, if you could send them to me, that would be fantastic.

Amanda Beaty: All right. All right. Thanks, everybody. We are out time and we will see you in the next session.

Sophie Novati: Thanks, everyone.

In this session, Agatha Agbanobi discusses the racial implications of psychological safety for people of color. She shares how psychological safety takes into account systemic oppression and how community building can foster psychological safety. The session focuses on three objectives: discussing a popular teaching of psychological safety that excludes people of color, exploring an equity principle for differentiated solution design, and examining a skill for cultivating psychological safety through an anti-oppressive lens.

Transcript:

Agatha Agbanobi: Hi everyone. Welcome to this session about the racial implications of psychological safety for people of color. My name is Agatha Agbanobi and I am a DEI consultant, coach and founder of the DEI firm Relevé. And I’m excited to be engaging with you all today on this topic. So I’m going to provide a brief intro about me, my background, and my approach before we dive into the session itself. I’ll quickly just say that I’m a former educator who was heavily focused on education equity work both internationally and also stateside. Specifically in Texas for many years before transitioning to focusing on team and leadership development for diversity, equity, and inclusion in the corporate workspace.

The three guideposts that generally lead my work or guide my work, I should say, are anti-oppressive or liberatory frameworks, systems change and community building. And I want to say that these are the guideposts specifically for how I frame my work on psychological safety. So some of the questions that I like to frame around this question is, how does psychological safety take into account the interpersonal and systemic oppression that people of color are those who face identity-based oppression? How does that take into account that oppression due to historical and present day context of systemic isms?

And then how do we leverage community building, coalition building to build psychological safety within ourselves, individually, self to self, but then also within community, with others across differences? So today we’ll be focused on three objectives. First, we’ll discuss briefly one popular teaching of psychological safety that excludes the experience of racialized individual or people of color. We’ll talk briefly about a crucial equity principle for supporting differentiated solution design for psychological safety, and then we’ll explore one of the skills for cultivating psychological safety through an anti-oppressive lens.

So the first question I want to pose you all is this. How do you define psychological safety in a teamwork environment? Go ahead and drop your responses in the chat and then also take a moment to see what your peers have said. See if anything resonates. So here’s just some of the common and well-known characteristics of psychological safety at work. So team-orientedness is one of them, being willing to take interpersonal risk or feeling that you have the freedom to do that, having mutual respect or experiencing mutual respect within your team from other team members, having the freedom to challenge the status quo.

Having the freedom to share your knowledge, ideas, ask questions without fear of retaliation or any sort of reputational risk, feeling like you matter to the team and the organization, more broadly. Inclusion, belonging, that sense of feeling included, feeling like you belong and mattering to your team. Feeling a high sense of value, having the permission to make mistakes and to fail again without risk, a reputational risk or just fear of folks viewing you differently. And then also the permission or freedom to learn without limit. So a lot of these definitions come from well-known researchers and practitioners like Amy Edmondson, Christine Comaford, Timothy Clark, and even mental health experts and therapists such as Nedra Glover Tawwab.

One of the popular frameworks of psychological safety I want to kind of zone in on is Timothy Clark’s four stages of psychological safety in the workplace. It begins with inclusion safety, which is the feeling of being included, and then it moves on to learner safety, which is safety to learn. Then contributor safety, which is safety to contribute. And lastly, challenger safety, which is safety to challenge the status quo. All without fear of being embarrassed, further marginalized or punished in some way. And so this definition, of course, sort of assumes that everyone is starting off at the same level of psychological safety in a way when they come into the workplace.

And while these definitions lay a foundation for psychological safety within a work environment and/or within a team, it’s really important to understand that our racial and intersectional identities are playing a role in what it takes for us to really feel psychologically safe when we arrive at the workplace compared to our white peers in any given work environment, and especially in industries like the tech industry that are historically racially homogenous. And so I want to pose this next question for you all then, since I’ve brought up the racial implications of psychological safety.

How do you think that your racial identity has affected your sense of psychological safety at work in the past in a way that maybe it’s not affecting your white peers? Go ahead and drop your response in the chat. And so as you all are dropping your responses in the chat, I want to just remind you all about racial identity, the different layers of racial identity. I think a lot of times when people think about race, they think of it in sort of like this one track lane or this single lane where it’s just race or your racial identifier. So Black, Latina, Asian, Asian American, so forth. But it’s way more than that.

There’s so many other layers to one’s racial identity that impacts how accepted, included, valued, and overall psychologically safe that they feel at work. So there’s the racial and ethnic group that one belongs to, that sometimes it’s incredibly visible and sometimes it’s not. Sometimes we can make assumptions, but we’re not always clear. We always have to verify with the individual. The other part is, the other layer is skin tone, how light or dark one skin tone is. The other is facial features, how closely aligned one’s facial features are to typical western features. The next is hair texture, how closely aligned one’s hair texture is to thin, fine hair textures.

That is usually what you’ll find in western parts of the world, even in Southeast Asian cultures. And then sometimes one’s nationality is another layer if that primary nationality is a global north nationality or a global south nationality. So all of these layers of one’s racial identity, sometimes it’s incredibly visible. I can say that if someone was to see me in person, they would probably be able to pinpoint that I am a West African woman. They can see that I’m dark skinned and darker skinned than most. My facial features, of course, are leaning more towards West African features and so on.

They can deduce that I belong to a Black racial group and so forth. The key here is that there is a racial hierarchy. That the closer one is to some of these aforementioned characteristics like lighter skin tone, being in some of the racial groups that are higher ranked, right? So white folks felt like people being at the top, and then Asian folks, then fine hair in terms of hair texture and so on. And so the closer one is to the top of that racial hierarchy scale, the less systemic and interpersonal racial oppression or biases and discriminations they’re going to face at or outside of work. So I want to emphasize that there are layers to racial identity, and there is a racial hierarchy that exists.

Another example is lighter skinned Asians and Asian Americans are often thought to be at the top of the racial hierarchies, second only to white folks in the west and white Europeans, white Americans. Because of the model minority myth, which of course stems from the racial tensions of the 1960s when civil rights movements were underway and the battles being fought in Asia during Vietnam War was on the minds of everyone. And there was a prevailing narrative that Asians were able to succeed in spite of all the hardships, but Black folks weren’t able to do that, quote unquote, and only complain and protested about their inequalities that existed.

And then another example is that you also have darker skinned Black people. So not just thinking about race, we’re also thinking about colorism, right? So you are going to have darker skinned Black people who are thought to be at the very bottom of this racial hierarchy. And it just continues in terms of facial features, leaning more towards where typical Western features or more towards Afro or African features. And all of that impacts how folks are experiencing the world that we live in.

So I’m going to break down what exactly systemic and interpersonal racial oppression is, how that sort of manifest. There are three ways, or some of the ways, I’ll name three. One of them is unnecessary suffering. So we’re constantly going through unnecessary suffering because of how we’re perceived racially. The other is inordinate use and depletion of energy. And I’ll dive a little bit more into that in a minute. And the last is social and systemic undervaluing. We get all these messages from the media, from people, even in our social groups, that somehow our value is less than folks who are at the top of that racial hierarchy.

And of course, it impacts the opportunity gap, career wise, education wise, it just impacts every aspect of our lives. And so the phenomenon I want to focus on today specifically is the inordinate use and depletion of energy and what that means. So you’ll see here on the screen that I have, the first person here on the screen has identity safety, and I’ll explain that in a minute. And the second person has a couple of things that probably is taking up some energy, that they’re navigating in the workplace aside from their regular job. And then the last person is maybe more closer to the bottom of the racial hierarchy or the racial scale.

And so they’re experiencing even more. They’re having to expend more energy just to exist at work in a way before they can even begin to feel like or think about their sense of inclusion, their sense of belonging. They’re navigating these other things as well as their job. I do want to also note that these different scenarios and examples that I’ve pulled are still kind of general because different racial groups experience different types of microaggressions and microinvalidations in the workplace. There are some that are very common for us and then across racial groups or non-white racial groups.

But then there are some that are unique to, for example, Black and African-Americans in the workplace. There are some that are very unique to Black immigrants in the workplace. There’s some that are unique to Latin or Latina individuals in the workplace and so on. So you get the picture. So looking at the first person here, identity safety. Identity safety essentially is the idea that one feels incredibly safe in who they are and how they show up without any effort, right? That they aren’t having to navigate different belief systems, scenarios, and situations that are constantly making them have to prove their value and their worth and their right to exist in a particular space and in this situation, the workplace.

And so when we look at this right here, the second person, the different aspects of their workday, these are just examples that they’re navigating that is taking away energy from their energy at work. One of them, an example is you show up to the workplace, your office, and you show up there all the time. Maybe there’s a new security guard. For some reason he doesn’t believe that you actually work there, even though you’re showing him your ID badge, he’s assuming that something is off or maybe you forgot your ID badge and you are trying to navigate, calling your manager and all of that. And so they’re giving you maybe more of a hard time than they might give someone who is lighter skinned or someone who is white.

There are a lot of real life stories like that where folks question folks of color who are at the workplace, they question whether they’re actually really working there or they mistake them for the janitor or whatnot. The next I want to talk about is different microaggressions that, specifically I would say maybe more so women of color experience microaggressions about our appearance, right? Example for black women, it’s often about our hair. It’s often about our makeup or what we’re wearing. And then another one that’s pretty prevalent and definitely you’ll see this on the racial scale.

This is something you will see specifically when you think about colorism and racism. The only feedback that one might be receiving after a presentation or a project is probably more aligned to their personality or how they conveyed their ideas during the presentation or how they worked with the team. It’s not actually about the content itself. Some of the meaty things that actually matter. We often find ourselves having to ask for that feedback, having to advocate for more critical and constructive feedback about the core goals of projects or the core goals of a presentation.

And then you’ll see in the third row, we have some other examples in there. And I also have there too, advocating for more actionable feedback. Other feedback that women of color get specifically darker skinned women of color or Black women is not actionable. And there’s a statistic on that in an article I did for HBR. Don’t quote me on it, but I think it’s… I’m going to say it wrong so you got to go back and look at my article. But compared to white men, we’re getting way less actionable feedback at work. And so all of these things are affecting our energy in the workplace and how we show up for the work itself.

There’s a term that we use now called weathering, which describes the high effort coping mechanisms that we are using to manage the constant stress of racial biases and discrimination that may lead to, of course, premature biological aging, poor, physical and mental health outcomes. And also just our ability to show up fully a hundred percent at work. And so while this term originated from a study to describe the unique stress from racism, that Black, especially dark-skinned Black people face, other racial groups at the bottom of the racial hierarchy arguably are facing some level of weathering as well.

So we’re constantly weathering these daily or unique incidents of racial biases and discrimination inside and outside of work. So quickly just let us know in the chat how are you able to relate to this. Have you ever noticed a difference in your mental or intellectual or even emotional energy when you are in an environment where you feel safe in your identity? So not when you don’t feel safe, but when you actually do feel safe. It doesn’t necessarily mean that you have to work in an environment. What I’m talking about doesn’t mean that you have to work in an environment where everyone looks like you.

But rather it’s that everyone possesses a high skill in navigating and this is all about cultivating equity, leveling the playing field, cultivating that sense of belonging, community and inclusion where everyone possesses, not just leaders, but also team members. A high skill in navigating relationship care, trust, safety, and safety with individuals of different identities. So what does this all mean, right? It means that there are elements to our sense of psychological safety as people of color that we have to confront before we can feel inclusion safety, learner safety, contributor safety and challenger safety, for example.

We first need to get over that hump of identity safety. And I think it’s also important to note here that we have to determine for ourselves how much responsibility we hold within ourselves to give ourselves that level of psychological safety. And then how much responsibility do we need to hold the organization and our team accountable to in securing that identity safety for us. So we’re not constantly having to navigate and spend energy defending our right to be in a space because of who we are. So now I want to briefly focus on what is within our power to get to identity safety for ourselves.

We have to definitely recognize that there is a role that workplace leaders, middle managers, and peers play, like I said before and there’s also a role that we individually play in getting to psychological safety for ourself. In looking at this specific category or phenomenon of systemic and interpersonal oppression that is identity-based. This category of inordinate use and depletion of energy. We can be reflective and strategic about how we use our energy or how much effort we decide to use to cope with different incidents and issues. And so what I’m talking about is sort of taking some of our power back.

And what I really mean by this is that we need to get in the habit of taking stock of what depletes us in navigating and in coping, and how it depletes us, what type of energy or effort it takes to get over the different humps or the different things that roadblocks that come into play at work. And then plan accordingly so we can be our best in the workplace. So what routes or peers do we need to avoid? When I say routes, I mean when we’re walking to our office, for example, what routes do we need to avoid? Who do we need to avoid? So think about peers.

And then when do we need to be sure to avoid them, right? For example, if there’s a big project coming up and you really want to make sure that you are conserving your energy as much as possible to complete it. You’ll definitely need to be mindful of how much energy you use to navigate different identity-based issues or conversations, whether they’re project related, team culture related or not. And this is one of the reasons why people of color, statistically, people who experience the most microaggressions at work in the workplace prefer working at home.

They’re not having to navigate these different barriers, specifically interpersonal barriers at work in order to do their job. So your emotional energy and positivity for your sense of self impacts your intellectual energy to fully show up, like I’ve mentioned before. All the studies show that you have a higher chance of reaching your full professional potential and become really good at a specific skillset if you are able to set the right boundaries for yourself. If you are able to really be careful about how you’re using your energy and if you’re very intentional about exercising your self agency.

Another example for me is just a personal one. When I’m working on a big presentation, I tend to limit my interactions with people in person, but specifically folks who I know who have been racially microaggressive in the past, even if it’s just subtle things that maybe they’re not aware of, that’s subconscious that I just sort of let slide because not everything warrants a crucial conversation. Those people, I’ll tend to just avoid that. Sometimes when I say communication interaction, this also includes email and phone communication and sending a nice message. Letting folks know that I’m working on something right now and I’ll get back to them at a later date usually works just fine.

So there’s definitely… This is very high level. There’s a little bit more to this, including how you communicate your boundaries to different types of stakeholders at work, because it’s not one quick broad brush stroke, but how you’re setting and communicating those boundaries without having to even use the word boundary is something that I’ve dove deeper with clients. And then also thinking about how you are communicating it in a way that sticks and is sustainable for folks no matter what type of work environment you’re in. So we don’t have much time to go into all of the details of that today.

But I hope this provides a good snapshot for you of a crucial skill when we think about cultivating psychological safety, which has the key, I want to say, core factor identity safety for ourselves in the workplace. So to quickly recap some of the key points or the main key points of this session today. The first one is feeling safe as we are in our identity is the primary stage of psychological safety for people of color and/or those who face identity-based, systemic and interpersonal oppression.

The other key idea is that one of the key pillars for cultivating psychological safety for ourselves is taking back some of our agency and being strategic about how we use our energy, knowing we have a limited daily supply compared to others because we’re not just dealing with what’s at work, but also outside of work in terms of social and systemic identity-based privileges. Or you could go the other way in terms of biases and discriminations that were confronting it or fielding every single day. So as we wrap up, I want to ask you all, what are some of your key takeaways?

Research says that if we’re able to clearly share new knowledge with a peer or even practice what we’ve learned after a session, the more likely we are to remember, internalize and even practice it. And so I’m going to ask you all or challenge you to find a friend or a peer who might be interested in this topic. Tell them about this session and tell them what is still circling around in your head that’s not quite clear, or that you have questions about. What do you understand now that you didn’t understand before?

And then what is one takeaway that you think you can start applying immediately as you navigate the workplace? And then lastly, if you’d more presentations like this, of course, feel free to get in touch with me. Here’s some of my information. And that’s it for today. Thank you all so much for engaging with me in this session. I hope that you all were able to take away some key nuggets, and this really sparks the conversation further about the racial implications of psychological safety at work. Thank you so much. Bye.