“Is Crochet Turing Complete?”: Christina Burger with Runway (Video + Transcript)

In this ELEVATE session, Christina Burger (Runway Senior Software Engineer) discusses the intersection of computer science and crochet. She explores the idea of representing a Turing machine as a crochet pattern and demonstrates her attempts at creating crochet symbols for the different states.

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

Christina Burger ELEVATE Crochet is Turing complete

Transcript of ELEVATE Session:

Christina Burger:

Thank you so much. What a wonderful intro. I guess that makes my next slide less relevant. I’ll just introduce myself quickly. I’m Christina. I not just love making software, I also enjoy all sorts of other things, including hanging out with my cats, who ignore me, and also, I have a art supply shopping problem, which has recently extended into a yarn buying problem.

I also recently made a zine with my good friend Erica, and I’ll tell you a little bit more about that at the end if we have time. All right, so this is where you find yourself at the intersection of computer science and old lady crafts. I really love this place that I find myself in. I love both of those things equally.

I’ve also often felt like I can … it’s hard to not see them as similar things because when you’re looking at something like crochet or knitting, it’s actually quite a technical endeavor.

I have lots of family members who always claim that they’re not technical or they’re not smart, but they’re able to make amazing, wonderful things from scratch, and so I think that there’s something to be said for respecting the technicality of certain crafts and hobbies.

To kick off this talk, let’s talk about what is crochet. I just recently learned crochet myself. Previously I had tried to learn knitting, and I found it a little bit overwhelming with all of the counting and dropping stitches and things like that. I tried crochet, and I really loved it.

I feel like it’s really soothing, if you have a very active brain at the end of the day, you can just do some crocheting to wind down. The history of crochet is very long, and there’s lots of different countries that claim that they invented crochet. It’s been around for a while. If you haven’t crocheted before, you use a hook like this, and yarn. And you’re just basically making fabric from yarn.

Crochet consists of a few stitches. You can go from different heights, so you have single crochet, which is the lowest stitch, and then it goes all the way up to a super high stitch, which is a quadruple treble crochet. These are US stitch names. I think the UK uses a slightly different system, but I learned how to crochet in Canada, so these are the ones that I use.

Crochet can be used to make really intricate, wonderful laces. It can also be used to make a little hat for your cat, so it’s very versatile, but learning crochet and learning crochet patterns, I felt like something about them was very familiar in that it almost felt like I was reading an algorithm, and I think that’s because it is an algorithm.

For the next part, we have to talk about the next part of this talk, which is what is Turing completeness. The first time I heard this concept was at university, and it was very foreign to me to understand why it matters. I’ll endeavor to explain that a little bit better.

To introduce the concept, Turing complete just means that a language or a thing can be used to make a Turing machine in theory, and so I guess what we need to talk about more is what is a Turing machine?

A Turing machine is a theoretical model of a computer, but before we had computers, and it’s very important to be able to think through something like a Turing machine because it explains to us how we could solve general problems with one machine, instead of making a new machine for each problem that we have to solve, which was the approach that we had before we had this way of thinking.

A Turing machine is a very theoretical thing – it’s not a physical thing. It was never built to prove that it could exist. I think people have built ones in modern times just to show that you can, but it’s more of a way of illustrating what a computer could be.

The parts of a Turing machine are very simple. It’s this tape that you see here, and it has symbols written on the tape, and you’re able to read and write onto that tape.

To illustrate a little bit more, because it can be a little bit hard to understand that just from a quick introduction, here is one algorithm that we will be stepping through in a Turing machine.

First of all, we’re going to start with 110, that’s the number, and our goal is to invert the number to 001.

You can see that for this machine, we have three symbols, a zero, a one, or an empty tape or an empty cell in the tape. We have the tape and we have the ability to read a symbol under the head, and so how this program works is we have 110, and we have this state table that tells us what to do in case of each symbol that we read.

If we read a zero, we’re going to invert it, so we’re going to write one, so write zero, write one. Then we’re going to move the tape to the right, and we’re going to do the same thing. We’re going to read one, and then we’re going to invert it and write zero; move the tape to the right, read one, write zero; move the tape to the right, and now we read an empty cell. That means we can stop. That’s pretty much how a Turing machine would solve this particular problem.

Right. I was thinking about this and how familiar it felt. And I thought, could you represent all of that as a crochet pattern?

It turns out you absolutely can, and it also turns out that it’s really fun to figure it out.

Before we go through the pattern that I ended up making, I will show you a few of my attempts. I tried to make various ways to represent the different symbols in crochet, and all of them turned out a bit wonky. One I tried to do with color, and I think you could totally do that with color. But I gave up after one row because I realized that it’s cheating, it’s not really thinking too much about crochet stitches and more about the colors. But yeah, you could definitely do that if you want.

Let’s go back to what we had before, the Turing machine that we were or the problem that we were solving with Turing machine in this previous slide. Now we’re going to solve it in crochet, and I did end up with a more acceptable crochet block.

All of you are welcome to use my pattern to make your own crocheted Turing machine.

So what is our algorithm here? To start with, we’re going to chain 15. Chain just means putting in the foundational stitches to start, so these ones at the bottom. We’re going from left to right. From row one, we’re going to add a few stitches for height, and then we’re going to chain one, and do a double crochet, chain one, do double crochet, all the way through. And that’s just to set up the tape.

These shaded areas of double crochet, these are just structural to keep the piece in a sort of grid. I shaded them so that you can ignore them and understand that only the ones that are not shaded are important for our tape. Okay.

In the second row, we are going to write or not, I guess, not write, we’re going to make a double crochet to represent a one, another double crochet to represent another one, and a picot, which is this little piece at the top, to represent a zero, because we need three states, we need to be able to also represent an empty cell, which is a chain.

So yes, we’ve done that. Then the crucial part is that we need a stitch marker, which looks like this, and that’s how you can mark a place within your work. You can mark, oh, I’m here, yeah? That’s going to be our head. In our crochet Turing machine, we’re going to not move a tape, but move a stitch marker. We are putting the stitch marker at the picot, and that’s going to be where we start. And then we’re going to go over to row number three.

For row number three, four, and five, we’re just going to follow the algorithm, which is this part here at the bottom. The algorithm goes, copy each stitch that you see from the previous row unless you’re at the marker. If you’re at the marker, if you see a picot, do a double crochet. If you see a double crochet, do a picot. And if you see nothing, then you’re done.

Let’s go through. To the next row. Copy, copy, copy, copy, to the marker. We see a picot. We’re going to do a double crochet. Copy the rest. Chain three to turn. Then we’re going to remember to move our stitch marker over two stitches to the right.

In the diagram, they’re all to the right, but if you were doing actually the crochet, you’d have to remember to move it to the left, because you turn your work every time you add a new row.

So yes, for row number four, we’re going to see that we have double crochet, so we’re going to do a picot, double crochet, double crochet. Move our stitch marker to the right. And then copy everything. Chain three to turn. Copy everything. Then we see a double crochet, so we do a picot, a picot, and double crochet. We’re just copying again from row four.

We know that we’re done because in theory we moved the stitch marker to the right and saw that it was empty, so we were done with the algorithm. And yeah, this pattern is available, I will share the link in the chat, if anyone wants to follow it. And just wanted to show a bit more visually, it can be really hard to see.

Also, I’m not the world’s best crocheter, but this is my final product. I’ve tried to highlight the different stitches and what they mean both in the diagram and in the finished product.

If you look at the colors, to represent the one and the zeros, that might also help for you to see that we started with a picot and two double crochets, and we ended with a double crochet and two picots.

That was a really quick run through both of Turing machines and crochet. I guess, my conclusion is that crochet is Turing complete, as long as you don’t think too hard about the fact that a person has to still do the crocheting.

There’s no such thing as a crocheting machine, we have knitting machines, but crochet is actually really complicated to automate. And so mostly it’s done by humans. I guess, in that way it’s not Turing complete because it’s not a machine at all.

It’s still a really interesting thing to think about, how we have algorithms in our day-to-day lives that we’re following, and how we can integrate computer science more into our granny-like crafts.

Yeah, so that is pretty much it. Just one final note, I wanted to share my zine. Oops, sorry. Wanted to share my zine here, which I made with my good friend Erica. It’s filled with really positive thoughts and fun puzzles, we have a crossword.

Follow the link in the slide here if you would like to buy one. Or if you have any questions, now is the time.

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

“Strategic Interviewing: Pursuing Roles Despite Skill Gaps”: Amie Dsouza with Southwest Airlines (Video + Transcript)

In this ELEVATE session, Amie Dsouza, a cybersecurity program manager at Southwest Airlines, shares tips and tricks for job seekers. She emphasizes the importance of tailoring resumes for each job application and including the specific keywords mentioned in the job ad, and encourages candidates to apply even if they have slightly less experience than specified, as some employers may be open to training. 

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

Amie Dsouza ELEVATE send a pre read for the job interview to stand out

Transcript of ELEVATE Session:

Amie Dsouza:

Hey everybody. Thanks for the warm welcome, Angie and Happy International Women’s Day. As Angie mentioned, I’m working with Southwest Airlines currently as a cybersecurity program manager and since I have a few years of experience of interviewing for jobs, looking for jobs, as well as writing job requisitions and interviewing job candidates, I thought I’ll share some tips and tricks on how you could go about. I want this session to be really interactive. Could I get a sense of how many of you are students, maybe you could raise your hand if you’re a student and you are looking for entry level jobs? Or maybe you could use the thumbs up emoji. Okay. Okay, so there are a few of you. All right. Okay, many of you. Thank you. All right. I’ll try to tailor it half-and-half for entry level as well as experienced professionals. I’m going to share my screen real quick.

I am going to dive right into it. A couple of things while looking for a job. You all know there are lots of softwares out there where recruiters, when you apply for a job, it only reaches the recruiter if it passes by, and I don’t have a lot of knowledge about that. I’m sure you’ve got some tips about that from other sessions as well.

The one thing I definitely know, once it reaches a recruiter, say your resume has all the right keywords for that job. A recruiter looks at your job for two to three seconds maximum.

Make sure what the job ad specifies, especially the main things they’re looking for is in your resume. One size doesn’t fit all. If you’re really serious about applying and trying for that job, make sure you are tailoring your resume for every job you apply. I know it is tiring. It is a full-time job to apply for jobs, but that’s how it is, and that’ll give you the best chance.

We are going to look at a few job ads. These are job ads I’ve taken out of LinkedIn and I have a couple of entry level jobs and a couple of senior level jobs as well, and I’m just going to analyze who could apply for them. Since I’m from the cybersecurity space, some of these terms like the jobs would be in that space, but it would apply for anybody in other technology areas as well.

This job is a fairly straightforward job. This team is looking for a pen tester and they have specified here, they already have a team. They’re looking at adding. a team member to their team. That’s one of the things you need to know that they’re looking at adding a team member. This is not a leadership position. It’s a consultant tester, that kind of analyst, that kind of position.

They have mentioned three years of professional experience. As a person who’s looking for candidates for my team, for example, I would prefer someone who could come join the team and get started. There’s not too much of training time. That’s why some of the jobs will say three years experience, but this shouldn’t deter you if you are a student and you have trained, have some training as a pen tester. If you had it in your college degree and you’ve done some internship around that, I would encourage you to still try for these jobs.

Everyone is optimistic when they’re looking for candidates they want find the right fit, but when they don’t find the right fit, there are some considerations that a manager who’s looking for a job will make.

If they’re not finding people who have enough of experience, they will look at entry level uni grads as well. If they show the right kind of attitude and they have the right kind of writeup in their resumes. This is one tip I would say. If it says two to three years, it’s possible that that team will look at someone who is fairly new to the workforce and will be ready to train. But, you have to show some examples of what you have done in this particular space. Have you done a course? Have you done some actual internship with an organization? And you could give some examples of that as well.

The other thing which I noticed on this job ad was a strong desire and future focus. It looks like they have burned their fingers a little bit. Like they’ve brought in somebody who kept changing their mind, whether they want to be a pen tester or not. If you read between the lines, you’re looking for someone who will be committed to that job, to that role. If you could mention something like that in your resume that would help you at least get to the interview level.

They have specifically mentioned all candidates are subject to a technical interview. If you haven’t done any work in this space and don’t have the training, I wouldn’t suggest because the technical interview will actually test you for those technical skills. If you have any questions, keep posting them. I’ll see if it is relevant. I will try to answer. I’m going to go to the next one.

This is the job for cyber threat intelligence analyst. Again, it’s similar. It’s an analyst role. I would look at it as… To be a cyber threat intelligent analyst, you need to have some experience, some working knowledge. But again, since they have said three years of proven experience, if you have a little bit less than that as well, I would encourage you to apply, still apply. Now they’re looking at certifications. See some of the certifications, CISSP certification, for example. Only someone who has five to six years of experience in cyber would be looking at doing those experience. They’re looking at a rockstar over here. They want someone with three years of experience, but a rockstar. I think it’s a little bit too farfetched. They may or may not get someone who with this kind of a combination. These are the kinds of things you should try and see and apply if you think… This doesn’t really match three years of proven experience and CISSP. It’s not a match, as such. A CISSP would be at least seven years of experience in cyber itself.

If you’re in the cyber space, Security Plus and CompTIA Security Plus are the entry level certifications, which are really, really useful. It just shows your commitment towards that field. I would highly encourage those certifications, but the rest will come as you go through your career. Don’t get bogged down by lots of information in the job ad. Now these are things that these are good to have for them, right? Can you do trend analysis? Do you have social media mastery? Can you look at social media records and look at and understand what kind of threats or indicators are there?

What you should do is still try to understand what they’re looking for and embed that in your resume and that yes, you have gone through social media logs and have found something like this, for example. That will show that you have specific examples for what they’re looking for. Again, because it’s three years experience, even though you may or may not have that much experience, give it a go because you never know. Maybe they’ve been looking for a cyber threat intelligence analyst for six months, have not found one, now they’re ready to train someone. Maybe you’ll be the right person at the right time.

I’m going to touch upon a couple of a little bit senior positions. This is a job ad which I really liked. Identity governance project manager. It is a lead role because they have mentioned leading a team of functional and technical resources. Someone who has enough of experience, but they have kept it pretty broad. They’ve said 10 years experience, but they’ve not said in what. Not specifically that you should have had 10 years experience in identity and access management or in project management.

It looks like they would be okay with someone mid-level and having some experience in each of these areas. That’s how you should read it. Say you have 10 to 12 years of experience in technology, but only three to four years of experience in identity and access management. A couple of years in project management and agile, you should still go for it because since they have not specified that, it looks like they are open to it. Don’t be shy to apply for this role if you have some experience in any of these areas.

This is a great job ad because they have said how you will stand out as a candidate. They have said these are the bonus points. It’s very rare you’ll see this in a job ad. If you have any of these, familiarity with NIST or you have experienced any of these IM products, any of these networking products or security tools, that’ll just make you stand out. If you have it, put it in the resume right up there. In those two to three minutes that the recruiter looks at your resume, they find those keywords. I’m going to do one more.

This is a GRC lead role. IT security, governance risk and compliance lead. It is a big role. It is managing a team definitely, and it helps in IT risk and control assessments, maintenance of IT risk and control catalog. The only thing about this role, if I look at it… I feel like, oh my god, they’re looking for so much of experience. It feels like that. But you’ve got to read each and every line and see where you are at.

Looking at skills and qualifications, again, they have not specifically said how many years in each of these areas, but they have said, do you have some experience in regulatory and compliant assessments, for example? Do you have some experience in maturing cybersecurity processes? If you have touched upon any of these areas, it should be in your resume to be picked up for this.

Some things they have mentioned. Some years of experience, five to seven years in related experience and project management experience. These are some of the keywords I would look at to see whether I have the right skill. Say my background is more in the identity and access management space. I have touched upon GRC a little bit and I have some experience. I have project management experience and experience in information security and audit. I could probably apply for this.

If they don’t get the exact match, they will at least consider me for an interview. That’s the kind of message I’m trying to give. If you have some related experience, at least try for it and highlight what they’re looking for in that job. Okay, so say you have applied for the job, you get selected.

I have a couple of tips for how do you prepare for the job, especially if you don’t have all the skills necessary, but the recruiter still wants to give you a try, that organization still wants to see if you’re the right fit.

Make sure you look up on the responsibilities and tasks like day-to-day tasks involved in that role so you’re familiar when they ask you those questions. In fact, go ahead and hit up some people on LinkedIn or in your network who are in the similar role and see what they do on a day-to-day basis just to get an understanding. You’ve not done that role in its entirety, so you need to have some inside information on what really happens in that role. And for no matter which level, if it’s entry level or senior level, I always recommend doing a 30, 60, 90 day plan.

What would you do if you are given that? Get into the mindset of that role that yes, you have got the job, and what would you do in the first 30 days, 60 days, and 90 days? Do this for yourself, whether you share it with the recruiter or not, do this for yourself. This will put you in the mindset of that role that if you actually get the role, because they will ask you that. Yes, if you are a pen tester and this is the situation you’re in, what would you do? If you plan that out by walking through your 30, 60, 90 day plan, it will help you answer the questions, prepare you for the interview.

And lastly, I do recommend sending a pre-read for the job interview, because people are looking for so many candidates. If you want to stand out and you want to show your commitment towards how committed you are towards preparing for that role, send a pre-read a day or two before your actual interview. The pre-read, now you’ve already sent your resume. They have looked at your resume, they’ve probably had a chat with you. You could just send a little bit about me, as in very specific, not more than seven to eight lines, very specific to that role, what exactly what the skills you have for that role. That’s it. You could have a 30, 60 day plan for leaders who are looking at middle management or senior roles. You should also look at 90, 180, 270 day plan because as a new leader, the first few months is only about establishing yourself.

You can only be productive and actually show some outcomes a little bit later after three, six months, nine months. For leaders, I would suggest you also show the up to 270 day plan. But for anybody else, you at least have to have a 30, 60, 90 day plan. And make sure you send it to the recruiter and make sure the recruiter sends it to the person who’s going to interview you. This will help. A lot of times they will pull it up as part of the interview. That gives you more control at the interview itself. And even if they don’t bring it up, you can refer to it and say, “I sent my 30, 60 day plan to you, and based on that, this is what I would try and do,” in response to any of the questions.

Yep. And that’s it. Yep. I highly recommend a pre-read. It makes you stand out as a candidate, shows your commitments. Definitely try that. No. Anybody. Even if it’s an analyst position, a testing position, doesn’t matter. Even if you are in technology like an engineer position, anybody will need to have this kind of plan. Look it up for specific your role, what would you need to do? And it could be your opinion as well. It makes them aware that you have really thought about that role and if you are appointed, that you will succeed because you are already in that mindset that yes, I’m getting that job.

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

“Don’t Be Elizabeth Holmes: When To Make That Difficult Decision To Cut Scope”: Natasha Harpalani with AWS (Video + Transcript)

In this ELEVATE session, Natasha Harpalani, a senior technical product manager at Amazon Web Services, discusses the importance of knowing when to cut scope in product development. She emphasizes the need to monitor and track progress, set milestones, and constantly evaluate against success criteria while analyzing customer needs and understanding what is truly necessary to achieve product goals.

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

Natasha Harpalani ELEVATE always monitor and track progress for any product

Transcript of ELEVATE Session:

Natasha Harpalani:

Thank you so much and hello, everyone. I wish I could see every individual here, but really, just can’t emphasize how excited I am to be speaking and to be a part of this conference. As you kind of all noted through my very kind introduction, my name is Natasha Harpalani and I’m a senior technical PM at AWS. As you also may have seen through the title of my presentation, I’ll be speaking about how not to be Elizabeth Holmes and really talking through when to make that difficult decision to cut scope.

I will explain the Elizabeth Holmes reference a little bit later in my presentation, but this is a topic that’s really near and dear to my heart and something that I’ve learned, I think, a lot about in every product experience I’ve had.

Before I dive into the details of this presentation, just to expand a little bit more on my background, I started my product management career at a startup called AppNexus. AppNexus was an adtech company that was later acquired by AT&T. My experience there was working on machine-learning products. After spending time at AppNexus and then, subsequently, at AT&T, I pivoted into the cleantech space. I went back to the startup world and worked at Mainspring Energy as an IoT product manager. Mainspring develops a clean generator that can run on hydrogen and biogas. From Mainspring, I came to AWS, where I continued to follow my interest and my passion working on solutions to climate change, and this is where I’m at today.

Today, in my day-to-day job, I focus on working with utility companies and clean energy companies and helping them use the cloud to be able to scale some of the data issues that they have and work with the increasing complexity of data that a lot of utilities and clean energy companies are challenged with as the electric grid is changing very rapidly with more and more renewables coming online.

Now that you know a little bit about me, just to set the stage for this presentation, I want to start by explaining and talking through an experience that I had very early on in my product management career. One of the first products that I worked on was a product I developed very closely with a group of machine-learning engineers and data scientists, and what we were aiming to do was to predict the likelihood of someone online to purchase a product. It was a really interesting product to develop, I was personally really fascinated by it, and as we worked on this product, we hit this point where we’re all sitting in this room and I remember sharing with the team, “What if we use this additional data set that we’ve all talked about that we all wanted to explore to make our prediction algorithm better?”

The intent was good, but it was a situation where I was completely wrong. I was wrong, because we were working on releasing a product that had pretty tight timelines, that was already fairly complex to begin with, and I really needed to take a step back and reevaluate what the team could and could not accomplish in a meaningful amount of time.

After this day, I remember having a pretty hard conversation with the engineering manager that I worked with, and I will never forget. He sat me down and literally said to me, “Natasha, you are asking the team to build Theranos. It’s like you want this perfect product that does everything and is beautiful and has all this functionality and deliver a perfect product to customers, but we work at a startup and we have some really aggressive timelines.” While I do love a turtleneck, the analogy to Elizabeth Holmes was a little frightening and one that I will never forget.

However, even though I didn’t necessarily appreciate the reference to Theranos and to Elizabeth Holmes, I will never forget this lesson.

What I’m hoping to do today is to share how that lesson has helped me in some of my product management experiences and, hopefully, be able to share some of that with you to help you as you’re either a product manager, an engineer, a designer, really anyone that’s working on developing products that customers love.

To set the stage for what you can expect over the next 15 or so minutes, I’m going to talk about how to really monitor and track progress when you’re working on a product to really be able to identify when you might need to get to a point to cut scope. I’ll talk about evaluating your product and your goals against the success criteria that you may have started with, and also, discuss how to really analyze what customers truly need and separating that from what you maybe want to build.

Finally, I’ll talk about when not to cut scope and end things off by hitting on a few key takeaways that you all can hopefully use and leverage in your experiences. With that, let me start with one of the, in my opinion, most underappreciated and undervalued parts of product management, which is monitoring and tracking progress.

If you work on developing software, it’s possible that you’ve seen Gantt charts and milestone tables. Something like what I have on the screen. I’ve certainly seen versions of this that are far longer, far more complex, has 50 boxes in a page. Regardless of how a team organizes and tracks milestones. I think it’s so important to set milestones and constantly track against them.

The number one thing that a team has to do in order to be able to execute well, and it’s the number one thing that I think will set up a team and a software development group to make sure that they’re always evaluating how they’re doing against their milestones and get to a point where they maybe have to make a decision and recognize that they need to cut scope on a product.

When you’re looking at milestones, it becomes very clear when something is off. I think very common causes that lead folks and lead teams to have to cut scope tend to be… Work takes longer than expected, that happens all the time. There’s unexpected bugs, there’s unforeseen issues, and there could also just be delays outside of your team. For example, if you work with another engineering team that is developing a component of the product that you’re putting out to your customer, you have a real dependency there.

Despite some of those very common causes, once you look at your program, roadmap, look at your milestones and you realize, “Okay, I’m not going to hit a certain date,” or, “I’m not going to hit a certain milestone,” there’s generally three options you can evaluate, and I’ll caveat, these are not the only options, but I’d say that these are almost always three of the main options, which is you can extend the timeline on something, you can add additional resources.

That might mean recruiting and including more engineers or more designers or more data scientists on the team to help the velocity of that team, or you cut scope.

This third one is a very common one, and while it’s very hard sometimes to knock it through all the P0s, P1s, and P2s that you want to deliver to a customer, it is so important and I think it’s so important to become really comfortable saying, “You know what? It’s okay, we can cut scope and we can evaluate this and still deliver a really great product.” Once you’ve made that decision. One thing I’ll note is coming back to the example that I’d given you very early on, in the case of the conversion optimization product that I was developing with a team, we had a really strict timeline. We wanted to release this product by the end of Q3 before hitting the holiday season in Q4.

That was really important, because in the ad tech industry, the holiday season is one of the biggest buying seasons and that leaves users sometimes less willing or interested in testing a new product, because there’s just so much spend happening during that time.

Once you’ve made that hard decision and realized, “Okay, I need to cut scope,” one of the most important things I think you have to do is come back to the success criteria that you and your team have talked about and aligned on for your product. Let’s say that, for some reason, you don’t have those success criteria, those can always be developed later on. Really, all that means is, what will make this product release, product launch successful?

The reason it’s so important to take a look at your success criteria is, especially as you start product development, I think that sometimes you can really reevaluate and take another look at, “What is truly necessary for me to achieve the product goals that are set out?” Sometimes you can let go of a few P2s, sometimes you can let go of a few P1s.

Heck, sometimes you can let go of P0s, as long as the work that you’re doing helps you achieve the goals that you’ve set. And that also really involves looking at every single feature. If a feature is a nice to have, or maybe it’s a great feature, but the amount of value it drives for the customer is small, that could be a candidate for something that maybe isn’t released and launched with the first release of a product, but comes shortly thereafter.

Coming back to the example that I’ve been discussing during this presentation, I think back to this example, actually, all the time. Amazing how early lessons really stick with you. But for the product I was developing, our goal that we had set at the very beginning of product development, and at the beginning of beginning our beta testing, was that if 75% of users that were testing this new product could achieve their performance goals, then we would release this product to GA.

As I was talking to my team, as we were thinking about using richer, more data sets to make our prediction algorithms even better, one thing that really was important to look at was, “Hey, will making our prediction algorithm better actually help us achieve our goal or will it just make us surpass that goal?”

At the end of the day, if we see that 75% of our users are achieving their goals, then making an algorithm even better is great, and we always want to deliver value to our customers and give them the best experience that they can, but we’re actually potentially already achieving our goal for this period of time when we’re testing with beta users.

Another really important evaluation step is to analyze the customer need, and this maybe sounds simple, right? Duh, of course I should be always looking at customer needs. But I think in situations like this, when you’re looking to cut scope, you have to come back to the customer and come back to, “What are truly the customer requirements and what are the customer needs?” Looking at things and really deeply understanding what are the customer’s goals, what are they gaining from this experience? Will the customer gain value from a partial test?

Is there something that you can do to supplement the customer’s usage of your product, such as providing additional customer support or additional documentation? Is your customer willing to use a workaround? These are all really important questions to ask your customer, potentially more than one customers, and to understand.

I am constantly surprised and I have to remind myself that, especially early customers that are testing a new product with you, they tend to be pretty agile and really open to the fact that they’re testing a new product. It’s not the end of the world sometimes for certain customers if there’s one or two bugs, it’s not the end of the world if maybe they have to use a workaround, so long as you’re very aware of what is it that the customer is trying to get out of this. Because if I can still deliver that value and I’m releasing one bug with it, but have documented that bug, it might be okay.

Once again, just to set the stage with an example, when I was developing the conversion optimization product, one of the… The crux of that product was that our end user had a performance target. They either hit it or they don’t. Of course, they would love to surpass their performance goal, that’s always great, but the definition of success for my customer was, “Did they or did they not achieve their goal?”

Therefore, by coming back to that understanding and remembering that for our customer, giving them even more value is great, but understanding how they’re judged and how they’re evaluated, once again helped us determine, “Okay, maybe we don’t need to look at everything that we had originally discussed and outlined in our project plan if we can still help our customer achieve that outcome.”

With that, I would be remiss if I didn’t at least touch on when not to cut scope. I don’t think any of these will be particularly surprising, because in many ways, I touched on this when describing the rubric you can use for when and how to cut scope, but I do think it’s worth really calling out.

If cutting scope will lead to your product no longer solving a problem, it’s not worth it. If it leads to delivering such a terrible customer experience that you might lose trust with your customer or your customer will have such a bad experience that they won’t come back to testing or using your product, it might not be worth it.

And then most importantly, if cutting scope will keep you and your team from really learning and getting the insights and achieving those product goals that you need to launch and really develop a great cohesive product, also not worth it. With that, I want to say there’s always ways to cut scope and to think about it, but you do have to be careful and make sure you don’t cross that line where you end up delivering something that isn’t actually achieving the goals that you or the customer set out to achieve. Let me tie back to some of the things I hope you take away here.

Remember to always monitor and track progress for any product. This is so important to help you get to a point to where you even know you have to make a decision to potentially cut scope. I also think it’s just a great habit and great culture to create that the team is constantly evaluating, “Hey, how are we doing against the goals and the timelines that we had set out?” Those can obviously change a lot as you get into the thick of a project and you’re developing a new product, and so constantly keeping an eye on that is so important, because the worst thing that could happen is you get to a certain point in time when you’re supposed to release something to a customer and you realize, “Shoot, I can’t do this. I wish I had cut scope earlier on.”

Next, make sure to always evaluate what you’re delivering to the customer against your success criteria and really deeply understand the needs of your customer. As a product manager, it can sometimes feel really difficult to cut scope. I love developing great products that look beautiful, that feel beautiful, that have all the functionality that my customers love and want.

Amanda Beaty:

Thanks, Natasha. I’m sorry, we’ve got to…

Natasha Harpalani:

No worries, no worries.

Amanda Beaty:

Thank you so much.

Natasha Harpalani:

Thank you so much.

Amanda Beaty:

Everybody, I hope everybody can join us in the next session. Thank you, Natasha.

Natasha Harpalani:

Thank you.

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

“Building By The Rules, A Policy Crash Course For Technologists”: Chizobam Nwagwu with U.S Digital Corps (Video + Transcript)

In this ELEVATE session, Chizobam Nwagwu, a fellow at U.S. Digital Corps, discusses the importance of policy for technologists and provides a crash course on policy. She covers different types of policies, including laws, regulations, executive orders, guidance, and priorities and plans. Chizo emphasizes the need for technologists to understand and work within policy boundaries, and provides advice on how to navigate policy challenges. 

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

Chizobam Nwagwu ELEVATE public policy should be designed to serve the public

Transcript of ELEVATE Session:

Chizobam Nwagwu:

Awesome. Thank you for having me. Thank you again for everyone who’s making the time out of your day to come. This is my talk – Building By the Rules, A Policy Crash Course for Technologists. Now, just a preface, this talk is not legal advice or a comprehensive guide to federal policy considerations. I am not an expert, but I recognize that this information is really important. As an overview of what I’ll cover today, I’ll talk about why policy matters, offer a basic policy framework and dive into a case study, a project that I worked on called FindSupport.gov. And if there’s time, we can hopefully do some questions.

Let’s start with why policy matters. Now, I can imagine that many of you are a mix of those coming from the nonprofit and private sector. Well, public policy is definitely a foundation of what makes government unique from either of those two. It’s often important for keeping in mind what and how we deliver products and services to the public and the government, or in my case, the federal workforce. I hope that this talk can equip you with some soft skills and knowledge to put in your civic technologist tool belt.

Let’s back up and use this from the perspective of thinking about our own personal lives for a bit. We all make policy. I think about rules that I live by, what are things that I always do or things that I never do? For instance, I always try to brush my teeth twice a day. I always try to…or I never bike in the rain because that sounds like a really risky task to take. Or I always make sure to fill up a tank of gas before I’m going on a really long road trip.

I can imagine that folks in the chat, if you want to share any of your own rules that you live by, that some of those themes may be along things like diet or things that you use to work out or how you budget. What are you setting aside for certain activities every fiscal year for yourself? Or even how people do chores in your house, I know that’s a big thing of mine.

I would say that people create rules or people create our own policies to protect ourselves. I think about my rule of, I always try to brush my teeth twice a day is because I want to prevent cavities. I want to ease the pressure that my dentist might be putting on me as well and keep myself healthy. That’s really what the essence of kind of a bit of what policy is. Policy is trying to make our behavior intelligible and predictable to others. Another policy could be, I have a colleague who is vegan and whenever we go out to eat, always thinking about what are places that we can go that can also accommodate her needs and wants?

It also helps us translate our goals into action. For instance, if I want to run a half marathon, leg day is my policy. I must do [inaudible] in the sense of if I want X, I must do Y. It also helps to organize our options to inform a specific course of action.

I think about whenever I’m going on a really big expensive trip, I may say, “Hey guys, or hey friends, I can’t go out tonight because I’m saving this for a piece of this, a certain amount for a big trip that I want to save up for.” It also sets expectations and clarifies our responsibilities to one another.

For example, if I have a roommate, “I do laundry and you are going to do the dishes.” And there may be some consequences or penalties for not complying. If I said that, “Hey, please do not touch my leftovers from a really nice dinner I had,” the consequence might be a very ominous stare from the corner of the room.

Public policy is like that, it’s really, except, it’s on a bigger scale. Public policy is trying to address a number of problems at the same time. Dealing with often a larger scale of people, goes into much more detail, and may require more time to craft.

Notice that maybe based on, and I don’t have super clear access to the chat yet, but if folks did share, there’s probably some rules in your own life that you’re thinking that you’re more lax about or more strict about than others.

Government can be like that too, where they’re constantly having to meet new people, do new things, and they need to be able to update policy to meet those new needs or new challenges, iterating to meet those challenges.

Let’s start with a brief framework of how I might think about product, specifically, in public policy. Where policy can be seen as a force for change or a force against change, acting on both sides of the thing that you’re trying to do or accomplish. This is Kurt Lewin’s force field analysis model that I can’t take credit for.

Let’s start with a force for change. In the chat, if anyone can share, feel free to share of any ideas of instances where a force for change.

What is a policy that allowed you to have permission to innovate or improve? Examples that I’m thinking of in my work, for instance, was the 21st Century IDEA Act. That was a law passed in 2017, if I’m remembering correctly, that required agencies to modernize, digitize, standardize how they’re actually building websites in the 21st century. Or the Customer Experience Executive Order, which I’ll dive into a little bit later.

On the opposite side, a force against change or a restraining force is what I’d like to say. It places constraints or conditions around innovation. An example of that, again, in my work or the space that I’m in, maybe for example will be the Privacy Act, which protects personally identifiable information. It prevents agencies from disclosing certain types of information without consent. It’s really trying to uphold that prior commitment that we’re making to the public. You might think of that as a, may the force be against you or with you type of situation, depending on how you’re looking at it.

Let’s go deeper into six policies I hope to cover today. Now, it’s not an exhaustive list, this is really just a discrete number that I thought would be relevant for our conversation this afternoon. I’d bucket those into binding and non-binding. With binding policies, I’d like to think of as carrying the force of law or a contract between you and the government, one that you can legally challenge one over the other with. There may be penalties or consequences for not complying with those. Whereas, non-binding will be not binding.

Let’s start with laws. Examples of laws that immediately come to mind include, for example, ones that really are stemming from people listening to problems in society. And so our lawmakers in Congress, for instance, or in your state legislature. They’re tasked with listening to the public and translating those challenges into solutions. That shows up in policy as, for instance, the Rehabilitation Act of 1973 or the Americans with Disabilities Act, the ADA’s protecting people with disabilities in many areas of public life. The Rehabilitation Act requiring access to federally funded agencies and programs and federal employment.

To get a bit deeper, laws or enabling statutes may also come with appropriations. As product people, especially, working in government, we’re working in agencies, complying with the law is part of our job. A law may also provide enabling statutes where it’s a type of legislation that provides new powers to an entity or permits something that maybe wasn’t allowed before. Again, these happen at the state level, the city level, think of your state legislature, your state constitution, or your city council, or your city charter. Those are also examples of appropriations laws. Now, there are also differences between mandatory laws, where you must do, versus directory, which is you should do. Which I won’t get into too deeply now.

On the right you’ll see a screenshot of the 21st Century IDEA Act, which again, as I mentioned, requires agencies to modernize websites, digitize forums, accelerate the use of e-signatures, improve customer experience, and standardize the transition to shared services.

Moving on to regulations. Regulations are also called rules. They are subject to statute. So for example, it goes through a comment period, it goes through the, sorry the rulemaking process, which first starts with a notice, the agency puts out notice of, “Hey, we’re putting out a draft version of this rule.” Then the public is allowed to comment on that rule.

Anyone can comment on that rule, there’s a lot of materials online about how to write a public comment. Then, the agency looks at each of those comments, understands and answers each of them to then implement those into the revision, understand what is implementable into the revision of that rule. And then finally, publishing the final rule. And these, again, are subject to challenging in the courts around agency authority, which I won’t get into for the bounds of this conversation.

Let’s take an example. Let’s take the Federal Acquisition Regulation for those that may be familiar with contracting or specifically, government contracting. This is the regulation that governs that process, the procurement policy for the federal government. Now in this subsection A where it says 41 U.S. Code chapter 13 is where those requirements will be. That code says that the General Services Administration, the DOD, and NASA shall jointly administer and maintain a single government procurement regulation known as the Federal Acquisitions Regulation. And so I encourage you, this is a very small piece to learn more about rulemaking or rules at regulations.gov or also reginfo.gov to certain degrees about how that process works.

Now, let’s go into Executive Orders, the final binding type of policy that I’ll go into. It’s also a type of regulation. It does not go through the notice and comment period. It’s exempt due to some expressed powers in the Constitution. For instance, times of emergency, examples of this are, for instance, the Customer Experience Executive Order. Which does provide specific instructions for how agencies should deliver.

Going into non-binding policies, we have guidance. There are lots of names for this, there’s memos, policy statements, circulars, bulletins, et cetera. The purpose of these is to explain new regulations and answer stakeholder questions. Now, there’s some caveats with this where the interpretations are binding on employees and may include some penalties.

The guidance also is binding, it can be binding to vendors in any contract. And again, it’s administered or written by subject matter experts like the chief information officers, program leads.

On the right, you’ll see an example of a recent memo that came out by OMB. Number OMB Memo 23-22, which outlines the specific requirements, timelines, and priorities for implementation of the 21st Century IDEA Act.

Now, I’d like to end here, this part of the talk here with the priorities and plans. The PMA is also known as the President’s Management Agenda, for instance, is a version of a priority. It lays out the agency’s strategic plans. For instance, the data strategy from the Evidence Act is often delegated to sub offices. There’s different responsibilities for these are spread out across the federal government in this case and often crafted internally.

Now, this might be a good screenshot time as a small version of a cheat sheet of some of the policies that I went over here. I’ll take a quick moment, and just to wrap us up here, I’d say the policy advice that I have for technologists would be to get to know your policy folks. It is someone’s job to understand statutes and regulations, really lean on them for insight and advice.

Secondly, I’d say the law is more flexible than people may realize at times, so really read the policy because sometimes the policy can be, “Well, we’ve done this this way the entire time and it may not be written down.”

Three, pick your battles, know whether you’re dealing with a law, which may be very hard to change, or guidance or a priority or plan. Where there might be some leeway and when necessary, fight policy with policy.

Then lastly, definitely knowing your boundaries. Knowing again, when to defer to your policy subject matter experts when it is falling outside the bounds of your role as a technologist.

These are some reflection questions I won’t have time to get into right at this moment. But again, feel free to screenshot if you’d like to take it back to your team. I hope from this very quick synopsis that you can see that technologists help deliver within the bounds of policy. Policy can seem scary, but policy shouldn’t stop us from meeting the public’s needs.

I’ll frame this quickly with a case study of Find Support. Where the White House in their 2020 Unity Agenda had outlined that they wanted to build new easy to access, user-friendly online treatment locator tools for behavioral health.

SAMHSA and CMS, my team with the digital service at CMS, helped support the work to build FindSupport.gov in trying to meet that priority. The purpose of this website is to help people know how to cope with behavioral health issues, know how to find treatment, get the tools to know how to pay for treatment, again, based on your insurance status.

We talk to a lot of the people as part of our user research who are on Medicaid or may have qualified based on some of their information, and also allows people to have the tools to know how to support their loved ones and what to do in a crisis.

We started with framing this project around how can we build with, not for users? Is this product accessible for all as part of our requirements being in the federal government? And how does this product protect user privacy? And is it secure?

These were a few of the statutes. I’m really going to dive into about two of them for the purposes of this conversation. The Paperwork Reduction Act in the federal government is really designed to reduce burden on the public. I say that to say, for instance, think about how long did it take you to take your taxes this year?

On average, it takes about 11 to 13 hours for Americans to prepare their taxes. And that’s at least a full workday, if not more. And so how would it make you feel if that process was any longer? That’s really what the PRA is trying to get at as one piece of the spirit of the legislation of thinking about forms. And you can see in the top right corner an OMB control number.

And ways that we navigated this… I encourage you to look actually more on PRA.digital.gov to learning more about what it means to do low burden research before having to go through a longer approval process. But these were some considerations that our team took. And so you can check out more information about this specific law on PRA.digital.gov.

Similarly, with the Section 508, it requires agencies to make all federal IT accessible to people with disabilities. And that touches on a number of things and also corresponds closely with other peer legislation related to people with disabilities and their different types of lived experiences. That also factored into creating our roadmap for actually building the product. Really making that the focal point for how we were doing user research at what points in time.

With that, I will quickly close since I know my time is coming up, but I hope that if it’s clear that as product managers or as technologists, doing your due diligence is important. That you have awareness that policy actually can create space to ask questions, and that every policy won’t apply. In general, the government should be designed to serve the public. Public policy should also be designed to serve the public. And with that, product managers or technologists specifically, more generally, have an opportunity to center the public voice.

Thank you again for having me, I’m really happy to connect offline.

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

“Technical Interviewing For Leadership & IC”: Flora Jha with Wells Fargo (Video + Transcript)

In this ELEVATE session, Flora Jha (Wells Fargo Developer), a software developer with experience in various domains, shares her advice on preparing for technical interviews, starting with the importance of preparing a great technical resume that highlights work and achievements.

Topics include tech screening, algorithms, data structures, and object-oriented principles, system design questions, and the importance of soft skills in technical interviews. She recommends preparation that includes researching the company and its culture before an interview.

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

Flora Jha ELEVATE your resume should be ats friendly

Transcript of ELEVATE Session:

Flora Jha:

Thank you. Thank you, Sukrutha, for having me at Girl Geek ELEVATE Conference. I’m so thrilled to be with so many awesome women who are making their mark in tech industry. Thanks to all the audiences for joining in today. I wish to give a quick introduction in addition to what was defined for myself. I’m a software developer for seven plus years total experience. The domains I’ve worked, education, investment banking, government and others. I’m Sun certified Java Developer and also AWS Certified Cloud Practitioner. Currently, I’m working on credit card domain building APIs.

I also run my own company called Bright Logicals LLC. Some fun facts about me, I have deployed 10 plus applications in Google Play Store. I have some volunteering experience as well. I’m currently co-lead at ACM-W students chapter, North America. I’m working with Lindsay Jamieson who is lead for the entire North America. I have my brief resume there on the first introductory slide. My LinkedIn profile has been posted through QR code. There is my complete profile. Without any further delay, let’s start with our topic today. Today the topic that I’m going to explore is going to be about technical interviewing.

This is the topic that’s very close to my heart because I have myself attended various technical interviews and to start with technical interview, it’s not about tricking you with any riddles and then brain teasing you with impossible questions.

Technical interviewing is all about preparing you to derive real world solution in real ways, just like those when you are on job. On contrary to the popular belief that technical interviewing is a science, I believe it’s more like an art, as there is a quote that says, “In science, universe is in control and in arts, you are in control.” In technical interview preparation, it’s exactly the same, you are in control.

Going next about the technical interviewing. What are the most important things? I just want to go across the first steps in hiring process and that is preparing a great technical resume. A resume that holds an epic story on your work and achievements. Before you, it’s your resume that’s going to be doing talking on your behalf. Make sure your resume is interesting with something that holds a lasting impression.

Look for ChatGPT-powered resume builders. I have enlisted some and as a giveaway I’m going to enlist some more. Look for symbol on the slide for takeaways, click onto it, should lead to a resource. You are always going to have options like how you want your resume to look and talk for you. Do you wish to write your resume in chronological order or reverse chronological order, for its obvious merits or simply hybrid order for its formal look and feel?

Most importantly, your resume should be ATS-friendly. ATS is Application Tracking System. It’s a buzzword for recruiters and for HR platforms in recent times. HR search engines look for certain terms to segregate the resume. These HR platforms are extensively ATS-oriented. Some HR platforms such as Greenhouse, Workable, Breezy HR, Lever are some examples. In the slide there is some detailing about these HR platforms and there is a report by Jobera that these recruiting platforms reduce the cost by 250% if they go with these ATS friendly HR platforms.

As a giveaway, I’m going to list some ATS friendly keywords that you can include in the resume. If your resume is the gateway to your work and achievements, then cover letter is your elevator pitch. You might have… This is basically, so you might have a plenty to say, but focus on some outstanding facts and figures, something eye catching. Mention what propels you or what motivates you.

Give the hiring manager an exact glimpse into what you can do for them. I’ve also mentioned Greatcareers.org that’s owned by Ms. Lynne Williams. She’s doing some great work in this area, you can check her work as well. Moving more into the details regarding what you should be doing for that, I have now entirely a different section to talk about. In the interview process, at some point you may have to go through tech screening. This might be the most decisive step, if not the only thing being considered in the hiring process.

A clear idea regarding an algorithm and its corresponding amortization complexity should be a priority in interview preparation. You don’t have to be an encyclopedia, however, you should be able to defend your answer or give an argument on why you think the solution you presented is the most optimum solution. Be prepared to write code on whiteboard or pseudocode.

Make sure your concepts regarding object-oriented principles or system designs are clear. You should be able to comprehend time and space complexity for any solution. Data structure and basic algorithm and how they work should be well-prepared in advance. Now, moving on to the sorting algorithms and various algorithms that I have tried to present on this slide, I’m going to specifically just give an example. Now say, for example, you have multiple sorting algorithms. Now, these are generally interviewers’ favorite question.

Comparing a sorting selection sort and quick sort for data set where N is equal to 1,000. Selection sort is going to require O(n) square or about a million operations, whereas quick sort is going to require only 10,000. Log base 2 for 1,000 is about 10 or 100 times faster. For data set where n is equal to 1 million, the savings are even better. Quick sort is 500,000 times faster than selection sort.

The way selection sort is going to work is by finding the smallest element in the array and swapping it as the first element. The first position is then ticked as done and pointer moves to the second element to find the smallest in the remaining and swapping it with the second position. Quick sort is considered as fastest because it is recursively going to sort elements by pivoting the last element and moving all the elements less than the pivot to the left side and those that are more than pivot to the right side.

Now moving on, I’m going to be taking an example. Now if you’re lucky, your interviewer might just ask you a simple question that, can you please write a code to find if a number is prime or maybe a string manipulation or something like that. But, technical interviewing is more like logic building, writing a code, and it’s very important that we do that logic building and writing a program perfectly.

I’m going to be presenting here a problem and the problem statement is, that we have a fence with N posts and we want to paint the fence. Every post must be painted exactly with one color. There cannot be two or more consecutive posts with the same color. We are going to represent color by K and a post in the fence by N. Now the very first step is going to be about logic building. So let’s start thinking how can we paint the first post. Then how many ways can we paint the second post, and then on the similar line, think about third post and so on. So, the first post can be painted either yellow, green or blue. As you can see here, I have just tried to give here detailing about how it can look so that you have a visual details as well.

If we have two posts then we can paint both the posts with the same color. So there are K ways to color it where K is a variable and we are representing it by K. Say for example I have K different ways, but I choose blue for the first post. For the second post I’m going to be doing the same as blue. I have no choice because I have chosen to paint both the posts with the same color. There’s only one way to choose the second color. Now, going onwards how we can, if we wish to paint these two with different color, then how many ways there is going to be K to K minus one. So, for the first post we have three choices, yellow, blue, and green, so we have K choices. For the second post, my choices are reduced by one because I want to keep both the posts different.

Our formula for computing total ways in which a post can be painted is going to be K+K * (K-1). And it is very simple because we just went through why we have come with this formula. So, we just have to add these values together. So far we are going really great and this is getting really interesting. Going on the similar line, we are going to determine the total ways to paint the third post.

In this particular slide it’s the most important slide because this gives a really good detailing about how we are going to build our logic. In this particular first column or maybe the second column, we are going to assume the basic two assumptions, and this is going to be for the third post. If we want to paint the third post different than the second and second assumption that we want to paint the third post to be the same as the second.

These two are going to further lead into sub-conditions and you can see in this fourth column we have those sub-conditions. I’m just quickly going through that so that makes more sense. First two are different, I want third also to be different. I have K-1 choices to make. Third post different. All I care is how the second post is, (first two posts different) * K-1. As you can see in the slide, that first two are different, that is blue and green, hence the third option I can choose is yellow or blue. Now second, first two are the same, I want to make third as different. Again, I have K-1 choices to make it different. (First two posts are the same) * K-1. Now going with the second assumption here on the second column that we want to make the third as same as the second.

First two are different. I want to make the third post the same as second. It’s possible if second is different than the first, there is only one way I can do that. And finally, it’s first two are the same and I want to make the third as the same, that is not possible, it is violating our boundary rule, and what’s the boundary rule? We cannot paint with more than one color, more than two consecutive posts, we cannot paint it with the same color. Now, we have built our logic, and the most important thing is that we have built a generalization and that is very, very important because if you solve something like this, it’s really going to help you to build a logic. And then for this particular problem, the generalization says that, for the third post to be different, total ways third post can be painted differently plus total ways third post can be painted the same.

We have reached this particular generalization. For example, if we consider fifth post and how many ways can we paint it differently. We simply have to look how many ways can we paint fourth post to be painted differently plus same and multiply it by K-1. That’s the generalization we have. After this we’re going to write either the pseudocode. For here I have just written the program itself. I thought it’s going to be a great idea just to share it with you. Now based on it I think you can look across, you have questions and concerns, you can definitely post it in the chat and I should be able to answer to it. Now, you can just look into it and I am going to, it is very self-explanatory because we have already gone through it.

Now we are going to analyze the complexity for this particular problem. The time complexity is O(n) because we are iterating from three to N once where each iteration is requiring O(1) time. O(n) is also known as linear time complexity. The runtime increases linearly with input’s size, and the space complexity is O(1) because we are using only some constant variables to store the value that is repeatedly replacing itself. So far this is the best solution we have arrived because it has the best possible space complexity we can create for this solution.

As promised during the first slide, technical interviewing is not about brain teasing you with impossible questions. It’s about solving day to day problems in simpler ways. There I was. Now moving on to something really important in technical interviewing, and that is mostly for the tech leads and it can be even for ICs, but then more for tech leads.

And that is system design questions. It’s a must for tech leads, actually, and it cannot be restricted with certain questions only. Design questions can be based on simple questions like, tell me about a time you solved a conflict with a developer. How did you handle criticism about your own design or a complex question, for that matter? As a preparation tip to solve any design questions, prepare and prepare, do all your mocks. Now moving on, we are going to have something simpler and that is, those questions that I just showed you in the start, we have little different than that. Say for example, when you are talking during the interview. You have to think as well as talk. The more logical and coordinated your thought processes, the better it is to help answering any question. In many ways, a designer is as good as their tools.

Any knowledge you have about design solution is an asset you should utilize in your interview. Don’t be afraid to ask questions to clarify yourself before answering. Additionally, be sure to mention certain skills that make you more versatile, such as, any certification or any programming language. Some more ideas: associate any design solution with any accomplishments or project work you have previously done.

Share your portfolio having similar work, and for analysis problems, for system analysis, try giving multiple solutions to the given problem. If required, you should be ready to defend each solution with each having its merit over the other. Moving on to the technical interviewing, some more aspects into it, and this is more about the soft skills. Now, more questions… either you can just look out for more questions. I have just put some more questions as well.

How do you do your time management? Management and lead duties can be tough for some. If you are interviewing for a role that requires managing others and are working on tight timelines, organization skills are even more crucial to demonstrate, especially for the tech leads.

Some questions that might come regarding the soft skills and regarding the time management, calendar management and in those lines, it can be something like this, how do you stay organized? Tell me about a time you had an enormous workload. How do you organize your priorities? Describe a role where you had to handle many things at once. How did you manage it? What organizational tools do you use in your work day? These are some basic questions. You should also know how to manage calendar, how do you prioritize your meeting and many other tools to handle your day-to-day work life. What are the best available tools?

I think these are also very important that you really remember what are the tools and how are you going to manage them? Okay, so going with some more ideas. It’s like I’ve done a little more research, but I always wish and I always advise that you should be doing little research about the company as well and you should do your homework about the company because leads are big responsibilities.

That little research about the company culture can give you an advantage over others. Look for inner information like if a company hosts your own podcast. Podcasts are the team style conversation that are availed as digital imprints into social medias. As a takeaway, I’m going to list companies that have brand presence through podcasts. Some companies that I worked at have their thriving podcast as an example, Wells Fargo has Working at Wells Fargo, McAfee has Hackable?

McKinsey has McKinsey Podcast and WHOOP has WHOOP. There are so many different podcasts you can just go through. They are really great as far as giving ideas regarding how a company culture works or what’s the team style conversation and things like that, so I’ve listed it here. Now, and also remember that it’s a never ending discussion on how much can you prepare.

Always remember you are not expected to be an encyclopedia, you should just be thorough with what you know and what you should know. The basics, the fundamentals, and you should have answers to everything you ever learned and ever worked on. I wish you all, best luck for all your preparations and please allow yourself to contact if you have any questions or concerns. I see that I do have questions in the chat, so I’m going to answer them here quickly and I’m just looking into here. So let me just take the questions.

Something is about getting connected and application tracking systems. I think it’s a great way to… Because almost all the HR platforms, if you see and if you just clearly go through, they are using this as the buzzword and I have also included in my slides some statistics by Jobera and they claim that if you have those buzzwords, they really help your resume to sail through.

I also wanted to mention, and I think this is really great that I just got connected to Ms. Lynne Williams and she is doing some really great work as far as resume building is concerned. Now it’s your wish if you really want to include ATS friendly words or if you just want your resume to be chronological order or reverse chronological order for its obvious merits, or maybe you just want it to be hybrid for little personal touch. I think you all can go for it with Ms. Lynne Williams. I think it’s…

Sukrutha Bhadouria:

Flora, she’s actually commented thanking you for the shout-out, she’s put in her link. But thank you so much Flora, we’re at time and this was a really engaging conversation and an engaging session. Thank you for your time.

Flora Jha:

Thank you, thank you very much.

Sukrutha Bhadouria:

Thank you everybody, bye…

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

“Accelerating Value Delivery & Empowering Autonomous Teams”: Jen McVicker with Atlassian (Video + Transcript)

In this ELEVATE session, Jen McVicker (Atlassian Senior Enterprise Technical Architect) discusses how adopting DevOps culture, strategies, and tools can reduce time to market and increase developer satisfaction and productivity by bringing together development and operations teams to work as a cohesive unit with shared goals.

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

Jen McVicker ELEVATE quote google dora devops metrics engineering performance

Transcript of ELEVATE Session:

Jen McVicker:

Today I’m going to share how you can reduce time to market and increase developer satisfaction and productivity by adopting DevOps culture, strategies, and tools. Let’s look at DevOps culture first.

In the world of software engineering, there’s historically been constant tension between deployment frequency on the development side and site reliability on the operations side.

When you have separate operations and development teams, this can result in a tug of war. The operations team is trying to limit deployments because deployments introduce change, which always carries some risk of failure while product development teams are trying to deliver value to customers as quickly as possible.

How can we resolve this struggle? Back in the late 2000s software development and operations communities started raising concerns about this tug of war. They realized that these apparently diametrically opposed groups could actually work much more effectively if they worked together as a cohesive unit with a shared set of goals.

The term DevOps was coined by Patrick Dubois in 2009 to represent this new way of working. But it’s not just as simple as mashing together two groups and telling them they’re now a team. You’ve heard of forming, storming, norming, and performing, right? It’s called Tuckman’s model, and it describes the life cycle of a team.

When a new team is created, they don’t immediately begin working together as a cohesive unit. This is when it’s important to develop working agreements because sooner or later conflict starts to arise within the group. And this is actually a good thing. It means that your team is starting to trust each other. As long as you have team agreements in place to ensure that everyone treats each other with respect and that each person’s opinion is considered valuable, you can harness that conflict to drive the collective team to deliver better outcomes.

Why? Because the knowledge of the collective group is greater than that of any one person. When the group starts to really coalesce as a team, they’ll begin sparring on problems and come up with solutions that take into account the diversity of experience among all team members. But teams need stability to develop this level of trust. That means not swapping team members in or out very often because every time the team changes, they’re going to regress for a little bit.

If you have a long-lived stable autonomous team that has developed trust, they’ll get to this point. Performing. And this is when you see real dividends pay off. I snuck something in there though. Did you notice? Autonomous. What does that word mean in terms of software development? Well, autonomous teams are independent. An autonomous team is made up of a cross-functional group of people who can move quickly because they don’t have dependencies on other teams. Ideally, all the skills needed to perform the work are encapsulated within the team.

The key is to eliminate as many dependencies on other teams as possible while keeping your team at a reasonable size, about five to 10 people. Now, another key element here is value-aligned, and by this I mean that the team is responsible for the entire flow of a stream of value to the customer. For example, an e-commerce solution. It needs to include products, the mechanism for adding products to the shopping cart, the checkout process, but it could also include things like a search engine for finding products to add to the cart, or customer tracking to gather data around customers who abandon their cart.

Finally, autonomous teams are empowered. They’re empowered to experiment, learn, and pivot as needed without a lot of bureaucracy, empowered to decide how they will work and what tasks to prioritize. And most of all, empowered to decide the best way to achieve the outcomes they’ve been asked to deliver.

Now, this involves a lot of trust that the team will deliver on their objectives, but if you empower your teams to be autonomous, you’ll be astounded at what they can accomplish. There’s a secret to getting the best results from an autonomous team though, and I just mentioned it.

Outcomes over output. Simply put, rewarding outcomes over output means measuring the right things. People are incentivized to deliver what gets measured because they’re held accountable to those metrics, so make sure you’re measuring the right things. Let’s take an example. You ask the team to build an avatar feature for the user profile section of your community website. You think that customers will come back to the site more frequently if they can see each other’s faces or cartoon robot faces in this case. The team takes a few sprints to deliver the feature because they need to implement a new backend process to optimize and store the images.

Now, you finally launched the feature, and it results in a very mild uptick in monthly active users for a couple of months, but then it drops back down. The effort and expense that went into building that feature may ultimately not produce the desired outcome. What if instead you ask the team to increase customer engagement on the website? Do you see the difference? In the first you’re telling the team how you want them to solve the problem. In the second, you’re telling the team the problem you want them to solve. How do they know how to solve the problem though? Well, it’s not easy, but it is simple. Experiments.

Much like with AI-generated art, you’re unlikely to get the outcome you’re looking for on the first try. If Agile has taught us anything, and I hope that it has over the past couple of decades, it’s that we have to iterate learning to capitalize on the things that work and pivoting to something different when the feedback tells us we’re going down the wrong path until we get to the outcome we ultimately want.

This is the power of experimentation and autonomy. When the people who are closest to the work are also closest to the feedback, they can learn from that data and make the best decision about what experiment to try next without having to get approvals and buy-in from three levels of management and a dozen other stakeholders first. By making teams accountable to outcomes instead of output, you incentivize them to quickly learn what works and what doesn’t, which naturally leads to a learning-centered culture, one of the key principles of DevOps. The faster you can get feedback, the faster you can learn what works and what doesn’t. So let’s take a look at some of those DevOps strategies and best practices.

Ten years ago, Google decided to research why some companies have high-performing software teams and why others fall short. Google’s research team known as DORA released the first State of DevOps report in 2014, and in it they introduced four key metrics that correlate to strong engineering performance. Those metrics are deployment frequency, which measures how often you deploy changes to production; change lead time, which measures how long it takes from the time a developer first commits code to the time it is released to end users; change failure rate, which measures what percentage of changes pushed to production cause a failure and mean time to recovery, which measures how long it takes to restore service after a failure. They’re collectively known as the DORA metrics. And you’ll notice that these are metrics that directly tie to strategic outcomes.

Deployment frequency and change lead time point to how quickly you can run an experiment and get feedback. Change failure rate and the mean time to recovery tie directly to code quality and site reliability. By focusing on these four metrics, your organization can reduce downtime and development cost while delivering value to your customers more rapidly. Now, all four of these are important, but today I’m just going to focus on deployment frequency and change failure rate.

By looking at these two metrics, you can build a robust process that mitigates risk and reduces time to market resulting in faster feedback loops. Let’s take a look at a common bottleneck for deployment frequency that I see at a lot of organizations. It’s the Change Approval Board or CAB. CABs are usually made up of leaders across different areas of the company’s technology stack. Those CAB meetings often don’t happen more than once or twice a week because it’s expensive to have a lot of highly paid people sitting around to give the thumbs up or down on a laundry list of changes.

Because of this, many changes are delayed several days before they’re actually released in production. What’s the solution? Do we eliminate the CAB altogether? Heck no. CABs serve a very important purpose. Their primary focus is site reliability. Remember that yellow ops side of our infinite loop?

The CAB is a key player here. Not only do they review proposed deployments in order to identify potential dependencies or downstream effects, they can also ensure that resources from any affected systems will be on call to address problems that might crop up during deployment such as database or network admins.

This is critical for complex deployments that may affect many areas of an application. Ideally, though, those dependencies and downstream effects are already known and communicated throughout the development process, and the people deploying the changes would have the ability to resolve any problems arising with the change because that change would be isolated from other applications and services.

How can we reach this ideal state? First step, a loosely coupled architecture. Loosely coupled architecture is a fancy way of saying that the software is made up of multiple independent services, sometimes called components, that interact with each other through APIs. For example, let’s say we have an online store. You may have a service that allows people to search for products. That service would call your product catalog service, and it does so by calling a specific URL, which is the catalog’s API endpoint, and passing along search criteria such as a keyword to get the results.

The catalog service API then returns zero or more records that match the search criteria. The search service doesn’t care how the items are stored in the catalog, how they get added or removed or updated. All the search service cares about is that when a keyword is sent to that URL, specific values will be returned, such as the name, price, and thumbnail image of the item.

This means that the catalog service can be updated at any time without affecting the search service at all as long as the parameters that get sent and the values returned by the API stay the same. You could add more product information such as customer ratings or even swap out the database that stores the products for a new one.

As long as the API endpoints don’t change and the same values are returned, the search engine will continue to function.

There are major benefits to a loosely coupled architecture, but there’s one big drawback. It turns into software sprawl. Now, software sprawl occurs when the number of applications or software components within an environment rapidly grows and changes. Sometimes this term is used in reference to the tools that your organization uses, but today I’m talking about the applications and services that your organization creates.

Sprawl makes it really difficult for traditional software project management to scale, including CABs, and it can be a nightmare for engineering teams to keep track of where dependencies exist, who owns what service, and when changes are being deployed.

How can we solve this? Well, hang tight. We’re going to get there in just a minute, but first, we need to take a little detour and talk about service tiers.

Service tiers are a great way to manage risk. I’m going to do a quick walkthrough here of what service tiers are, so we’re all on the same page.

Tier one also sometimes called tier zero includes your most critical services. Any downtime for a tier one service is going to have a significant impact to customers or the company’s bottom line. An example of a tier one service could be a credit card processor.

Tier two failures will cause a serious degradation to the customer experience, but it doesn’t completely block customers from interacting with it. Tier two services might include that product search that we just talked about. Customers could still purchase an item by browsing through categories even if the search is down, but it’s a poorer experience.

Tier three services have a very minor impact to customers or limited effects on internal systems. Tier three services might be something like that avatar display that we talked about earlier. And finally, we come to tier four. These services would have no significant effect on customers or internal business users.

Tier four services could include things like a sales report that temporarily fails to generate. Now we have one more point to cover before we move on to tools, and it’s about the difference between continuous delivery and continuous deployment.

These are actually related concepts that are often mistakenly used interchangeably. Continuous delivery is defined by Google as the ability to release software changes on demand quickly, safely, and sustainably. It does not mean that the code has been deployed to production.

Rather, it means that the main trunk of your repository in your staging environment must be ready to be deployed to a live production environment at any time. Any testing or scanning that needs to happen before the code is released to production must be done before the code is pushed to that pre-production environment. Now, remember, change failure rate? This is how we move the needle on that metric by ensuring that our code is deployment-ready and fully tested before merging it into our staging environment.

Continuous deployment takes this one step further and automates the release to production. Now, it doesn’t necessarily mean that the code is immediately released to production as soon as it reaches the staging environment. Those deployments might still be scheduled to run at a specific time. The key to remember here is that continuous deployment is dependent on continuous delivery.

Okay, now we can talk about tools. Remember, software sprawl? Well, software sprawl can be tamed by adopting an IDP, an Internal Developer Platform to catalog and document metadata about services. At Atlassian, we use Compass, an IDP we built specifically for the purpose of bringing clarity to loosely coupled microservices architecture. An IDP solves the common problems of lack of visibility into the status and risk level of services and the connections between them.

For instance, identifying the service tier and whether or not this service is active and the dependencies between different components. Now, suppose you’re working on a service with dependencies on several other services. Rather than waiting to deploy all the changes at once, you can have each service deployed to production separately behind a feature flag and then enable all the changes at once when you’re ready to launch.

Feature flags can minimize risk by allowing you to deploy changes to production in a dormant state and enable them later, and they give you the flexibility to quickly back out changes that aren’t performing the way you expect. So let’s look at this all together now. When software is designed with a loosely coupled architecture, we reduce the risk of introducing changes to a single service in the application.

If we assign an appropriate tier to this service and document any dependencies, we can identify which services are low risk. When the DevOps team is practicing continuous delivery, we know that the code and staging is in a consistently deployable state, having already passed testing and security scans. With feature flags, we can control when the new change takes effect separately from the process of deployment.

If that DevOps team is responsible for the end-to-end life cycle of the service and is held accountable for the quality of their deployments through tracking the change failure rate, they’re naturally going to focus on ensuring that this metric is as favorable as possible. Now, if all these things are true, then there’s no real benefit to having CAB review changes for low tier services prior to deployment. Even if a deployment does fail, you’ve ensured that it’s only going to have a minor effect on customers or internal business processes at the very worst, and it can be rolled back quickly using feature flags.

By implementing a continuous delivery process for services with a loosely coupled architecture, you can create a set of standards for pre-approved changes, which will unlock the ability to deliver value to customers on a more frequent basis. And by enabling autonomous teams that are empowered to solve business problems by focusing on outcomes over output, we can ensure that they’re incentivized to quickly learn from mistakes, take ownership of the success of the application, and create fast feedback loops.

If you only take one thing away from this session, I hope it’s this, you get what you measure. Measure the right things. And we’ve really just scratched the surface of DevOps here today. There is so much more that can be covered than what I could cover in a 20 minute presentation.

If you’re interested in helping your teams develop a more mature DevOps tool chain and process, feel free to scan this QR code and send me an email or reach out to me on LinkedIn, and thank you so much for your time today. I’m grateful to have had the opportunity to present to you all at the 2024 Elevate Conference.

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

“Optimize Your Potential: Planning For Senior IC Vs. Manager Career Tracks”: Chelsea Zhou with Chainalisys (Video + Transcript)

In this ELEVATE session, Chelsea Zhou, product design manager at Chainalysis, provides insights and guidance for individuals considering the individual contributor (IC) or manager track, highlighting the key differences and qualities required for each role.

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

Chelsea Zhou ELEVATE quote choosing career path starts with deep honest inward assessment of yourself and your motivations

Transcript of ELEVATE Session:

Chelsea Zhou:

Morning, good afternoon, good evening to you depending on where you are. My name is Chelsea, I’m a design manager at Chainalysis. Today I wanted to give a talk on, “Optimize your potential, planning for senior IC versus manager tracks”. Today’s talk, this is the agenda. We’ll go over some of the context. I’ll talk a little bit about my own background and then my incentives to give this talk. Then we’ll cover why you want to hear about this talk.

Whether you’re considering manager track or senior staff IC track, we’ll then dive into a realistic week of a senior staff IC versus a manager so you know what to expect. And then after that we’ll go over what makes a great manager. And lastly, we’ll talk about how to get there if you do want to move forward with the manager track.

So first of all, a bit of intro about myself. I currently work at Chainalysis. Chainalysis’ mission is to solve world’s most complex crypto crime using data as a data product. At Chainalysis, we are currently at a Series F. It’s a pretty late stage startup with employee headcounts over 800 distributed all across the globe. I lead designers in teams across compliance, risk, and core services products. The designers on my team are in Canada, Brazil, and Denmark. All over the place. I have retained and inherited designers. I have also hired and scaled the teams across product design, user research and design technologists functions in the past, both in person and remote in companies across Series A, all the way to Series F. I’m also a best rated manager and quoting an upward review from one of my direct reports here. It’s a little bit of a marketing slide for myself.

Besides some of the qualifications I put down here, on a weekly basis, I was asked by designers across different levels, what is it like to be a manager? If you have read Julie Zhuo’s book, Making of a Manager, you will see that it is very common that almost no companies, no matter how big or small they are, no companies actually prepare how someone should become a manager.

I see there is a huge knowledge gap here and I want to share with you all with my own thinking, learning over the years, and my readings on scaling team and developing talent.

The next point I want to make here is that I know a lot of the audience have engineering and product backgrounds, but some of the takeaways really apply to any functions, such as product design, data science, operations, and much more. I put a asterisk next to mid to senior level in your career because, although choosing IC versus manager track will become more of a pressing topic once you rise up to mid to senior level, it’s actually never too early or too late to think about this no matter where you are in your career.

In fact, I am approached by many college students who are considering a career in tech and they asked me this question, “How do I become a manager,” very early on. Now let’s talk about the motivations behind why you’re trying to become a manager. I have heard people assuming that managers get to boss people around, or managers must make a lot more money.

In many cases it is super common that someone is just asked to be a manager because there isn’t one on the team and the company is growing. However, none of these reasons seem to be a great reason to become a manager. My question back to you is think about this. Why do you want to be a manager?

Many of the staff level people, engineers or designers or PMs I work with actually have been managers before. I’m always curious about the decisions to come back to become a senior staff person after being a manager for a little bit. After my conversations with these people actually, things aside, what I have learned from their experiences and listed down some of the differentiating qualities in two buckets to you.

I want you to really be honest with yourself here when you read through this two lists and feel free to take some time to think through them too. But generally if you…senior staff people, focus on the problem, and the managers are more focused on the people. If you love the time and space to solve a complex puzzle or think through a problem deeply, you’ll probably find a senior staff IC track more energizing. If you’re more interested in other people’s growth and interpersonal and dynamics among the team and beyond the team, you’ll probably find a manager track more interesting.

Now we’ll look at a typical senior staff IC schedule of the week and see how she spends her time. This is actually a schedule I took from one of the staff designers on my team. Let’s look at her schedule. So she starts her off into a sync with the design team on design system. Then she launches into some of the design review that she leads for her future, rest of the Monday, she just has down design until Tuesday midday, where design team all-hands happen on Tuesday. And after that she has some weekly catch up with a PM where she’s a pair with, follow up with the one-on-one with her manager.

The rest of the day she just catches up on Slack and documentation. On Wednesday she attends company all-hands. She has a one-on-one with the designer. Then she has another one-on-one with the PM where she’s co-leading another project. Then she has more time to do heads-down work before joining a design team critique where designers working on adjacent product areas get together. Then, on Thursday she has more time for hands down work and joins a design review for Project A and another one-on-one with another designer she mentors. On Friday, she has more time to design and work. And then the final Project B project review.

On this next slide we’ll be looking at a realistic schedule of a manager. I actually took it from my schedule for the last week where you can see that the manager launching to the same design system meeting similar to the staff designer. Right after she has a sync with a PM where they meet with a solution architecture team on selling a POC and making it a scalable solution. Then she runs weekly execution meeting with a whole design team.

She has an hour or so of deep focus work where she prepares for important meetings coming up in the rest of the week, and she has one-on-ones with her peer user research manager leads a meeting between front end and design and a bunch of other meetings. I’m not going to go over every single meeting she has, but take a minute to look at the difference between a realistic schedule of a manager versus senior IC, except for a few common design team meetings, both of the design staff person and the manager, both of them attend. Their schedules are vastly different. The staff person actually has one-on-ones PMs with designers. But you see that manager spends most of the time in very different types of meetings. There is one-on-one with her reports, her peers, like managers in other functions, cross-functional folks in sales and go-to-market.

There’s almost limited or no time throughout the day for more than maybe an hour or an hour and a half for deep focused work. This means if you are the type of people that enjoy solving a problem really deeply, a manager schedule probably will take your energy from you. I’ll pause here quickly and check the chat and see if there’s any questions. Everybody just mostly intros. All right, moving on. Now you probably have an idea of which path might suit you better.

I want to spend some time actually talking about the qualities of a good senior IC person and a good manager.

Both of the senior IC person and a good manager need to have really great communication and collaboration skills at the core. The main difference is senior IC person has a space to go really deep in solving a problem and gaining that technical expertise in certain areas. They’re often seen as the experts where people go to them and with consult with them to solve a problem.

Versus manager, they may not have the space to go super deep in one technical area. Their job is being able to multitask. They prioritize tasks really quickly and they knock through the most important ones to unblock others. They have the ability to see the big picture and they rally the team that have different opinions and resolve the tensions among the team.

Now you might have this question. Well, the senior IC track seem to have tangible deliverables. They’re technical experts and I can understand what they bring to the table. What exactly does a manager do? Don’t worry. I get this question a lot even from people who work in engineering and product development for years. There’s some principles I want to go through of what a good manager exhibits.

Principle number one from a conscious leader, a good manager is they protect their time really well. You can see that more than other roles, a manager’s day is made of extremely tight time blocks that are called meetings. The manager’s value is directly translated into the time blocks in these meetings. The benefit of this manager working beyond 12 hours every day is at this point deceiving. You tend to lose energy, focus and clarity.

And because many of the manager’s output is directly in meetings, a good manager always think about how to best translate the values into the time and shine these meetings. Maybe they need strict time scheduled to take care of the family right before a very important meeting. Maybe they put time on the calendar for small breaks or exercises like a walk to make sure that they’re consistently calm and focused throughout the day, whatever they need to do to show the best version of yourself. The best managers are the masters of energy. That leads to organization culture that is alive, engaged on purpose, creative, visionary, and playful and refreshed.

The second principle touches on a common dilemma that I see many newer managers have encountered. Many newbie managers in addition to supporting others, cannot let go of doing work themselves. So a lot of the newer managers often assume that it’s a fine arrangement, they could handle it. They don’t want to stop doing actual IC work. And if they do stop doing IC work, they might lose their skills, which will make them harder to be an effective leader.

Unfortunately, that is a mistake I made myself too, and I see virtually every newer manager make, which is continuing to do a lot of individual contributor work past the point that is sustainable. When you pass the point when it’s sustainable, go back to principal one, you’ll lose your energy, you’ll lose your focus, which is bad for the entire team.

The third principle is actually getting to the core of a manager job, which is be a good coach. Time usually reveals the truth. You’ll see the best employees usually don’t tend to stick around for years and years under a boss who treats them poorly or they don’t respect, and vice versa. If a manager don’t really truly respect or care for her reports, there’s no faking either.

The closest analogy I can come up with for the manager role is usually a sports coach. Managers in some way are very similar to sports coach. They use every encounter as an opportunity to evaluate and coach their team members. A good manager always sees the big picture. They evaluate all the time and they make sure that the right people are doing the right job and they support and advise for those who are doing a great job and they move people around who are not doing a good job.

The fourth principle here, and the last principle, is actually showing as much candor as possible. A lot of people probably heard of Kim Scott book, Radical Candor, is a manager must-read. Even if those of you who are not really considering manager track it helps you reflect on what type of leader you are because you’re senior and a lot of your job is to give feedback. And this book forces you to really reflect on what type of feedback you tend to give that are often masked behind superficial niceness.

In fact, being truthful and delivering the timely feedback, both positive and constructive feedback, is the best form of love you can have for the team. This means you take opportunity to inject self-confidence in those that really earn it. Use ample praise, the more specific the better. It also means delivering constructive feedback timely. And finally, when you’re in the one-on-ones, spend more time listening to your team rather than speaking. One of the greatest gifts we give one another is to listen deeply what other people really want. And this will come through when you give the team the comfort and space really speak and communicate with you what they really want. I’m going to take a quick pause here and see if there’s anything in the chat.

Are a lot of managers about to get a review code? I think there’s some good questions here. I’ll try to follow up, but if we run out of time, you can always reach me later. Now we’re launching to the next part of this presentation, which is how do I get started? How do I find my leadership style? Whether we want to venture into the manager track or senior IC track at this point, both type of roles require you to figure out the leadership style you have. So this is actually applying to both. It’s like a little exercise or thinking access, you could probably do.

If you take any formal leadership training courses, this is a common framework or diagram that helps frame six types of leadership, from affiliate, democratic, commanding, pace setting, visionary, to coaching. Most of the people are probably a mixer of one or two among the six. It’s really important to be super honest about who you are, and what leadership style can really bring out the truest form of yourself.

You really got to be real. Best managers are true to themselves. And earlier in my management years, I made a mistake to only think that there’s that one strong commander type of a leader where I faked my personality to try to be someone who I’m truly not. And now I really show up at work and being the true self, which is a mix of pace setting and affiliate, where my strength shines through by being goofy and yet forthcoming at the same time for the people on my team to do their best work.

I think the next step is just to try it. Building leadership skills is not that hard, you can start anytime. Opposite to many people assumption, leadership is a skill that is not about bossing people around. It is about speaking the uncomfortable truth when other peoples are really scared to do that. Leadership is about standing up for the team in crisis and letting team take credits when really good things happen.

Leadership is about letting go too. It’s liberating to let go of your own agenda and how things should be done and see how other people come up with how they resolve things. An easy exercise you could start today is probably starting a lot of one-on-ones with your fellow IC or peers and try mentoring and see how you like it. And then back to the exercise I gave.

Do the punch list of whether you like it or not and how you want to actually manage your time and schedule, and see whether your energy really spikes in these one-on-one sessions, or you actually prefer the deep dive and deep work. So lastly, management is really a journey.

I think the biggest takeaway here is to reflect as much as possible and be true to your motivations, your personality, and your true self. As we wrap up here, I think… this is my contact info if you want to follow up with more questions. I probably don’t have time to get to all the questions here, but good luck to you and enjoy the rest of the conference.

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

“Empowering Communities Through Mobile App Development: Inspiring Girls & Women with AI & App Inventor”: Dr. Natalie Lao with App Inventor Foundation (Video + Transcript)

In her ELEVATE session, Dr. Natalie Lao, Executive Director of the App Inventor Foundation, discusses the organization’s focus on empowering communities, particularly girls and women, in the field of tech and AI.

App Inventor is a free and open-source web platform that allows anyone to create mobile apps, with a focus on accessibility for under-resourced populations.

Natalie Lao ELEVATE quote our goal is to reach million girls by and teach them ai and technology development

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

Transcript of ELEVATE Session:

Natalie Lao:

Thank you everyone for joining the session. I’m really happy to be able to share some of my work and my organization’s work, and we’re really focused on how do we empower communities around the world in tech and AI, and specifically focusing on girls and women. So Sukrutha already gave a great introduction for me. I’m Natalie.

I’m currently Executive Director of App Inventor Foundation. We’re a 501(c)(3) nonprofit in the US and I’m also currently Expert on Mission for UNESCO. I’m developing the UN’s AI competency framework for school students. In the past, I spent 10 years at MIT and I’ve also worn several other hats in tech, as a high school teacher, and in the startup world.

First, what is App Inventor? We’re a free and open source web platform that allows anyone to make mobile apps. The reason that we focus on mobile apps is because it’s the most accessible modality for under-resourced populations. In the US, even about 15% of households don’t have a computer or a tablet. A smartphone is their only computer in the household, and it’s a great way to get children involved in tech and across the world and globally, that number goes up to 50% in some regions.

We’re able to have a lot of impact by teaching engagement and technology through smartphone usage. App Inventor has had 10 years of research from MIT and Google behind it, and our goal isn’t just to teach how to code, it’s to engage students in community engagement and development. We see that after one year of learning how to create apps with App Inventor, students feel like they’re able to effectively change their communities.

Here are some of our impact numbers from the past year. In 2023, we had 11.2 million users from every single country in the world. This has been really huge for us. We’re also really happy that about half of our users come from the Global South and the developing world. This is our global reach. The US is our number one user base, but we have huge adoption in Asia, the Middle East, and we saw last year in Saudi Arabia our growth was over 400%. That was also super amazing.

We also work with organizations both domestically and internationally. We have a partnership with Amazon Future Engineers where we go into classrooms and we teach teachers how to work with conversational AI and App Inventor. As I mentioned before, we’re partnered with UNESCO and UNICEF. And then also with Girl Geek X, we recently joined The AI Forward Alliance, which is sponsored by Technovation, UNICEF and the Grameen Foundation.

Our goal is to reach 25 million girls by 2030 and teach them AI and technology development. We’re taking a lead in mentorship and teacher development in that. If you’re interested, actually we’d love to see you reach out and I’ll have information at the end of my presentation for how to join us. If you’re familiar with Scratch, we see App Inventor as kind of the bridge between something a bit easier, like Scratch, that’s for elementary and middle school students, and then something like Python. That’s where we fit in, in the development pipeline.

I briefly wanted to go through our education philosophy, which really goes into how we design the platform and all of our educational programs. Our philosophy stems from constructionism, which Seymour Papert said best. We believe that, “Children learn best when they’re actively engaged in constructing something that has personal meaning to them.”

With that, we also look towards self-efficacy theory, which is rooted in over 40 years of education research. It’s basically if students feel like they’re able to do something, they actually gain the skills to do that faster and more competently. If we break that down into its four components, this is how we run all of our programs.

The most important component of self-efficacy is an active mastery, which is successful hands-on learning experiences in AI or development. At the end of every App Inventor workshop or class, we want students to walk away with a fully developed app for their own smartphones, and that’s kind of a complete experience of success.

The second is vicarious experiences, which is seeing and hearing about people of similar backgrounds succeeding in these activities. As we know, women are underrepresented in AI and tech, so we do our best to work with organizations and feature stories about girls and women doing amazing things in their community with AI and tech.

The third is persuasion and support, which is being encouraged by respected friends and advisors. In our programs, we actively try to have scaffolded activities where students are encouraging each other, and we also bring in mentors to give students additional feedback, constructive feedback, and also of course positive encouragement.

The fourth is physiological experiences. We want all of our activities to be non-stressful and for students to have positive reactions to them. One thing I wanted to share is our Appathons for a Cause program. We started this program about two years ago in order to build community across the globe. We’ve had millions of users, but our team is really small and we didn’t really know what our students were building unless they made New York Times and they shared it with us.

We launched this new competition that’s completely free and virtual. Anyone of any age can attend. And the goal is to find a problem in your community that you’re really passionate about and build an app for that problem. We ran it last year for the first time under the App of the Season banner, and we saw an extremely diverse range of participants. 55% of students who participated came from the developing world. The youngest was eight years old and the oldest was 60 years old.

We had some really lovely family groups who made apps for grandma or the community senior center. 43% were women or non-binary, which is a huge number for these types of events. We also saw that about 60% of participants were beginners to programming. It’s a very easy entry level hackathon to participate in. And in the past year we launched our own chatGPT and image AI extensions, and we saw that 43% of app submissions used AI, which is something, of course, that we’re all trying to encourage.

Now I wanted to share a few stories of our students who’ve created some amazing apps. This is Gitanjali Rao. She is currently actually a freshman at MIT, but when she was in high school, the water crisis in Flint, Michigan, made headlines and she really wanted to help, so she used App Inventor and some really inexpensive, affordable sensors to create an app that detected the water quality and could tell when lead was in the water. She donated this to communities in the area, and she was named Time Magazine’s Kid of the Year. And currently, she’s still using App Inventor to create new apps. Her newest app is one that’s meant to be anti-bullying, and it’s called Kindly.

We also work extensively with communities internationally. The Dharavi Slum in India is the largest urban slum in the world, and there’s a group there called Dharavi Diary that educates women and girls in tech, in civil engineering and a lot of programs, and we’ve been partners with them for many, many years. A few years ago, this group of girls found that there was a lot of sexual harassment in their community. Their mothers, when they came back from work, would get called out and it would generally feel very unsafe.

They used App Inventor to develop an app for women in the area that if you shook it in your pocket, it would have this very high-pitched police siren. It would scare people off. And when you did that, it would log it in a cloud database and share with other people on the network so they knew when these things were happening and to avoid the areas. And they recently gave a TED talk, I think, in India.

Then this past year we worked with a team of girls from Montana in the US. In Montana, there are lots of indigenous peoples, and there’s also an issue with human trafficking, especially of the indigenous community. They created an app with AI and databases that taught people how to find when this was happening and kind of train students to recognize in AI generated chat rooms, what kind of questions lead up to this type of behavior.

They also created a database for people to report when they potentially saw human traffickers or victims of human trafficking, and they won the congressional app challenge for their district. We got to meet them in Washington DC last year! And since I have a bit of time, I just wanted to share a video of another team who won our app challenge this year. This is a team from Texas who created a mental health journaling app with App Inventor and AI.

Jocelyn: Hi, I’m Jocelyn.

Jack: I’m Jack.

Jocelyn: And today we will be explaining Calmify and our inspiration behind this app was advocate for mental health wellness through a journaling system.

Jack: What makes our app unique is its special AI emotion detection. After we finish setting up this new user account, the first thing we’ll be greeted with is the journaling page and the different happy and sad emojis you see up there help the user to track their mood across past journal entries.

Jocelyn: Here are some different journaling scenarios, and a user will have the ability to record some roses, thorns, any emotions throughout their day.

Jack: They can also add a picture, really nice picture in my opinion, and they can add some activities they did during the day. And so after finishing up their journal entry and submitting, the app will take the journal entry and plug into OpenAI software to detect how the day was, what emotions filled it, loneliness, happiness, stress, for example and will recommend a personalized arrangement of features to help address any negative emotions present. If it’s a happy day, it might just congratulate the user. If it was a stressful one, it could recommend some stress relieving resources, and we will be going over these resources next.

Jocelyn: Here’s some modules and you can actually edit your profile. So your first module is a personal AI friend you can chat with.

Jack: Our next module or resource is the memory lane where you can view memories you added or the app added from your happy journal entries, and researchers have found that looking and reminiscing over your past happy memories can help improve one’s mood.

Jocelyn: All right, our next module is an activity planner. So based on the activity you have chosen, the app will design an activity plan based on your location.

Jack: Next are multiple music therapies you can use to calm yourself, meditate, or to help you fall asleep.

Jocelyn: Our next module are stress relief techniques, including paper ripping and pillow punching.

Jack: Finally, we have some help resources, including hotlines and what they’re about. You can dial from the app directly if you need to.

Jocelyn: Thank you.

Natalie Lao: I love this video and I love to share it with as many people as possible. In our app competitions, we encourage students to choose a problem they’re passionate about in their community. Over the past three years, we’ve seen a huge uptick in mental health related apps. This is just one of the amazing ones we’ve seen.

Jocelyn: Hi, I’m…

Natalie Lao: This is my last slide. We’d love for you guys to reach out and get involved. Our mailing list can be found at the bottom of our website appinventorfoundation.org. If you’d like to volunteer, there’s a lot of opportunities in judging for our Appathons. If you speak other languages, translating our open source education materials is also really helpful.

Our code base is open source, so if you want to get involved technically, we always welcome that. And if your company has a CSR program, we’d love to get in touch.

In the next month, we’re actually collaborating with MIT to launch their first global AI hackathon, and we’d love to have community judges sign up. If you’re interested, please reach out and sign up for our mailing list and I’d be happy to take any questions. Oh, yes. Yes, I saw the first question about how to get involved.

Yes, about IP protection. The creator of the app owns all of the IP. Most of the students who use our apps, they’re able to, sorry, who use App Inventor, they’re able to download the files and upload it to the Google Play Store or the Apple Store, and they own all of that. We don’t take any part of their profits. We’re completely nonprofit.

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

“Product Management In Public Health: Fireside Chat With The U.S. Digital Service At The White House”: Itir Cole, Mary Moreno, and Purvi Desai with U.S. Digital Service (Video + Transcript)

In this ELEVATE session, Product Managers Itir Cole, Mary Moreno, and Purvi Desai from the U.S. Digital Service discuss their experience applying product management in the federal government.

They emphasize the importance of building relationships, being resilient, and highlight the significance of open communication channels and repetition in fostering trust and ensuring effective collaboration. 

Itir Cole ELEVATE quote we work remotely but we work for the federal government

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

Transcript of ELEVATE Session:

Itir Cole: Hi. Thank you for having us. We’re excited to be here, and excited to share with you our experience. My name is Itir Cole. I am coming to you live from New Jersey. I’m joined here by my colleague Mary, who’s calling in from Colorado, and Purvi, who’s calling in from Texas. That’s the beauty of USDS.

We work remotely, but we work for the federal government. To introduce our agency a bit more, we are with the U.S. Digital Service, which is a federal agency, and we report into the executive office of the president.

Our mission at USDS is to deliver better government services to the American people through technology and design. We do this by using our collective expertise and our unique position to do the most good for the most people in the most need.

We collaborate with public servants throughout the government to address some of those most critical needs on high priority technology projects, and ultimately deliver a better government experience.

We work across multiple agencies. The way that we work is we are a central hub of technologists, and we get detailed out to agencies as they have priority projects. We do this by bringing our best practices from our various disciplines.

Of course, we are here representing product management, but we also have engineers, data scientists, designers on all of our projects, and we also have procurement, talent, operations, and communications. So, we are interdisciplinary teams.

Today, specifically, we’re going to talk to you about our experience applying product management in the federal government. We’re going to be drawing a lot from our experience being detailed to the CDC and bringing our public health experience. With that, let’s get started. I’m going to pull up our questions.

The first question we had was around how we balance bringing in new approaches to product management in traditional, maybe more rigid structures in the public sector. So I’ll give you… Mary, do you want to take this one first, and we’ll pass it over to Purvi?

Mary Moreno: Sure, yeah. Itir, maybe it would make sense for us to also introduce ourselves really briefly too, just so everyone has a little bit of better background. Why don’t you go first, actually, and then I’ll introduce myself and answer the questions. Does that sound good?

Itir Cole: Sounds great.

Mary Moreno: Then we can hand it off to Purvi? Cool.

Itir Cole: Yeah, let’s do it. I mentioned my name is Itir Cole. I have been in product management for several years now. My experiences in database administration, that’s how I started. But my formal education is in urban planning.

I love studying systems, going macro and then diving back into details. That led me into GIS, Geographic Information Systems, studying spatial data, I really love that. That’s how I landed in database administration.

From there, product management naturally came about. I just saw that there was a need bridging the gap between leadership and the work that we’re doing on the ground. So I started to fill up that space as a product manager, and decided to more intentionally lean into that work. So, that’s me.

Mary Moreno: Thanks. I have a degree in chemistry in German, so I’m just going to double down on the weirdness of a variety of backgrounds. But I’m a product human definitely, through and through.

A lot of my experience prior to coming to USDS almost a year ago, which is crazy, is mostly in healthcare technology. So I got my sea legs in healthcare technology at Athena Health, which is a large electronic medical record company out in Boston, where I’m originally from. But I moved to the mountains at some point, so I’m a reformed East Coaster, but definitely health tech nerd through and through.

Newer to government, so I can answer the question about existing processes in government to a degree, but I certainly don’t have the breadth of experience in the federal government as Purvi does, who you’ll hear from in a moment. But my approach to existing processes is… Well, I’ll be frank.

I am generally allergic to process, I say a lot. I do not love process as a product manager, and the government has a lot of processes, there is a lot of red tape and bureaucracy. We have this concept at USDS called bureaucracy hacking.

This idea that there might be a way for us to be innovative in our approaches, or ensure that the process in place is the right one for the job to be done instead of just following the status quo and checking the boxes, because that’s what people before us have done. That’s something that I really love about USDS, so I take that approach with me to the CDC when I’m faced with a process that we have to follow, or a framework that is typically used.

One example recently is that we went through a security review for the product and team that I’m on, and that product and security review didn’t quite meet the needs of a true agile product development team, so we brought the team along with us. We had the IT department on the phone, and we explained, “We don’t actually track costs in this way in an agile environment. We don’t break out the cost per sprint, but here’s what we could do instead.” Here’s how I think about whether we’re on track or not. Squaring their circle on what the IT department expects and meeting them halfway, but also bringing them along for the ride on those processes. Purvi, why don’t you introduce yourself? I’m happy to-

Purvi Desai: Thanks, Mary. Thanks, Itir. Hey, everyone. My name is Purvi Desai. A quick intro. I’ll pile on. I like to tell people that I live a portfolio life, and I’ve done a little bit of a lot of things. My start actually is, I’m a Veteran. I went to the United States Air Force Academy and I was a commissioned Air Force Officer for about seven years. I’m also a military spouse, so if there’s any military dependents out there, you know how hard it can be to find jobs and keep up with your career as you move along with your active duty spouse. So, that was my first experiences.

After being active duty, I moved into more traditional program management. I’m an engineer by trade, so my master’s and undergrad are in systems and industrial engineering, so I did a lot of reliability work for large acquisitions, so think buying airplanes and airplane systems for the services. From that, is where I found my love for innovation, and moving into the DevOps and the product career fields. I really helped stand up a lot of the Air Force’s innovation cells and software factories, as you could call them.

I worked in something called BESPIN. BESPIN is an organization down in Montgomery, and they’re really focused on digital transformation and mobile application delivery for business systems for the Air Force. Then moved on to more infrastructure-related backend things, such as running a hybrid cloud platform for applications across the world. So, all over the place. But really, at the intersection, I’m really passionate about serving. So throughout most of my work, even when I was a consultant or worked for a private industry, we were supporting government contracts.

Service is central, and USDS is a great place to do that. Working at the CDC has just expanded the horizon of how unique each government agency can be. But, at the same time, a lot of those same problems manifest in different domains. It’s great to be able to see across them, and bring some lessons learned from different government agencies into other ones. Process, let’s talk about that. Bureaucracies aren’t inherently bad. Having a process isn’t inherently bad. They bring important structure, stability and compliance to projects, and sometimes you just can’t get away with it, especially working in the government.

I like to orbit the giant hairball. You want to stay as close to… You don’t want to be relegated off the island. But, you want to be sure that you could actually move and balance things in the right manner. Like Mary said, having a good understanding of what is in scope and an out of scope is important. You want to start really with relationships, I think, though. Anything you want to do, you want to make sure you have a valued colleague relationship, so you’re not that heretic with wild ideas.

When you come in and you want to bring the IT professionals, and the security professionals, and the product people all together on a phone call to go through this security review, that’s not going to be just wild. It’s going to be like, “Okay, let me hear you out.” So invest in that relationship first, focus on those shared outcomes. Everyone wants the security review to happen, and then let’s give the existing process a fair shake. That’s probably a different answer from Mary, who’s newer to government. I’ve worked most of my life in government.

I feel like a more iterative approach to change sometimes is the right way. You’ve got to bring those folks along, like Mary said, and you can’t… Lasting change sometimes takes a while. Humans are humans at the end of the day, and change is hard. So taking people along, having an iterative approach to changing process as well. Maybe you just tweak one or two things here, and you meet their needs and you assuage their fears, and you’re building that rapport while you’re going along. I think that can help play that long game a little bit, and bring that lasting change for a while.

I will say, an important caveat, sometimes there is things that you just need to address immediately, staying true to the values that we know are important. Balanced teams, empowered teams, having certain cultural things, you need to address those right away. But, there might be some things that you could give a little bit on. So it’s like with anything in life, it’s a give and take, it’s an iterative approach. Focus on the humans because, at the end of the day, that’s what we all are.

Itir Cole: Excellent point there. I will echo both of those comments. I think where I might add is, yes, relationships are super important. People need to see that you’re reliable if you want them to trust you. When you’re trying to bring an innovative practice, you’re really asking for culture shift, probably at the organization level. Showing people that you’re reliable and you’ve built that relationship, I think is really important.

Another piece in government, probably, is being resilient. You’re probably going to come across a lot of closed doors as you’re going through this process of changing behavior, changing processes. Staying resilient, and staying strong, and looking for… Being like water, find another way to get there. That would be my recommendation. Should we go to the next question?

The next one is around fostering open communication. Of course, we’re talking about building relationships, but how do you ensure that open communication channels are effectively established and maintained to foster that trust we mentioned, especially when you’re integrating a new problem-solving approach? Should we go backwards this time? Purvi, do you want to go, and then Mary?

Purvi Desai: Sure. Thanks, Itir. Effective communication is so important everywhere, but especially in government. You hit the nail on the head. It is critical to foster trust, implement any new approach and really meet those successful outcomes of that approach.

Working in the government, and then especially in public health, we have many different stakeholders and customers all with varying access to communication methods. They also have varying levels of a shared vocabulary, and then there’s varying levels of how comfortable they are, according to their own organizational cultures, voicing concerns, being curious, and then just plainly being engaged in a large and complex group.

The first problem usually to overcome is ensuring that we have a shared platform to communicate on. Once we have that shared platform, we could then foster the dialogue. There’s some great tools out there, Airmeet being one. But I would caution at introducing new tools when the stakes are really high. Less complexity is probably better, and you might want to spend that capital on harder problems to solve, rather than teaching someone how to use Slack. So, having a common platform is important.

The next thing I would say is, being an active facilitator is also crucial. We have so many different folks at different levels of government, from different perspectives in the CDC and public health. We deal with tech people like me, and Mary, and Itir, but we also have EPI’s in the mix, we also have procurement folks. We have a ton of folks. Being able to be a translator and drawing parallels is really important to keep the engagement going, and really spark the action that needs to happen.

You’ll have to go deep in your domain to make sure that you can identify those areas. Sometimes you see a connection, and folks might not engage on that. You might have to facilitate that connection and that communication to happen a little bit more. Once those floodgates open up, it’s a little bit easier to get going. I have a colleague actually at the CDC who loves to say, “Repetition doesn’t spoil the prayer,” and it’s so true.

Most of the time, I hesitate on repeating information, or messaging, or repeating a question and an answer, and I’m routinely corrected. There’s always people who are hearing it for the first time, or they’re just now understanding the complex nature of public health or the government, and they’re finally hearing the message in the right context. I’d say, don’t be afraid to share more than once or twice. I think that’s it. Back over to… Maybe Mary has some additional thoughts there.

Mary Moreno: I’m so upset I have to follow that answer, Purvi. That was so good. I was just clapping and saying yes the whole time. We have the same colleague that says, “Repetition doesn’t spoil the prayer,” I love that. I love that you used that quote. I so agree. I’m going to add to it and say that…

Saying things in different ways can sometimes be a really effective way to communicate how we’re solving a problem for the first time. What I mean by that, more tactically, is just because you’ve said the words doesn’t mean everyone understands those words in the way that you’ve communicated them.

Sometimes a slide is helpful. I’ve actually used this tactic a couple of times, where you bring up a Mural board or a whiteboarding technology of choice, and you have someone add stickies and questions, and they’re more actively participating.

Or you have a diagram or an architecture diagram, sometimes that’s an effective communication tactic. Then something that we say at USDS is, “Show, don’t tell.” Sometimes just telling isn’t enough. Sometimes you just have to be like, “Hey, I’m doing this,” and then you show the results of the thing that you’re doing.

What I mean by that is, recently, we were coming up with a way to basically slap a UI, a user interface, onto this very backend heavy piece of technology to demonstrate how… This is a meta example, now that I’m saying it out loud. But to demonstrate to users how this backend technology actually improved the visibility that they had into data, just generally speaking, and getting the excitement… Not everyone understood why that was so important.

But getting that idea out in front of some of our potential users, getting feedback and then showing that feedback back to our leadership team was really, really helpful in demonstrating like, “Listen, this idea is actually getting some traction. We have some data here that says so.” Sometimes that can be a really awesome way to double down on telling, is just showing. Then lastly, I’ll add, one tactic that I employ is a monthly session where I bring everyone together who’s even interested, semi-interested, in my project, once a month. I call it the Interested Party Session.

I have a look back over the last month, and a look forward over the current to next month, on how the teams are orienting themselves, and how we’re chipping away at objectives and outcomes. I make that more of a dialogue where people can ask questions. Or, “Have you thought about this thing? Have you thought about that thing?” It aligns everyone, even though they might not be super involved in the day-to-day of the project, to what it is that we’re doing.

Itir Cole: Such excellent points. I’m happy to wrap up our answers to this question by adding that, yes, repetition is incredibly important. You have to continue to manage up, manage sideways, manage down, get your information, get your message out there.

The great thing about being able to work within a group setting is that you don’t have to do that alone. You can be strategic on sharing that message across the organization through your colleagues, which is what we do. If a message needs to travel up and down the organization, we can say, “Okay, this is how we’ll split ourselves across the hierarchy, and everyone go and have this conversation, and then come back and report back. Let’s see what message actually traveled across.” I think that’s a great one.

And, knowing how to influence the people that make the decisions. Maybe you’re not influential, but someone else is. How can you get in front of those people to get your message across, and have them support you or endorse your idea as you’re pushing change across the organization? T

o then wrap up our session, we have one last question for us to answer for all of you. That is, what role does user-centric design and iterative development play in creating public health solutions that are both effective and user-friendly? Mary, do you want to start us off?

Mary Moreno: Sure. This is a really big question because, I think, if you’re a product manager, then you’re obsessed with user-centricity. Often I’ve been at companies in the private sector where product managers are considered voice of the customer even. We are so focused on users that we are the users themselves, and can often speak for them.

One of the things that I think has been helpful, as far as ensuring that the thing that we’re building is actually making an impact, is that the same person that Purvi and I both work with, who talks about repetition not spoiling the prayer, also talks about customer benefit. He’s a huge advocate of outcomes-oriented product work.

One of the things that we push to do within our division at CDC is basically benchmark where we want to hit outcomes for the projects that we take on before we even get to a point where we even know what it is that we’re building. For example, time savings, or cost savings, or number of touches. If it’s not intervened, there’s no introduction to human error or something on a process.

One of the ways that we’ve been able to tell the story about the impact of my project is by concentrating on a pre-workflow and a service design blueprint that explains what happened before at this specific user group, how they were using, or not using in this case, a specific data source, and how difficult it was to make sense of that data before this tool was introduced.

Telling the story in terms of the service blueprint, and then showing the after effect of having the technology in place, and what impact it had. Not just on the user flow, but as a measurement of time saving.

Being able to do that time study even in an analog environment where maybe we don’t have monitoring in place like we do in private sector, and being able to say, “Before, this was a really bad process, and it took users 20 hours to process this data. After, it took them two minutes, because we automated the entire process. That’s a huge time savings.”

Being able to tell that story and getting really deep into your user’s workflows and stuff is really, really impactful and helpful in storytelling.

Purvi Desai: Perfect. Mary, you chatted about user-centricity so well that I feel like there’s almost nothing to add. I will make a note on maybe just the iterative nature of how that’s so important as well.

Working in public health, or maybe in government in general, our problem space doesn’t usually require brand new innovation. It’s usually modernizing existing functions or improving capabilities. This was a common scenario that applications and systems faced in the last pandemic, when we needed our existing systems to be able to sense and respond that novel disease, and then respond to it at that impressive scale.

We just weren’t able to keep up, and there were a lot of workarounds that happened because we didn’t have that agile or iterative development model in place. Those changes that were required would’ve taken an impressive amount of work because the scaffolding to incorporate them just didn’t exist.

It’s so important right now to create that scaffolding, to create the ability to add new capability while you’re still executing the mission. The public health mission doesn’t go away in times of normalness, in times outside of a public health emergency. But, you want to have that ability to rapidly include things.

Having that capability not only in the actual architecture of your systems, but also the flexibility in those wraparound services. In our jurisdictions, you know a lot of our folks rely on third-party vendors to help them execute their work. Do you have flexibility baked into the procurement contracts that might allow that scale to increase, or the support that they give? So that iterative nature not only within the development of the actual system, but also the iterative nature and the agility and flexibility for all of that wraparound service and support.

Then I’ll just add one brief bit. Being user-centric, make sure that once we have this ability to sense and respond, that we actually sense the right thing. Like Mary mentioned, we’re actually measuring the right things and sensing those right things, and then responding in the right way, because we are the voice of our users. We are so user and customer-centric, that is inherently ingrained in us. So, plus one. It doesn’t matter what… I shouldn’t say it doesn’t matter. It matters what we do. But, the way we do it too is equally important.

Itir Cole: That was awesome. Thank you both. I do see some questions. I realize we’re down to three minutes, so maybe I’ll give us some of the questions to respond to. There’s one here from Patty who’s asking, “How do you get stakeholders to be committed to goals if many areas are incentivized in different ways? Or specifically, to commit space and mind space for the project?” I can give you a quick answer, and I’ll turn it over to our panelists too.

You stay persistent. You have to remind them that you’re not going to let go of the goal yourself. So what I would want to avoid is making the ask towards the goal, and then just letting the person do it on their own time. But going back and reminding them, “Hey, I’m still on this. I’m not going to give up. I’m going to keep coming back to this ask.” Reminding them of why it’s important, as far as which outcome, I think that’s really helpful. Mary? Purvi?

Mary Moreno: Do you mind if I go first, Purvi?

Purvi Desai: Please.

Mary Moreno: Okay. I would say that there are likely different ways to storytell so that it resonates with your audience. If there’s truly nothing uniting these audiences together, if you can’t figure out a way to pitch or storytell to an audience that might not directly see the impact on the face of what it is you’re doing, maybe they’re the wrong stakeholders for you.

But, if you really strategically think about what it is you’re trying to get done, and then put on your user empathy hat as a product manager, and you’re like, “Okay, if I were this person or I was this team, what would I care about? What are their goals, and how do I make it make sense to them in the framework of their goals, or their strategy?” That’s one of the hardest things that we do, as we’re leading up and across orgs.

Purvi Desai: I would just add, we have the luxury in government that we don’t have to win. It is not an individual win, it’s a communal win. The pressure of getting ahead or not…it’s really what Mary said. We have a shared common goal, and it’s really just looking at all those different perspectives of meeting that goal. It’s not winning individually, it’s winning collectively.

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

ELEVATE 2024 Career Fair Kickoff – Employer Intro – U.S. Digital Service (Video + Transcript)

U.S. Digital Service’s Deputy Director, Talent Management Shavonne Holman and Talent Operations Specialist Mariah Casimir share why they enjoy working at the U.S. Digital Service and how the interview process works. Learn how to apply to U.S. Digital Service!

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


Shavonne Holman:

Thank you, Angie. I’m so glad to be here. Again, my name is Shavonne Holman and I’m the deputy director of talent management. And just super excited to be here today to talk with you all about what I would say is one of the coolest organizations in the federal government, the United States Digital Service. And here with my colleague, and I’ll allow her to introduce herself.

Mariah Casimir:

Hi everyone. I’m equally as excited as Shavonne to talk with you all today about the US Digital Service. As Angie mentioned, I am the onboarding guru for USDS, so I’ll be talking about all things hiring once I get through the presentation. So I’ll pass it back to Shavonne to get us started.

Shavonne Holman:

Awesome. Thanks, Mariah. And so the United States Digital Service was founded in 2014 to really change the government’s approach to technology. We’re located in the executive office of the president at the White House, and we are a nonpartisan organization on a mission to really deliver better government services to the American people, and that’s through technology and design.

We do this by really partnering with other federal agencies, and I think we work with about 30 at this point to really create, update, redesign, reimagine, and transform government services for the better. USDS really tries to fulfill our mission by working across government and approaching our work, keeping our six core values in mind, which are hiring and empowering great people, finding the truth and telling the truth, optimizing for results, not optics, going where the work is, creating momentum around that work and designing with users of services, not for them.

This really means that we are human centered in all the work that we do. As mentioned earlier by Angie, one of the things I love most about working at USDS is that we are a limited term serving … we have a limited term serving structure at the White House, and we work on projects that really impact the American people.

But because of our term limits, our employees really bring their skills and passion to do the greatest amount of good in a limited amount of time. And so that’s super exciting to know that we have such smart people coming here for a limited amount of time to really use what they have, use all of their expertise to make the most impact to the American people. And this also really means that we are constantly hiring top talent to really support these projects that shift the way the government works.

Because we’re on those limited terms, we’re always looking to backfill with top talent to keep these projects going that really impact the American people. And so our teams are a mix of engineers, data scientists, product managers, designers, procurement specialists, communications, operations and talent professionals. The list goes on.

And for nearly 10 years, we’ve grown from just a handful of folks to more than 200 professionals that each play a vital role in USDS’s collective success. And through that time, we’ve really enabled the delivery of dozens of improved services and supported the curation and formation of digital service delivery teams to really expand and continue the important work that we’re doing, really trying to create a long-term impact in the federal government.

USDS selects projects that really bring about substantial change for the greatest number of people in the greatest good, excuse me, in the greatest need. And so our projects touch the lives of American people like veterans, immigrants, refugees, children, patients, doctors, small businesses, people with disabilities, job seekers, students.

The list goes on. Some way, every American should be represented, and we want to make sure that the services that we offer are directly impacting those people. I really just wanted to take some time to share a few of the recent projects that we’ve worked on. One being working with the Department of Veterans Affairs.

We’ve actually worked with them for over nine years now, which has included us helping them relaunch their main website, va.gov. And this really allows for veterans to access the services offered by the Veterans Affairs. Over time we’ve seen that about half of all veterans visiting the VA’s website, were using a mobile device.

Our support led to the VA building and launching a top-rated mobile app in late 2021 that lets veterans do an expanding array of important tasks such as checking their benefits, booking appointments, messaging healthcare providers, and looking for lists of their VA payments. And since its launch, over one million veterans have used the app and it’s garnered nearly perfect ratings in the app store with over 80,000 five star reviews.

And so we’re super proud about that. We’re super thrilled of the impact that it has made in really helping veterans to take advantage of the benefits that are offered to them. We’ve also worked with the Department of Health and Human Services. We have a zero to five life experience team.

And that team really sets out to listen to families nationwide and really understand their lives as parents of babies and young children. And we really want to see how the government can reduce burdens from programs that are offered to them and better support them through those programs.

Based on the research that we found, USDS and HHS launched several projects to support better maternal and child health with one of those projects being the newborn supply kit. We also supported the effort in response to the infant formula crisis last year. So we’re doing amazing things, right? Through dedication and collaboration, we are really making government services more accessible, secure, and user-friendly one project at a time.

And if anything that I said today has piqued your interest in any way, and you have questions on how to be a part of this impactful work, we ask that you stick around to hear my colleague Mariah, who will be diving into the hiring process and how you can be a part of the team here at USDS. So thank you so much, and I’ll hand it over to Mariah.

Mariah Casimir:

Thanks, Shavonne. All right, everyone. So I’m going to dive into what our hiring process will look like into government, especially for USDS. So that first step will be to submit an application. It’s super short and takes about two minutes to complete. And as Shavonne mentioned, all of our roles are term limited, meaning we are all here for at least two years. This is to keep, like she said, a constant influx of talent into government.

The next step would be that our technical experts will review your resume and application criteria. So that means our team will evaluate your application and decide if your background and experience may be a good fit for one of our communities of practice. So that includes product, design, engineering, including data science, procurement, operations, talent and communications. If your resume is a good match and a recruiter reaches out to discuss your … a recruiter will reach out to you to discuss your background in USDS.

You’ll speak with a technical talent recruiter who will answer your questions about working at USDS. You’ll also have the opportunity to tell us about your background and go over any of your questions. And then after that, you’ll begin interviewing and USDS evaluations. So you’ll participate up to three interviews.

That’ll include two technical and one behavioral to address your technical skills and knowledge in your field, as well as problem solving skills, communication strengths, and other typical interview questions. And if you make it through the first part of our hiring process, you’ll then move into the onboarding, which can be a totally unfamiliar territory for most of our people joining USDS, which is completely okay because we’re here to walk you through every step of the way.

You’ll first schedule a call with the onboarding team to congratulate you and outline what the next steps look like for starting the process to join government. If everything goes well and you’re ready to move forward, you’ll then work with our formal HR partners to secure an official tentative offer of employment into government.

If you accept your tentative offer, that’ll bring you to the next step, which is a background investigation where personnel security and the FBI will work with you to kick off a formal background investigation at the national security level. Once the security steps are cleared, you’ll then be scheduled for a drug test, and after that, that’ll be the last step.

You’ll then receive your firm offer and get started. That means that you’ve made it all the way through the process. You’ll then have a start date and get some first date logistics outlined before you get started here at USDS.

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