These transcripts were captured live by a captioner. As such, there may be small errors. If you spot any, please feel free to submit a pull request with amendments.

Hi, everyone. My name is Gargi, and I'm going to be talking about being so good they can't ignore you. I kind of made the title because - it sounds douchy, but the idea is how to make your work visible.

So, the thing, the idea is that, if you do good work, then someone should take notice and reward you accordingly to your work, but that's not how it works in real life, unfortunately, and promotion is something that doesn't come easy to most people, maybe because of cultural background, or the upbringing, and it can be even painful sometimes, so what I want to do in this talk is give you a framework so, so that you have - it's less painful to brag and not undersell yourself.

So, this talk is going to be divided into three structures. The first is meritocracy and the myth of meritocracy. The second is how do you make your work visible? And the last is, once you're successful, how do you help others around you be successful? If you want to follow the slides for some reason, you have the link where you can find the slides.

So, under the first, so, meritocracy - before we get into the meritocracy, I would like to talk about what meritocracy is. So, it's this belief that everyone has an equal opportunity for success based on personal achievement and merit regard the of your background, or where you come from, and tech tend to be to be a meritocracy, but we know about roads paved with good intentions.

It's hard for people who have had some success, or have achieved something to believe that it is anything but a meritocracy, because the system has rewarded them, because if they've got to where they got to, it has to be because of their merit and not anything else? The problem with meritocracy is that the belief that it can and should be measured on an intellectual output, regardless of their identity, gender, any other distinguishing characteristics.

The assumption is that everyone has equal access to information is wrong, because we all live in our silos. If you were to live in one geographical area of the world, you might have access to more information than the other geographical area. It's even the thing is that who your network is determined, like what information you're getting. I wouldn't be here if my network didn't tell me that there is a conference here. And, it's not that.

The second part is we are all humans working with other humans, writing software that benefits - for the benefit of humans, so, another problem with the already flawed notion of meritocracy is that the worth of an individual is not measured by their humanity but by their intellectual output.

Meritocracy is based on the utilitarian principle of the work. Utilitarianism is the philosophical belief that the most moral action is the one that ... so, in the end, the end justifies the means. One of the well-known problems with adopting utility as a measure of morality is that it ignores the concept of justice, so, as long as you're maximising output, anything, any bad actions you take are justified because they contribute to the greater good, so it objectifies people reducing them to the level of tools, and most cases, it's code for whatever delivers maximum comfort and is least painful to the other people.

So, the biggest paradox of meritocracy is a ... a Professor did a study where he studied 9,000 people in an organisation where there are HR practices like a bonus for the performance, and the whole spiel is about reward ing m meritocratic ideas, and what the idea found is that the women and ethnic minorities, and non-US-based employees, received a smaller increase in compensation compared with the white man, despite having the same jobs, working the same hours, having the same manager, and, most importantly, having the same performance review score, so, the paradox of meritocracy both on the - based on the other research which shows that people who believe they are the most objective can actually exhibit the most bias, in their evaluations. And this is kind of disheartening.

I think the biggest takeaway that I have is nobody cares about your work as much as you do, and this is kind of the system we live in, and we have to figure out how to navigate this system so we can work it to our benefit. With that, we move to the second part of the talk, which is how to make your work visible.

So, the idea is that whenever - at some point, - at some point in your career, you will have to prove your value that you block here, you're good at what you do, but it can be hard to talk about your achievements for that, underselling yourself, or feeling like you're busking. And that if you carried out your job, someone should automatically recognise that the work you do unrewarded - and reward you with promotions or increased pay.

In practice, it's like often more complicated than that. There is some work which is more visible and memorable than the others, and it is frustrating to have done something that is you think is important, but you later realise you weren't rewarded for it because someone thought, someone who is making the decisions, thought that they don't understand what you were doing, or just didn't remember what you were doing.

So, the first part is building your personal brand, so you have a personal brand, regardless of whether you've consciously chosen to cultivate it or not. Your personal brand is what people are saying whenever you're not in the room. My personal brand is that I really care about open source and people sometimes make fun of it, but I'm okay with that. I can live with that.

Your personal brand is a platform for growth, so your personal brand has you realise what values you identify with, what are the things you care about? And they have others that realise if there is some test that needs to be done, maybe you care the most about it, because that's the value system you identify with. So, to ... your own personal brand, you need to be confident that you're able to achieve your goals, and take the actions to achieve those goals, and use whatever your personal values that make you unique to achieve those goals.

The other thing you could do is build an experience map for yourself. In UX design, whenever you want to get from point A to point B in an app, you go through the this experience map of getting from paint A to point B, and that's something that you can do for yourself, where you realise, oh, where you say that if you're currently, like let's say, a junior developer and you want to be a senior developer, what should the experience map for that look like? And it is a way to quickly identify like your personal brand when you're working with other people, the values that you care about.

The biggest thing that you can do to make your work visible is write a brag doc. What happens at most places is that every six months, or a year, or a quarter, you have to sit down with your manager and talk about what you did for the last X months, and then what usually happens is you go scramble up, look at all the PRs you made, think this PR was useful and maybe it's something, and the other pull request - sorry - not so useful, and maybe I shouldn't talk about that, but what happens when you do that is a lot of work that you did falls under the radar because you didn't think it was important enough.

And, a brag doc is not meant to be a self-evaluation, or a résumé, or a vision board - each of those serve their own purpose - but somewhat different. Instead, it's like it's a living list of all the achievements you've done, so one of the biggest things like you don't remember all the cool things you did.

Maybe you wrote a test that you don't think is important, but it helped figure out - helped catch an important bug later which you didn't know about, or your manager - you might have the best manager, but they certainly don't remember all the cool things you did. Writing a document and listing everything you're proud of is an important reminder that can help you during your self eval.

What is especially about writing a brag doc is that, whenever you have to update your experience map of what your experience has looked like so far, you can go, look at your brag doc, go back and update your experience map every year, six months, depending on what timescale you choose. And what can you add to your brag doc? It could be the pull request that took forever to merge. It does not matter if the pull request has two lines of code or 300 lines of code. As long as you're proud of it, you should add it to your brag doc. It could be the design document that you contributed to, or even maybe you did some discovery work to figure out that the service that your team needs to write has already been written by some other team, and maybe you can collaborate with them to use their service, and that also should be included in your brag doc. It could be a talk you gave, a lightning talk, or an internal talk that you gave at your company.

And a brag doc can help you start your own brag doc. List down your major goals for the year and share them. Share them with your manager, share them with your co-workers, and it's really nice, because then they can see that what is in their power to help you achieve and accomplish those goals. And add your code and non-code contribution to the project, but, when you add those, add metrics if you can to that, so, let's say if you're - if the code you wrote helped speed up the service by X per cent, add those numbers because you then have solid data to back up what you're feeling.

It doesn't have to be a numerical impact. Maybe the thing you wrote helped GDPR, for example. Maybe whatever you needed was important to - important for law purposes, I guess. Yes. And, collaboration and mentoring, if you're a junior engineer, you can still mentor a lot of people. If someone is new, is on your team, you can have them on board on to your team. If there's an intern on your team, you can mentor the intern, and you just don't have to be a mentor.

You can even be a connector if there is a new person on your team you can introduce them to your network, and that should also be part of your brag doc and collaboration where you discover, there are other things, maybe there's someone on another team who wants to use your service and you help them how to use your team's code. It doesn't have to be in the realm of your team. It could be helping the company. Most places allow people after a year who have been there a year to be in the interviewing pipeline, so you can work to ensure that the interview process is fairer, or, if you're in the company, you can figure out if you see that the performance review could be fairer.

And the biggest thing in my opinion is tracking what you learn, because a lot of times, you have a lot of work that you're learning, but it could be that what you're learning is not aligned to your goals.

Let's say I care a lot about systems software and I want to write more lower-level code, but what is happening is I'm learning more about benchmarking and testing, and while these are important things, it's not aligned to my goal of learning more about systems software, and this helps me track down when that is not happening, and I can go back to my manager and say in the last three months, of what I worked on is not related to any of the - and can we change that? And it could include your participation outside of work, so that could be contributing to an open source project you really care about, or a blog post that you wrote, or a talk at a meet-up event that you gave. And the most important part is don't forget the invisible work.

So, what happens a lot of time is we do a lot of fuzzy work which is hard to quantify. It could be, like, improving the code quality, or ensuring that the code review processes are good and more in depth, and maybe it's refactoring so the next person comes and adds code, it's less painful for them. This is the kind of work that is especially important to add to your brag doc because it's most likely to fall under the radar, so, when you're doing this, explain the code.

So, for example, if you were going to refactor something, state why you wanted to refactor this. And then there's the things that you refactored. It could be that you wrote a test to ensure that, when you refactored, things didn't break, or, if there were already tasks, you ensured they were still working once you refactored the code. And then you can show the visible effects that your refactoring had, and the good thing about sharing your brag doc with your co-workers is they can tell you and help you make this impact more visible. The last thing is how to help others.

So, in general, if you're someone who really cares about your work, then it's really positive to share your goals and accomplishments, and for sure the things that haven't gone well too, and, with your friend and co-workers, because it feels more like - less like you're working alone, and more like everyone's in it together, and you're helping each other get where you want.

So you can run a brag document workshop which is for the first part everyone writes their brag document, and, for the second part, you can pair up with other people and help each other brag more. This is something I do with my friends is we set up a call, bi-weekly or once a month to update our brag doc. It's especially helpful if you have - so my brag group is mostly other gender minorities, and what I see in my friends is that we don't brag enough, so we help each other brag more, and the big part is encourage each other to brag more, and, yes.

So, what I, in my opinion, what is so great about having your brag doc is that it lets you - it lets you find out now rather than later that things are not going to great, so the first time I ever did a performance review, it was four months after I my started on my first job which was weird because times aligned that way, but when I scrambled to find the PRs, et cetera, I didn't know how to put up a lot of things that I should have, and then I also realised, like I did learn a lot of things that I wanted to learn, and that whatever I was working with, it was diverged from what my goal was, so having a brag doc is a great way to immediately find out that things are not going so well, and maybe you should act on it.

The other part of being visible and making your work visible is networking. As much as I hate to say it, it's really important because you can have your personal brand, but if you're not showing up, to places, nobody knows about your personal brand, and you're not telling your own story, and getting out of your comfort zone, and networking ensures that you can create new and exciting opportunities for yourself.

So I have some networking hacks as an introvert, mostly for introverts. I hope they will help other people too. One is having a blog or a micro blog. A micro blog is, hint, hint, Twitter! Having this ensures that you can take your time and think about things and formulate your thoughts, and then engage in real dialogue with others.

This one is my favourite. It's Connectors. If you work for a big company - I work for like a 20-person start-up, so I know everyone. Like, who do I connect to? If you work for a bigger company, you can be a connector, which is every week or two weeks, get a lunch or coffee with someone. It doesn't have to be someone in engineering. It could be someone in sales and marketing, and that's a great way to learn about the bigger picture that your company's trying to solve, and like not be siloed into your tech bubble, and you can be indispensable because then you know more, like knowledge gaps in other people, because you have talked to people who work in different areas of your job.

The third is a hack which is very stressful. The good thing about it is that you've already spent so much time thinking about what you're going to talk about that, when people come up to you, people will come up to you, and, two, you can already talk about what you talked about, so, that's a stressful hack, but a hack nonetheless.

The fourth is organising a low-effort event which I used to run a book club, which was very low effort because you only have to read a book, and people will show up, and you can talk about the book, and it's a great way to meet new people, and still be talking about the book, and other things, which was nice.

The last is if you do end up at a big event, one of the hacks is talk to n people before leaving. My n is usually less than three, but I will talk to three people, three new people, and then be, like, okay, I have no more FOMO and I will be out of here! [Laughter]. One of the pitfalls - yes, this is one of my hacks. One of the pitfalls that happens with junior engineers especially is glue work. Tanya Reilly has a talk about glue work. It's in my references. But it is a essentially the non-technical aspects of your job, so like establishing a coding standard. Like you can be a junior engineer, and you could hear a lot about code reviews, and washing a lot to ensure that no pull request gets merged in without a code review, or at least two people have to agree before merging a pull request, or setting up collaboration with other teams, and a lot of these fall on your shoulders because they're part of your personal brand, and your values, and it's something that you really, really, really care about.

So, brag documents are also a way to help you track this, that you're doing too much glue work, and maybe you should talk to your manager to ensure that more glue work doesn't fall on your shoulders. So don't pigeon-hole yourself. The last part of my talk is what we owe to one another once we are successful. Success can have different definitions for different people, but I want you to figure out how to make your work visible within your organisation and help other folks around you pay it forward, and a lot of times, the competition we see is artificial competition.

Like there is much more growth and much more opportunity outside the career ladders that we see, and, if you think about those opportunities, you make more nothing less, and feel more progress. And better yet, you will find ways and opportunities to partner with people within your peers, because you no longer are competing for the same limited promotion slot.

So you should not mentor folks who is a junior engineer. It could be someone starting out. You have lessons that you learned that you can teach others. Help those around you. We're all in this together. We all need to brag more. Maybe not all. Most people certainly need to brag more! And you can run a brag doc workshop, help other people brag more, and you can set up networking events. It can be something low effort like a book club, or a conference if you want. Yes, and that's it. Thank you so much. [Applause].