Adriana geeks out with Nayana Shetty of the LEGO Group, on what it takes to be a Principal Engineer. Nayana shares her firsthand experiences of working as a Principal Engineer in two different organizations. She delves into the nuances of leadership, comparing direct and indirect approaches, and emphasizes the importance of building trust with colleagues. Finally, Nayana discusses the significance of maintaining her coding skills, even in a role where coding isn’t her primary focus, and how she keeps her hands-on abilities up-to-date.
About our guest:
Nayana Shetty is a Principal Engineer at the LEGO Group. The LEGO Group is going through a massive digital transformation and she is helping with the architecture and engineering practices especially in the Ecommerce, Marketing and Channels technology. Over the years, she has led teams building products and tools that help organizations with site reliability and getting on the devops journey. Starting her career as a Quality Engineer, she is passionate about building quality into products from the start rather than an afterthought and creating a culture of quality using DevOps practices within teams.
Find our guest on:
Find us on:
Show Links:
Transcript:
ADRIANA: Hey, y'all, welcome to Geeking Out, the podcast about all geeky aspects of software delivery, DevOps, Observability, reliability, and everything in between. I'm your host, Adriana Villela. Coming to you from Toronto, Canada. And geeking out with me today is Nyana Shetty from the LEGO Group. Welcome, Nyana.
NAYANA: Hi, Adriana. And I'm excited to be here and it's going to be interesting to see what we uncover over the next half an hour or so.
ADRIANA: Yes, absolutely. I am super stoked because I always love talking to fellow women in tech. And also you work at Lego, which...so iconic! Such an iconic product!
NAYANA: I mean, there's not been one person where I've introduced myself and said that I work for the LEGO Group and let's not put smile on them. There's not been one. I think it's the best place to work at that way.
ADRIANA: I can totally imagine. Well, before we dig into that, I've got some lightning round questions to ask you. They will be quick and painless.
NAYANA: Okay, let's try.
ADRIANA: All right, are you ready? Let's go. Okay, first question. Are you a lefty or a righty?
NAYANA: Righty.
ADRIANA: All right, do you prefer iPhone or Android?
NAYANA: iPhone any day. I don't know how Android works anymore.
ADRIANA: Fair enough. Do you prefer Mac, Linux or Windows?
NAYANA: Mac for most of my day to day work, but if it's actual tech work, Linux any day.
ADRIANA: I hear that a lot actually. Very cool, very cool. What is your favorite programming language?
NAYANA: Python.
ADRIANA: Me too.
NAYANA: I've done Python for a few years now and I don't write in Python anymore because I'm mostly in marketing and channels technology area where it's more about providing services for marketing use cases. And there's not a lot of Python there. But my love is always for Python.
ADRIANA: I feel you. Yeah. I always tell people I'm happy when I code in Python. I'm like e best language ever.
NAYANA: It's so much more easier than callbacks and Javascript. Oh my God, yes.
ADRIANA: I'm sorry to people who like Javascript. I don't get it. I'm sorry. Okay, next question. Do you prefer Dev or Ops?
NAYANA: Can I go DevOps?
ADRIANA: Yeah, that is a perfectly valid answer. A lot of people have answered that. Totally. Next question. JSON or YAML?
NAYANA: JSON.
ADRIANA: Oh, interesting! I always find it funny when people who are Python lovers say JSON because you're already forced to indent. You get bitten by the indentation bug in Python anyway, so that's very interesting. All right, I just added this one today because it came up in another recording that I did. Spaces or tabs?
NAYANA: Spaces. I think less confusing than tabs. When you have spaces and tabs, it's confusing. So just keep it simple. Just do one thing. Spaces.
ADRIANA: Yeah, I totally feel you. I'm curious after I start asking this question more regularly, like what other people are going to respond. So thank you for being my first respondent to the spaces versus tabs question. Two more questions. Do you prefer to consume content through video or text?
NAYANA: Video.
ADRIANA: Interesting.
NAYANA: I learn a lot by seeing and listening rather than just reading. So yeah, I think my preferred option is videos and second option is listening and then the third option is reading.
ADRIANA: Right. That's so interesting because I think you're like the first person in a while who said video. So one pick for the video camp. Awesome. And final question, what is your superpower?
NAYANA: What is my superpower? I think being extremely structured, that's my superpower. I can convert any problem into logical steps and say, this is what that.
ADRIANA: Is a good superpower to have. I do find like whenever I'm in a position where all the thoughts are in disarray, like just sitting down and doing a list is like, magical.
NAYANA: My role kind of calls for it a bit because I kind of tell people a principal engineer's role is to go into places where you don't know anything about the topic. You go discover, find out, and then you know, but also you get the rest of the organization know what and how to move forward with and when you're going with so much uncertainty, if you had some structure, I think it's much more easier to work through it.
ADRIANA: Yeah, that makes so much sense. That makes so much sense. And I think that is probably like having that skill set is probably the most valuable skill set for a software engineer. Right. Because we're constantly encountering these scenarios that we haven't encountered before.
NAYANA: Yeah. And I've seen so many times when engineers get, as soon as they see a problem, they start digging into it and they're like, oh, I'm going to solve this with arrays or lists. And I'm like, what are you trying to do? Step back and just come up with a plan. And it doesn't have to be like something that you set in stone. Keep it fluid, but at the same time have a plan.
ADRIANA: Yeah, it's true. It's funny, I remember when I was a kid, so my dad is like, he's a math guy, he's a software guy, and I used to come to him to ask for help with math problems. And he would always bug me. He's like, do you have a plan? That's been permanently etched in my mind now. It's like, you need a plan of attack for solving this problem. Where is it? You can't solve this problem without it.
NAYANA: Yeah, I have a story from, really from two weeks ago now where we do all of these planning, and then you put four people in a room and say, you've got ten minutes and you have to solve this puzzle. All that goes out of the window, though, you start thinking about, oh, how do I solve this problem? In the process? When this happened two weeks ago for us, we forgot that we had to collaborate with two other teams that were sitting in two other rooms. We were like, if we had just stepped back and come up with a plan, we would have won this challenge.
ADRIANA: Yeah, so true. So for all you out there, planning goes a long way. So I wanted to take a step back because as we mentioned in the outset, you work for LEGO Group. I mean, I'm super curious, what does it mean to work in technology at LEGO Group? Because we always think of, like Lego as the toy, the physical bricks that we put together. So what does that look like?
NAYANA: So there's a lot of digital transformation that's been happening over the last two years or two to three years at the LEGO Group. And this means that there's technology being introduced in all sorts of places from, like, I work in the marketing and channels technology area, which is to do with how do we sell to shoppers on Lego.com to how do we sell on Amazon and Tesco and all of those kind of places, to how do we do good marketing? And Lego has a very strong brand image. How do we sustain it and how do we build on top of it? What sort of technologies can support those kind of brand image and the shopping side of things. So that's with the marketing side of things, which is where I mostly work on. I do very little on the product side of things. But then there are parts of the organization that look at the kids experiences. We've split ourselves into shopper, partner and consumer. Shopper is someone who buys from us, mostly adults.
And then there's partners who are like Amazon and Tesco, those kind of companies who buy from us. And then there's consumer, which is actually kids and adults who actually play with our products. And the experience they have is very different to what, when you're buying a product should have. And how do you bring technology closer to them, especially with so much digitization happening and Lego bricks it's still something very physical. How do you bring technology into something so physical, I think is an interesting challenge. And then there's the whole operations and the supply chain and side of things where there's the manufacturing of start with the planning of creating the products to how you then manufacture it, and then how do you ship it and all of those things. There's a lot of investment that's gone over the last few years in digitizing a lot of these things and bringing the business processes closer and redefining some of our business processes to be more engineering focused or simplifying it so that the architecture is much more simpler. And that kind of stuff has been a massive thing over the last few years now.
And a lot of teams are...it's a new space for a lot of teams. When I joined two years ago, I was fascinated and surprised by how much you can push tools like SharePoint...and Microsoft Sharepoint and Excel and PowerPoint to run a business. Basically, I came from an organization where everything was digital. So for me this was fascinating to see that they're actually selling, planning, selling and all of those just through Excel sheets. And now, two years down the line, we see a lot of digital services which are actually solving these for our business. And yeah, I think that's where engineering and technology plays a very strong hand in how we move forward as the LEGO Group and how we evolve ourselves, I guess.
ADRIANA: Right. And so what do you think right now are some of the most challenging problems that you're working on?
NAYANA: So the area I look at in marketing is to do with personalization. And because of the strong brand we have had as the LEGO Group, we didn't have to go to the level of individual persons needs and requests to actually figure out how do we make a difference in their shopping experiences. Until recently, and now we've pivoted to be like, it's all about that experience, especially Gen Z. And the future generations are so much on the Internet that everything they need has to be personalized. And there's an expectation that if you don't know me, don't sell things to me. That's how I think the expectation is. So one of the major challenge I'm working with is how do we bring technology into personalization? How do we collect data in a much secure way. So there's the whole legal and privacy aspects of collecting personal data.
And then how do we then translate that into making sure that we use it in a consistent way across our different product teams and stuff. So one of the things that we hold quite dearly from a principles perspective, is that we follow domain-driven design thinking, which means that there's very modular, clear boundaries to our product teams and they can work independently to deliver the business outcomes in the marketing space. That's actually a not so common concept. When you look at any tools that are out in the market, they're very much like they can solve it all for you in one single product, but you don't need one product for the whole thing. You have four different product teams looking at it. So how do we break that? Like a single monolith kind of approach, which is what marketing has been in the past, to much more modular, domain-driven kind of product themes and product areas and stuff. So that's been one of the major areas that I've been working on over the last year. The other one, which has started cropping up more recently, is how do we collect or gather engineering metrics? And this comes from the fact that we've invested a lot over the last two, three years in technology.
We've grown quite a lot. How do we know it's actually bringing us the right return on investment? And what are the right indicators that show us that our engineering teams are working efficiently and stuff? And we need to do this in a way that's not poking individual teams saying, oh, you're better than them, because your, let's say deployment frequency is five and that team's deployment, that's not the level we should be going into, but what is it that we should be looking at more widely? So that's another area that we've been exploring quite heavily more recently. And I think this will be a hot topic for the next year as well.
ADRIANA: Right, right. Now, pulling back a little bit, because you mentioned you're a principal engineer, you touched upon some of the things that are within the purview of your responsibility or the expectations as a principal engineer, what would you say is kind of the one thing that stuck out for you more than anything when you moved into a principal engineer role? Because the expectations are vastly different from, say, a junior, where you're like, you're just writing some code that someone told you to write.
NAYANA: Yeah. So I moved into a principal engineer role. I was at the FT when...Financial Times...when I moved into the principal engineer role, and for me at that point, it was like, and principal engineer roles are very different across different organizations where at the FT, it was a 50/50 kind of role, where 50% of the time I spent on people management and team health and that kind of stuff. And 50% of the time is what I thought about tech strategy and the direction we want to move in and stuff. Where now at the LEGO Group, it's very much the tech strategy role. It's an individual contributor role where I'm mostly thinking about the long-term direction and the guardrails that we need to enable the teams on. And I think what surprises me and what had surprised me, and probably it's something that anyone who comes in new to this role will have to work with, is how much hands-on experience do you want to have in this role? And I think it varies. And in the LEGO Group, we've got around 15-ish principal engineers, and each one of us have a different version of principal engineering that we do. So it's not the same role that...as a role or as a level...it's the same level that all of us have.
The roles that we cater to within the organization is subtly different based on what our strengths are. I think where some people are very much into, oh, I'm an expert in, let's say, for example, a technology like SAP. I'm an expert in SAP. So I'm going to be spreading across wherever SAP expertise are needed. And I'm going to do some hands-on supporting or even the strategic thinking around SAP. Where I'm more of a solution architect kind of principal engineer, where I do very little hands on. I do hands on just so that I remember and stay true to the title of engineer. But my role itself doesn't want me or it doesn't need me to actually do a lot of hands on coding and that kind of stuff. So I think that's something that surprised me thinking, oh, I thought principal engineer is going to be like the smartest engineer in the room, which is not true.
I'm not that I kind of see myself as a person who can glue the right people together so we reach that best outcome possible for the organization.
ADRIANA: Right. And that is such an important skill. I mean, it's not necessarily about having the answers, it's knowing the people who have the answers and putting them together.
NAYANA: Yeah. So I kind of see myself doing the glue. I say principal engineers are the glue across the organization. Breaking some of those silos and barriers across organizational constraints and stuff. That's what a principal engineer should be looking at. And then the other thing is we're also part of leadership team. So I'm part of the marketing and channels technology leadership team. So what sort of engineering culture do I want to help the organization get behind? And that kind of stuff and being, like, a positive influence on it.
I mean, given my role, I work very closely with engineers on a day-to-day basis. So I hear a lot, like, just on the ground kind of, I wish they had this. I wish we had done that. So just hearing those things, and when there's enough of those wishes that you hear, you're like, okay, can we positively influence it? And that's, I think, something that a principal engineer kind of plays a key role in bringing that people's voice into spaces where there's just leadership...leaders in a room and stuff. And how do you then create and change because of what you know and what you're surrounded by and stuff?
ADRIANA: Yeah, that makes a lot of sense. And it's interesting because I think having your ear to the ground, knowing what's around you, I think it helps. As you said, you're bringing the challenges and the needs and wants of the other engineers to the forefront. But also, I guess it helps you with that glue aspect of your job as well, because then you're in tune with, like, who knows what.
NAYANA: Yeah, exactly. And also it adds to they trust me enough because I help them somehow kind of thing. How do you build trust, especially? And this was something which I think was something that I had to learn when I moved to the LEGO Group, because at the Financial Times, I moved through different roles. And I started as a QA Lead and then moved on to Tech Leading and then slowly into being a Principal Engineer, where people have seen how I contribute and what my opinions are about stuff, so they already know about me, and they trust me enough based on what I've delivered. Where when I started here, it was completely different. Where some people trust. I mean, there's an inherent trust that you get because you're in a role, but other than that, there's not trust that they believe you. You've done that thing. That's why I trust you.
So how do you generate that quick trust among your peers and people who you work with is something that I had to learn as part of joining the LEGO Group. And, I mean, there's probably something that the LEGO Group is really good at, which is that open culture of, you can just go and talk to people, understand where they're coming from, and then it's one of those places where I felt it's easy to debate, but then at the end conclude somewhere.
ADRIANA: Cool, because I think you touched on something really interesting, because I think one of the hardest parts about joining a new organization is having to build up that reputation, that trust, so that people see that you're worth the paycheck you're earning. And that can be really scary, right? Because you've got that ramp up time where you got to figure out the landscape, but then at the same time you have to have some level of productivity so that people are like, okay, I know I can go to her. I trust her.
NAYANA: Yeah, I spoke about this in a conference recently as well at the LeadDev in London, where I talked about these different sizes of problems as a principal engineer that you should be thinking of. So there's the whole, an analogy that I learned from my previous manager was the rock, pebbles and the sand, where if you fill your jar with sand first, then you have no space for the pebbles and the rock. So when you start in a new organization, the first thing worth doing is understanding what those sand are, what those rocks are, what the pebbles are that you can be getting yourself involved in, but being very conscious about what you can pick up. Because if you end up picking all of the sand, then you're doing all of those little changes, but nothing, it doesn't justify the salary you get. So how do you then rebalance to make sure there's enough rocks that you work on and pebbles and stuff. Something that you consciously think about.
ADRIANA: That's a really great analogy. It's the first time I've heard that, but that's really good. The other thing that you touched upon that I want to dig a little bit deeper into, which I thought was something that I think in a lot of tech circles, there's this expectation that if you move into a management role that is equivalent to a leadership role, and that management is like a natural promotion cycle for whatever. I definitely have that impression. Like, when I started my career, I'm like, oh, yeah, I need to be a manager. I can't be a developer my whole life. No. But the thing that I thought that was really cool about what you said is that even in your position as a principal engineer, as an individual contributor, you're not managing people. But you have a very prominent leadership position.
And I think that's such an important thing to underscore because I think a lot of people conflate like, oh, the only way to be a leader is by having a management position.
NAYANA: Yeah. Doing this role now for two years, I think I found that this is indirect leadership, where you don't actually manage people, but you still have an influence on what happens within an organization. And when you're having that indirect leadership, it's all about how you bring along people on the journey and how do they, for me, when I'm working on a tech strategy or any of those things, it's the day when I hear other people tell that this is the tech strategy that we've got within our org. That is the day I feel like I've actually done my job because that's my role where I've influenced people enough that they have bought into it, that they call it out as the thing that needs to happen and stuff. So it's very different to like, if I was managing people, I could say, you report to me, and if you didn't do this, then we will have to go through all of the people management side of things, which I have none of those to do. So you do get the best parts of management, I think, being an individual contributor and influencing the rest of the where you're bringing people along. But at the same time, I do work very closely with the senior directors who actually have the management responsibility of these orgs where if I see things moving slowly, I kind of lean on them saying, can you help nudge this happen or can you help make this happen within the organization? And they surely have the direct influence, which I don't, but you have to use that levers at times, but at least 80% of the time you can get away without that.
ADRIANA: Yeah. And I think that's an extremely important and useful skill to have no matter what right to be able to exert influence. So for you, what's your strategy in terms of exerting influence? How do you make it work? Because I mean, it's so difficult, right? Especially when you're dealing with all kinds of people, people who are like, oh, this is the best idea ever. And then there's the, no, I don't care, I don't like your idea. Not gonna do it.
NAYANA: It happens. And I think this is where it's the carrot and the stick kind of approach where you show the carrots. And then there are times when a lot of the work that I do is talking about why it's important to do certain things in a certain way. Or if you're saying...recently I was working on what are guardrails around PII data handling is and getting the right people involved. So it was not just engineers opinions, but getting people from legal and privacy office involved in that decision making from the start. So we're not bringing them later on. But when we thought about, this is an idea that we should do something about, bring people on early so they feel like they have contributed into it and they have a stake in it, which sometimes can be hard given everyone's got busy lives and there's a lot of people working on product teams are thinking about, oh, this is my OKR that I have to deliver to and all of those kind of things.
So taking away from that is what a lot of principal engineers will have to do where we say, oh, that is important. But in the next quarter, if we did this, this will make your life easy, like just showing that futuristic view of what will benefit them. And also in a lot of times it's about coaching and mentoring people through. If you contributed through this process, then you can get into...as you develop...engineering management is not just the option. You can also think about IC roles like we have as principal engineers and stuff. And when it all fails, that's when it's probably just getting back to the people leaders...of these people who...troublemakers. Are they troublemakers? I don't know. And then getting them to help a bit more.
And this is where I kind of see that relationship between the senior directors and principal engineers being really close, where we work quite like if we have to influence without authority, we need their support when that authority is needed.
ADRIANA: Yeah, absolutely. Sometimes it's one of those things where you can't and probably shouldn't handle all the issues yourself anyway. So it's good to know who you can call on to ask for help, to ask for the little nudge to get people around to your corner. I think that's also like an aspect of influence, right? Is having a circle of people who trust that you know what you're doing and will follow you because they like your leadership and that they can also exert their influence to influence others because they believe in what you do, which is super cool.
NAYANA: I've also used other principal engineers across the organization as a support network because the kinds of problems I work with are not within my own product area scope. It can also span across multiple product areas, or we call it clusters within the LEGO Group. So when there are things spanning across clusters, I kind of lean on the other principal engineers and we work together so that it's more of like, it's not her opinion, it's the company's opinion kind of comes in, which also is quite handy to have in places when you have to influence people where they don't come within your part of the organization. They have no clue where you sit in the organization. They've not worked with you, so they don't trust you enough. So in those kind of it's worth calling in on your support network outside of your immediate organization and stuff.
ADRIANA: Yeah, and it makes sense because, again, it helps to build that trust because it doesn't seem then like, oh, you have an agenda. No, there are other people who see this in the same way. So, hey, maybe there's something to it.
NAYANA: And like, I think a good thing that the LEGO Group...that I've seen at the LEGO Group is that we have some core principles that have been outlined at the start of this whole digital transformation. Like I mentioned about the domain-driven principles that we follow. Or it could be that API-first kind of approach or like the Cloud-first kind of. I think the core principles that we've laid out, forms like that foundation that we can lean on quite heavily when it comes to, "Okay, I'm lost here. What do I fall back on?" I can fall back on those core principles, and they're not special for the LEGO Group. So you can read about it, how other companies are doing to actually learn from it. And then it's a good safety net to have, especially when you're starting new in an organization, having that kind of a foundation layer that you can fall back on and stuff is quite handy as well.
And it's also like when they're stuck in those scenarios where you have an argument, you can then go back to the first principles and talk about, okay, what does theory say? And then work forward from there kind of thing.
ADRIANA: Yeah. Makes a lot of sense. Now, going back to something that you mentioned earlier, which is you mentioned that you don't get to do a whole lot of coding as part of your role, but you still like to stay sharp. So what do you do to stay sharp with your coding skills? Kind of your go to thing.
NAYANA: Yeah. I think more lately what I've done is within the principal engineers group, we have a working group where we do hands-on work. We've set up a couple of hours every week where we just do some hands-on work. So the most recent one was we were all learning gen AI, and learning didn't mean just go read stuff, but actually build something. And we did more like a hackathon kind of style thing. But we're not spending a day. It's just a couple of hours each week. And I think that's how I have...for me, that's the easiest way to keep on top and also feel like I'm staying up-to-date and also avoiding that impostor syndrome to kick in as well. You're like, oh, am I current? Am I what...trustworthy enough? So I kind of use those hands-on sessions that we've got internally where spend a couple of hours each week just coding anything. And currently, given the gen AI, seems to be like the current hot topic. So that's one area and the other area is around...I haven't worked much in the data space, and a lot of teams that I'm currently working with work with data a lot. So this is where some of this Python skills does come in quite handy, which is just trying how to crunch data with Python and that kind of stuff. So it's always related to what I'm working on, but with a slight slant on nothing related to what the LEGO Group needs. Just what I need to keep myself updated, kind of.
ADRIANA: Yeah, that is such a great way to stay current. It's funny because I was telling someone the other day that my last role, I was a manager, but I don't feel whole unless I'm coding. So even in that role, I would carve out some time in my week to make sure that I was learning new things, because otherwise I legitimately got depressed if I wasn't creating something. And I think if you're a software engineer, it's just kind of part of your blood. So to be able to find any excuse to learn something cool and to get that hands-on experience and to learn something that's actually interesting so that it'll stick in your mind more, right?
NAYANA: Yeah. And I think another thing that I remembered was, when I attend conferences, if there's an interesting piece of technology I would have seen, that's another place where I just go and play around with that for a few days. And conferences are my trigger to play around with a few technologies as well. So I kind of make sure I attend a few just so that that becomes the reason why I'm trying out stuff. At the end of the day, it's how we manage our time. And we are at a stage, we are our own time...leaders of our own time, right? So we have to see how we manage it. And carving out time is so important, especially as you grow in your career, you can go into that thing of, I'm busy, so I can't learn. It's a very easy, vicious cycle to go into, but staying aware of it, I think, is quite good.
ADRIANA: Yeah. Like you said, carving out the time is super important. And not using, as you just said, being busy as an excuse. Because I remember an instance when I was doing the management role where I was getting really frustrated because we had these no meeting Wednesdays that was like my day to play around with stuff, right? But then I kept booking meetings on my no meeting Wednesdays, so I had nobody to blame for myself. So until I took control of my calendar and started saying no, because people would book meetings on Wednesdays, and I kept saying yes. So I'm like, "NO!"
NAYANA: It's very easy to do it. And I think I had a colleague at the Financial Times who she had, like, a tally chart that she used to maintain for the month to just see how many days of just coding she's done. And it was so interesting to see how you can put some data behind this and it's not too hard to do it. If I wrote some code or if I read some code today, then I just put a...like, it's a tiny chart. You just put a line on a book, right? And she kind of said that that was really motivating her to keep true to coding always. Or, like, doing something hands-on doesn't have to be. Exactly.
ADRIANA: Ultimately. I mean, what we do is a very creative line of work. And I think as creators, we like to create and it makes us whole.
NAYANA: Yeah, that's so true.
ADRIANA: Awesome. Well, we are coming up on time, but before we part ways, are there any parting words of wisdom that you would like to share with our audience today?
NAYANA: I'm trying to prioritize in my head which one's the better one. I think I'll probably go to one which we are in a macroeconomic situation where everything's getting tight and there are companies that are struggling. And for me, this is a time when engineering efficiency and thinking about how we build more sustainable products becomes quite important. So I think...thinking about engineering efficiencies and trying to not in a sense of I'm going to measure the four DORA metrics or...not that way, but more of what can make my software more sustainable, what can I do to make it more maintainable so that I don't have to put energy once I've built those products and stuff is probably the key thing that it's top of my mind at the moment. And I think it will be more. It's going to take a larger space next year when we don't know where the world is going and stuff.
ADRIANA: Yeah. So very true. I think those are really great words of wisdom. Well, thank you so much, Nayana, for geeking out with me today, y'all don't forget to subscribe and be sure to check the show notes for additional resources and to connect with us and our guests on social media until next time.
NAYANA: Peace out and geek out.
ADRIANA: Geeking Out is hosted and produced by me, Adriana Villela. I also compose and perform the theme music on my trusty clarinet. Geeking Out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the socials by going to bento.me/geekingout.
ADRIANA: Hey, y'all, welcome to Geeking Out, the podcast about all geeky aspects of software delivery, DevOps, Observability, reliability, and everything in between. I'm your host, Adriana Villela. Coming to you from Toronto, Canada. And geeking out with me today is Nyana Shetty from the LEGO Group. Welcome, Nyana.
NAYANA: Hi, Adriana. And I'm excited to be here and it's going to be interesting to see what we uncover over the next half an hour or so.
ADRIANA: Yes, absolutely. I am super stoked because I always love talking to fellow women in tech. And also you work at Lego, which...so iconic! Such an iconic product!
NAYANA: I mean, there's not been one person where I've introduced myself and said that I work for the LEGO Group and let's not put smile on them. There's not been one. I think it's the best place to work at that way.
ADRIANA: I can totally imagine. Well, before we dig into that, I've got some lightning round questions to ask you. They will be quick and painless.
NAYANA: Okay, let's try.
ADRIANA: All right, are you ready? Let's go. Okay, first question. Are you a lefty or a righty?
NAYANA: Righty.
ADRIANA: All right, do you prefer iPhone or Android?
NAYANA: iPhone any day. I don't know how Android works anymore.
ADRIANA: Fair enough. Do you prefer Mac, Linux or Windows?
NAYANA: Mac for most of my day to day work, but if it's actual tech work, Linux any day.
ADRIANA: I hear that a lot actually. Very cool, very cool. What is your favorite programming language?
NAYANA: Python.
ADRIANA: Me too.
NAYANA: I've done Python for a few years now and I don't write in Python anymore because I'm mostly in marketing and channels technology area where it's more about providing services for marketing use cases. And there's not a lot of Python there. But my love is always for Python.
ADRIANA: I feel you. Yeah. I always tell people I'm happy when I code in Python. I'm like e best language ever.
NAYANA: It's so much more easier than callbacks and Javascript. Oh my God, yes.
ADRIANA: I'm sorry to people who like Javascript. I don't get it. I'm sorry. Okay, next question. Do you prefer Dev or Ops?
NAYANA: Can I go DevOps?
ADRIANA: Yeah, that is a perfectly valid answer. A lot of people have answered that. Totally. Next question. JSON or YAML?
NAYANA: JSON.
ADRIANA: Oh, interesting! I always find it funny when people who are Python lovers say JSON because you're already forced to indent. You get bitten by the indentation bug in Python anyway, so that's very interesting. All right, I just added this one today because it came up in another recording that I did. Spaces or tabs?
NAYANA: Spaces. I think less confusing than tabs. When you have spaces and tabs, it's confusing. So just keep it simple. Just do one thing. Spaces.
ADRIANA: Yeah, I totally feel you. I'm curious after I start asking this question more regularly, like what other people are going to respond. So thank you for being my first respondent to the spaces versus tabs question. Two more questions. Do you prefer to consume content through video or text?
NAYANA: Video.
ADRIANA: Interesting.
NAYANA: I learn a lot by seeing and listening rather than just reading. So yeah, I think my preferred option is videos and second option is listening and then the third option is reading.
ADRIANA: Right. That's so interesting because I think you're like the first person in a while who said video. So one pick for the video camp. Awesome. And final question, what is your superpower?
NAYANA: What is my superpower? I think being extremely structured, that's my superpower. I can convert any problem into logical steps and say, this is what that.
ADRIANA: Is a good superpower to have. I do find like whenever I'm in a position where all the thoughts are in disarray, like just sitting down and doing a list is like, magical.
NAYANA: My role kind of calls for it a bit because I kind of tell people a principal engineer's role is to go into places where you don't know anything about the topic. You go discover, find out, and then you know, but also you get the rest of the organization know what and how to move forward with and when you're going with so much uncertainty, if you had some structure, I think it's much more easier to work through it.
ADRIANA: Yeah, that makes so much sense. That makes so much sense. And I think that is probably like having that skill set is probably the most valuable skill set for a software engineer. Right. Because we're constantly encountering these scenarios that we haven't encountered before.
NAYANA: Yeah. And I've seen so many times when engineers get, as soon as they see a problem, they start digging into it and they're like, oh, I'm going to solve this with arrays or lists. And I'm like, what are you trying to do? Step back and just come up with a plan. And it doesn't have to be like something that you set in stone. Keep it fluid, but at the same time have a plan.
ADRIANA: Yeah, it's true. It's funny, I remember when I was a kid, so my dad is like, he's a math guy, he's a software guy, and I used to come to him to ask for help with math problems. And he would always bug me. He's like, do you have a plan? That's been permanently etched in my mind now. It's like, you need a plan of attack for solving this problem. Where is it? You can't solve this problem without it.
NAYANA: Yeah, I have a story from, really from two weeks ago now where we do all of these planning, and then you put four people in a room and say, you've got ten minutes and you have to solve this puzzle. All that goes out of the window, though, you start thinking about, oh, how do I solve this problem? In the process? When this happened two weeks ago for us, we forgot that we had to collaborate with two other teams that were sitting in two other rooms. We were like, if we had just stepped back and come up with a plan, we would have won this challenge.
ADRIANA: Yeah, so true. So for all you out there, planning goes a long way. So I wanted to take a step back because as we mentioned in the outset, you work for LEGO Group. I mean, I'm super curious, what does it mean to work in technology at LEGO Group? Because we always think of, like Lego as the toy, the physical bricks that we put together. So what does that look like?
NAYANA: So there's a lot of digital transformation that's been happening over the last two years or two to three years at the LEGO Group. And this means that there's technology being introduced in all sorts of places from, like, I work in the marketing and channels technology area, which is to do with how do we sell to shoppers on Lego.com to how do we sell on Amazon and Tesco and all of those kind of places, to how do we do good marketing? And Lego has a very strong brand image. How do we sustain it and how do we build on top of it? What sort of technologies can support those kind of brand image and the shopping side of things. So that's with the marketing side of things, which is where I mostly work on. I do very little on the product side of things. But then there are parts of the organization that look at the kids experiences. We've split ourselves into shopper, partner and consumer. Shopper is someone who buys from us, mostly adults.
And then there's partners who are like Amazon and Tesco, those kind of companies who buy from us. And then there's consumer, which is actually kids and adults who actually play with our products. And the experience they have is very different to what, when you're buying a product should have. And how do you bring technology closer to them, especially with so much digitization happening and Lego bricks it's still something very physical. How do you bring technology into something so physical, I think is an interesting challenge. And then there's the whole operations and the supply chain and side of things where there's the manufacturing of start with the planning of creating the products to how you then manufacture it, and then how do you ship it and all of those things. There's a lot of investment that's gone over the last few years in digitizing a lot of these things and bringing the business processes closer and redefining some of our business processes to be more engineering focused or simplifying it so that the architecture is much more simpler. And that kind of stuff has been a massive thing over the last few years now.
And a lot of teams are...it's a new space for a lot of teams. When I joined two years ago, I was fascinated and surprised by how much you can push tools like SharePoint...and Microsoft Sharepoint and Excel and PowerPoint to run a business. Basically, I came from an organization where everything was digital. So for me this was fascinating to see that they're actually selling, planning, selling and all of those just through Excel sheets. And now, two years down the line, we see a lot of digital services which are actually solving these for our business. And yeah, I think that's where engineering and technology plays a very strong hand in how we move forward as the LEGO Group and how we evolve ourselves, I guess.
ADRIANA: Right. And so what do you think right now are some of the most challenging problems that you're working on?
NAYANA: So the area I look at in marketing is to do with personalization. And because of the strong brand we have had as the LEGO Group, we didn't have to go to the level of individual persons needs and requests to actually figure out how do we make a difference in their shopping experiences. Until recently, and now we've pivoted to be like, it's all about that experience, especially Gen Z. And the future generations are so much on the Internet that everything they need has to be personalized. And there's an expectation that if you don't know me, don't sell things to me. That's how I think the expectation is. So one of the major challenge I'm working with is how do we bring technology into personalization? How do we collect data in a much secure way. So there's the whole legal and privacy aspects of collecting personal data.
And then how do we then translate that into making sure that we use it in a consistent way across our different product teams and stuff. So one of the things that we hold quite dearly from a principles perspective, is that we follow domain-driven design thinking, which means that there's very modular, clear boundaries to our product teams and they can work independently to deliver the business outcomes in the marketing space. That's actually a not so common concept. When you look at any tools that are out in the market, they're very much like they can solve it all for you in one single product, but you don't need one product for the whole thing. You have four different product teams looking at it. So how do we break that? Like a single monolith kind of approach, which is what marketing has been in the past, to much more modular, domain-driven kind of product themes and product areas and stuff. So that's been one of the major areas that I've been working on over the last year. The other one, which has started cropping up more recently, is how do we collect or gather engineering metrics? And this comes from the fact that we've invested a lot over the last two, three years in technology.
We've grown quite a lot. How do we know it's actually bringing us the right return on investment? And what are the right indicators that show us that our engineering teams are working efficiently and stuff? And we need to do this in a way that's not poking individual teams saying, oh, you're better than them, because your, let's say deployment frequency is five and that team's deployment, that's not the level we should be going into, but what is it that we should be looking at more widely? So that's another area that we've been exploring quite heavily more recently. And I think this will be a hot topic for the next year as well.
ADRIANA: Right, right. Now, pulling back a little bit, because you mentioned you're a principal engineer, you touched upon some of the things that are within the purview of your responsibility or the expectations as a principal engineer, what would you say is kind of the one thing that stuck out for you more than anything when you moved into a principal engineer role? Because the expectations are vastly different from, say, a junior, where you're like, you're just writing some code that someone told you to write.
NAYANA: Yeah. So I moved into a principal engineer role. I was at the FT when...Financial Times...when I moved into the principal engineer role, and for me at that point, it was like, and principal engineer roles are very different across different organizations where at the FT, it was a 50/50 kind of role, where 50% of the time I spent on people management and team health and that kind of stuff. And 50% of the time is what I thought about tech strategy and the direction we want to move in and stuff. Where now at the LEGO Group, it's very much the tech strategy role. It's an individual contributor role where I'm mostly thinking about the long-term direction and the guardrails that we need to enable the teams on. And I think what surprises me and what had surprised me, and probably it's something that anyone who comes in new to this role will have to work with, is how much hands-on experience do you want to have in this role? And I think it varies. And in the LEGO Group, we've got around 15-ish principal engineers, and each one of us have a different version of principal engineering that we do. So it's not the same role that...as a role or as a level...it's the same level that all of us have.
The roles that we cater to within the organization is subtly different based on what our strengths are. I think where some people are very much into, oh, I'm an expert in, let's say, for example, a technology like SAP. I'm an expert in SAP. So I'm going to be spreading across wherever SAP expertise are needed. And I'm going to do some hands-on supporting or even the strategic thinking around SAP. Where I'm more of a solution architect kind of principal engineer, where I do very little hands on. I do hands on just so that I remember and stay true to the title of engineer. But my role itself doesn't want me or it doesn't need me to actually do a lot of hands on coding and that kind of stuff. So I think that's something that surprised me thinking, oh, I thought principal engineer is going to be like the smartest engineer in the room, which is not true.
I'm not that I kind of see myself as a person who can glue the right people together so we reach that best outcome possible for the organization.
ADRIANA: Right. And that is such an important skill. I mean, it's not necessarily about having the answers, it's knowing the people who have the answers and putting them together.
NAYANA: Yeah. So I kind of see myself doing the glue. I say principal engineers are the glue across the organization. Breaking some of those silos and barriers across organizational constraints and stuff. That's what a principal engineer should be looking at. And then the other thing is we're also part of leadership team. So I'm part of the marketing and channels technology leadership team. So what sort of engineering culture do I want to help the organization get behind? And that kind of stuff and being, like, a positive influence on it.
I mean, given my role, I work very closely with engineers on a day-to-day basis. So I hear a lot, like, just on the ground kind of, I wish they had this. I wish we had done that. So just hearing those things, and when there's enough of those wishes that you hear, you're like, okay, can we positively influence it? And that's, I think, something that a principal engineer kind of plays a key role in bringing that people's voice into spaces where there's just leadership...leaders in a room and stuff. And how do you then create and change because of what you know and what you're surrounded by and stuff?
ADRIANA: Yeah, that makes a lot of sense. And it's interesting because I think having your ear to the ground, knowing what's around you, I think it helps. As you said, you're bringing the challenges and the needs and wants of the other engineers to the forefront. But also, I guess it helps you with that glue aspect of your job as well, because then you're in tune with, like, who knows what.
NAYANA: Yeah, exactly. And also it adds to they trust me enough because I help them somehow kind of thing. How do you build trust, especially? And this was something which I think was something that I had to learn when I moved to the LEGO Group, because at the Financial Times, I moved through different roles. And I started as a QA Lead and then moved on to Tech Leading and then slowly into being a Principal Engineer, where people have seen how I contribute and what my opinions are about stuff, so they already know about me, and they trust me enough based on what I've delivered. Where when I started here, it was completely different. Where some people trust. I mean, there's an inherent trust that you get because you're in a role, but other than that, there's not trust that they believe you. You've done that thing. That's why I trust you.
So how do you generate that quick trust among your peers and people who you work with is something that I had to learn as part of joining the LEGO Group. And, I mean, there's probably something that the LEGO Group is really good at, which is that open culture of, you can just go and talk to people, understand where they're coming from, and then it's one of those places where I felt it's easy to debate, but then at the end conclude somewhere.
ADRIANA: Cool, because I think you touched on something really interesting, because I think one of the hardest parts about joining a new organization is having to build up that reputation, that trust, so that people see that you're worth the paycheck you're earning. And that can be really scary, right? Because you've got that ramp up time where you got to figure out the landscape, but then at the same time you have to have some level of productivity so that people are like, okay, I know I can go to her. I trust her.
NAYANA: Yeah, I spoke about this in a conference recently as well at the LeadDev in London, where I talked about these different sizes of problems as a principal engineer that you should be thinking of. So there's the whole, an analogy that I learned from my previous manager was the rock, pebbles and the sand, where if you fill your jar with sand first, then you have no space for the pebbles and the rock. So when you start in a new organization, the first thing worth doing is understanding what those sand are, what those rocks are, what the pebbles are that you can be getting yourself involved in, but being very conscious about what you can pick up. Because if you end up picking all of the sand, then you're doing all of those little changes, but nothing, it doesn't justify the salary you get. So how do you then rebalance to make sure there's enough rocks that you work on and pebbles and stuff. Something that you consciously think about.
ADRIANA: That's a really great analogy. It's the first time I've heard that, but that's really good. The other thing that you touched upon that I want to dig a little bit deeper into, which I thought was something that I think in a lot of tech circles, there's this expectation that if you move into a management role that is equivalent to a leadership role, and that management is like a natural promotion cycle for whatever. I definitely have that impression. Like, when I started my career, I'm like, oh, yeah, I need to be a manager. I can't be a developer my whole life. No. But the thing that I thought that was really cool about what you said is that even in your position as a principal engineer, as an individual contributor, you're not managing people. But you have a very prominent leadership position.
And I think that's such an important thing to underscore because I think a lot of people conflate like, oh, the only way to be a leader is by having a management position.
NAYANA: Yeah. Doing this role now for two years, I think I found that this is indirect leadership, where you don't actually manage people, but you still have an influence on what happens within an organization. And when you're having that indirect leadership, it's all about how you bring along people on the journey and how do they, for me, when I'm working on a tech strategy or any of those things, it's the day when I hear other people tell that this is the tech strategy that we've got within our org. That is the day I feel like I've actually done my job because that's my role where I've influenced people enough that they have bought into it, that they call it out as the thing that needs to happen and stuff. So it's very different to like, if I was managing people, I could say, you report to me, and if you didn't do this, then we will have to go through all of the people management side of things, which I have none of those to do. So you do get the best parts of management, I think, being an individual contributor and influencing the rest of the where you're bringing people along. But at the same time, I do work very closely with the senior directors who actually have the management responsibility of these orgs where if I see things moving slowly, I kind of lean on them saying, can you help nudge this happen or can you help make this happen within the organization? And they surely have the direct influence, which I don't, but you have to use that levers at times, but at least 80% of the time you can get away without that.
ADRIANA: Yeah. And I think that's an extremely important and useful skill to have no matter what right to be able to exert influence. So for you, what's your strategy in terms of exerting influence? How do you make it work? Because I mean, it's so difficult, right? Especially when you're dealing with all kinds of people, people who are like, oh, this is the best idea ever. And then there's the, no, I don't care, I don't like your idea. Not gonna do it.
NAYANA: It happens. And I think this is where it's the carrot and the stick kind of approach where you show the carrots. And then there are times when a lot of the work that I do is talking about why it's important to do certain things in a certain way. Or if you're saying...recently I was working on what are guardrails around PII data handling is and getting the right people involved. So it was not just engineers opinions, but getting people from legal and privacy office involved in that decision making from the start. So we're not bringing them later on. But when we thought about, this is an idea that we should do something about, bring people on early so they feel like they have contributed into it and they have a stake in it, which sometimes can be hard given everyone's got busy lives and there's a lot of people working on product teams are thinking about, oh, this is my OKR that I have to deliver to and all of those kind of things.
So taking away from that is what a lot of principal engineers will have to do where we say, oh, that is important. But in the next quarter, if we did this, this will make your life easy, like just showing that futuristic view of what will benefit them. And also in a lot of times it's about coaching and mentoring people through. If you contributed through this process, then you can get into...as you develop...engineering management is not just the option. You can also think about IC roles like we have as principal engineers and stuff. And when it all fails, that's when it's probably just getting back to the people leaders...of these people who...troublemakers. Are they troublemakers? I don't know. And then getting them to help a bit more.
And this is where I kind of see that relationship between the senior directors and principal engineers being really close, where we work quite like if we have to influence without authority, we need their support when that authority is needed.
ADRIANA: Yeah, absolutely. Sometimes it's one of those things where you can't and probably shouldn't handle all the issues yourself anyway. So it's good to know who you can call on to ask for help, to ask for the little nudge to get people around to your corner. I think that's also like an aspect of influence, right? Is having a circle of people who trust that you know what you're doing and will follow you because they like your leadership and that they can also exert their influence to influence others because they believe in what you do, which is super cool.
NAYANA: I've also used other principal engineers across the organization as a support network because the kinds of problems I work with are not within my own product area scope. It can also span across multiple product areas, or we call it clusters within the LEGO Group. So when there are things spanning across clusters, I kind of lean on the other principal engineers and we work together so that it's more of like, it's not her opinion, it's the company's opinion kind of comes in, which also is quite handy to have in places when you have to influence people where they don't come within your part of the organization. They have no clue where you sit in the organization. They've not worked with you, so they don't trust you enough. So in those kind of it's worth calling in on your support network outside of your immediate organization and stuff.
ADRIANA: Yeah, and it makes sense because, again, it helps to build that trust because it doesn't seem then like, oh, you have an agenda. No, there are other people who see this in the same way. So, hey, maybe there's something to it.
NAYANA: And like, I think a good thing that the LEGO Group...that I've seen at the LEGO Group is that we have some core principles that have been outlined at the start of this whole digital transformation. Like I mentioned about the domain-driven principles that we follow. Or it could be that API-first kind of approach or like the Cloud-first kind of. I think the core principles that we've laid out, forms like that foundation that we can lean on quite heavily when it comes to, "Okay, I'm lost here. What do I fall back on?" I can fall back on those core principles, and they're not special for the LEGO Group. So you can read about it, how other companies are doing to actually learn from it. And then it's a good safety net to have, especially when you're starting new in an organization, having that kind of a foundation layer that you can fall back on and stuff is quite handy as well.
And it's also like when they're stuck in those scenarios where you have an argument, you can then go back to the first principles and talk about, okay, what does theory say? And then work forward from there kind of thing.
ADRIANA: Yeah. Makes a lot of sense. Now, going back to something that you mentioned earlier, which is you mentioned that you don't get to do a whole lot of coding as part of your role, but you still like to stay sharp. So what do you do to stay sharp with your coding skills? Kind of your go to thing.
NAYANA: Yeah. I think more lately what I've done is within the principal engineers group, we have a working group where we do hands-on work. We've set up a couple of hours every week where we just do some hands-on work. So the most recent one was we were all learning gen AI, and learning didn't mean just go read stuff, but actually build something. And we did more like a hackathon kind of style thing. But we're not spending a day. It's just a couple of hours each week. And I think that's how I have...for me, that's the easiest way to keep on top and also feel like I'm staying up-to-date and also avoiding that impostor syndrome to kick in as well. You're like, oh, am I current? Am I what...trustworthy enough? So I kind of use those hands-on sessions that we've got internally where spend a couple of hours each week just coding anything. And currently, given the gen AI, seems to be like the current hot topic. So that's one area and the other area is around...I haven't worked much in the data space, and a lot of teams that I'm currently working with work with data a lot. So this is where some of this Python skills does come in quite handy, which is just trying how to crunch data with Python and that kind of stuff. So it's always related to what I'm working on, but with a slight slant on nothing related to what the LEGO Group needs. Just what I need to keep myself updated, kind of.
ADRIANA: Yeah, that is such a great way to stay current. It's funny because I was telling someone the other day that my last role, I was a manager, but I don't feel whole unless I'm coding. So even in that role, I would carve out some time in my week to make sure that I was learning new things, because otherwise I legitimately got depressed if I wasn't creating something. And I think if you're a software engineer, it's just kind of part of your blood. So to be able to find any excuse to learn something cool and to get that hands-on experience and to learn something that's actually interesting so that it'll stick in your mind more, right?
NAYANA: Yeah. And I think another thing that I remembered was, when I attend conferences, if there's an interesting piece of technology I would have seen, that's another place where I just go and play around with that for a few days. And conferences are my trigger to play around with a few technologies as well. So I kind of make sure I attend a few just so that that becomes the reason why I'm trying out stuff. At the end of the day, it's how we manage our time. And we are at a stage, we are our own time...leaders of our own time, right? So we have to see how we manage it. And carving out time is so important, especially as you grow in your career, you can go into that thing of, I'm busy, so I can't learn. It's a very easy, vicious cycle to go into, but staying aware of it, I think, is quite good.
ADRIANA: Yeah. Like you said, carving out the time is super important. And not using, as you just said, being busy as an excuse. Because I remember an instance when I was doing the management role where I was getting really frustrated because we had these no meeting Wednesdays that was like my day to play around with stuff, right? But then I kept booking meetings on my no meeting Wednesdays, so I had nobody to blame for myself. So until I took control of my calendar and started saying no, because people would book meetings on Wednesdays, and I kept saying yes. So I'm like, "NO!"
NAYANA: It's very easy to do it. And I think I had a colleague at the Financial Times who she had, like, a tally chart that she used to maintain for the month to just see how many days of just coding she's done. And it was so interesting to see how you can put some data behind this and it's not too hard to do it. If I wrote some code or if I read some code today, then I just put a...like, it's a tiny chart. You just put a line on a book, right? And she kind of said that that was really motivating her to keep true to coding always. Or, like, doing something hands-on doesn't have to be. Exactly.
ADRIANA: Ultimately. I mean, what we do is a very creative line of work. And I think as creators, we like to create and it makes us whole.
NAYANA: Yeah, that's so true.
ADRIANA: Awesome. Well, we are coming up on time, but before we part ways, are there any parting words of wisdom that you would like to share with our audience today?
NAYANA: I'm trying to prioritize in my head which one's the better one. I think I'll probably go to one which we are in a macroeconomic situation where everything's getting tight and there are companies that are struggling. And for me, this is a time when engineering efficiency and thinking about how we build more sustainable products becomes quite important. So I think...thinking about engineering efficiencies and trying to not in a sense of I'm going to measure the four DORA metrics or...not that way, but more of what can make my software more sustainable, what can I do to make it more maintainable so that I don't have to put energy once I've built those products and stuff is probably the key thing that it's top of my mind at the moment. And I think it will be more. It's going to take a larger space next year when we don't know where the world is going and stuff.
ADRIANA: Yeah. So very true. I think those are really great words of wisdom. Well, thank you so much, Nayana, for geeking out with me today, y'all don't forget to subscribe and be sure to check the show notes for additional resources and to connect with us and our guests on social media until next time.
NAYANA: Peace out and geek out.
ADRIANA: Geeking Out is hosted and produced by me, Adriana Villela. I also compose and perform the theme music on my trusty clarinet. Geeking Out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the socials by going to bento.me/geekingout.