Sr Dir @ OpenGov | How To Cut AI Signal From Noise

Speaker A: The mistakes that you make are, uh, amplified by the velocity that you have gained. Ambiguity is something that is here and it's going to stay here. AI is just another tool. I don't think it's really another tool. If you don't have a system that controls where the car is going, you have a high risk of adding into a wall.

Speaker B: Welcome to TechTeams today, where we talk to the people building and leading the engineering orgs behind today's most innovative. Our guest today is Gianluca Bickery, senior director of engineering at OpenGov, where he and his team build products to make your local government more effective and accountable. We dig into how he is leading both his team and the entire organization through a time of unprecedented ambiguity. This is a fascinating discussion, and I look forward to all of you hitting that like and subscribe button. All right, onto the episode. Welcome to the podcast, Gianluca. Excited to have you. We are going to jump right in and because we are tech teams today, we want to learn a little bit about your team. So talk to me about the team you have, what their makeup is, if they're front end, back end, full stack, what does it look like?

Speaker A: Yeah, sure. Thank you for having me, Josh. Uh, I'm, uh, senior director of engineering at OpenGov, and, uh, I do run teams, uh, that are both in platform and product engineering team. Um, the team they do have, they cover everything from the front end, back end, um, operation, and, um, yeah, pretty much.

Speaker B: And are you remote? Is everybody in the office or hybrid? What does that look like?

Speaker A: So the company, the company is a, uh, working from work company, meaning we have, uh, um, offices where people go and do their work. So the hub that we have are Boston, Atlanta, San Francisco, and also we do have hub, uh, in India where we have engineering resources. Uh, so it's a company that works from office.

Speaker B: Okay, cool. All right. The world that we're in has always moved fast, but it feels like it's moving faster. And even though that's evolving fast, something that you mentioned when we prepped for the call was, and it's one of my favorite words now, was, it's moving fast, but it's figureoutable. So can you talk to me about how you and your team are, Are. Are dealing with all of the change that's happening with AI and models and just even in your own space.

Speaker A: Yeah, definitely is moving. Has been moving extremely fast. I think that the part that is really important is to, uh, focus on what matters, which is, um, what matters when there are changes that affect us so deeply like is happening right now. Um, and uh, to be a little bit more concrete I thought about this after we discussed last time is that uh, is really applying something like a ah framework that used in the past which is uh, the switch framework. And um, if you look at any change in any um organization uh you can look at the change in the lens of um um a rider, an elephant and the path to walk through. And um, the rider is you human being that you are rational, you know what is happening and uh, you have a, you are thinking about what you should do next. But then there's the elephant. The elephant is the one that really you sit on top of it and is one that involves still from you the part where more emotional. So the part that are about uh your identity, your job security, uh the feeling of uh the ground under your feet that is moving is changing. That part is the part where usually a block you to make progress and then the path that you need to build. And so when you look at these three aspects, the reason why I'm saying this figurable, I think what it is is that what you need to really focus is on the elephant. And so what are the motions that are going on and understanding um, what it really is. How do you create the space for teams to explore, to build confidence and to move forward. And uh, this is what we've been doing in my company. Um and the other aspect of this is uh understanding um, that there is a lot of ambiguity going on. There is a lot of going on and the most important thing is not that to figure everything out but really figuring out what are the next things that you need to do to start building the path of your role to navigate through this ambiguity. And so to be a little bit more concrete, something that many companies, many leaders have been starting doing is that you want to create opportunity uh for small win in your organization. Uh and also you want to build that bottom up engagement in terms of changing the mindset kind of removing the fear of the elephant so the elephant can start making the first few step. Uh because if you don't provide that one as much as you as a rider you're on a leading, you're thinking about the problem, trying to move, doesn't move.

Speaker B: So what are some of the small wins? Yeah, sorry, I just want to dig in there on some of the small wins you mentioned. What have some of those look like where you see it within your team. Like uh. Ah yes, we got it. What does that look like?

Speaker A: Yeah, the, the small win that need to come to focusing on what really matters for you right now. Um, and uh, creating small win is important to make progress. So some of them definitely there are different stages, those are different. But um, there's the aspect of um, understanding and um, figuring out how to use all the tools that are available is one. So um, being able to create the room for doing experiment is important but I think it's also important to do experiment with the uh, with discipline in mind. What I mean is that there are two factors that I look at. There is the discipline aspect and there is the curiosity. So the discipline aspect is the one they tell you okay, I want to solve this problem that I'm seeing in my own right now. And um, the curiosity aspect is the one, okay, let me see if what I'm hearing or seeing or is available help me to get there. And so one thing that we have done is really to create forum for engineer to explore and to share with others the lesson that they learned and the lesson that uh, the things that they learned also that didn't work out. And um, this is really taking care of the elephant. As I was mentioning before. What I mean is when you have engineers that they see from their peers how they've been using AI for addressing for example um, defects, addressing alerts and how that made them uh, operate in more efficient way with outcome, for example can be well the time for us to resolve a defect dramatically slow down. So that's when you start taking care of the psychological aspect that right now is very important to take care of where people they see from their peers and they build confidence and trust more than a top down mandate or you have to do this. And um, this is something that is uh, yeah this is something that we will be doing is very important to be able to uh, making one step with elephant.

Speaker B: Yeah, I really want to stop and make sure that our listeners and viewers understand the importance that Jean Luca is putting on. The mental challenges that we're all uh, and emotional challenges of all of this change and investing in making sure your team can navigate through that because there's a lot of FOMO that's going on out there and even not just regular fomo, but a feeling of I might be missing out on my future if I don't catch up with this. And so how are you? And uh, you mentioned that you're getting it from the inside and helping them see from, from peers but there's also this never ending onslaught of newsletters and podcasts and YouTube folks that are saying this is the new way, these are the new things. And is, is your team trying to manage that themselves or are you trying to manage that yourself? How are you making sure it doesn't feel so overwhelming for you personally and for your team?

Speaker A: Yeah, well, definitely that the amount, um, of information, um, available and the pace that information change is probably unprecedented. What I mean is that. You receive through your plan, social media, LinkedIn, email subscription, so many information about just one topic, which is AI in different flavor, new model, new framework, new tools, et cetera. So, um, it's overwhelming for sure. And I think, uh, at the same time when you do this, you know that maybe the next hour on um, the next day you have an important meeting that you need to prepare and you need to uh, take care of your business and your organization. So there is this, uh, the sentiment that everybody, I believe is feeling right now is really as you described in terms of formal, but not formal to building to uh, missing the party is really form in term of missing the opportunity to stay relevant in the work that we're doing. And so the approach that I do have or the approach that I think we need to focus on is really to dealing with the fact that information is more than what we can deal with as a human being. First, you can't fight that. I don't think you can find that. The other thing is, okay, how do I build filter that allow me to collect only the signal that I care. And for me that means going back to what I was mentioning before. You need to start with the end in mind from the outcome that you're trying to provide for us. In my job, for our company, we're very customer, uh, obsessed. We really care about making our customers successful and we do everything we do to get there. And so you need to start from that. All you need to start from how you make your team successful. It could be that internal process. It can be that there are so part of the operation that you have that you can definitely leverage what you're hearing, seeing to take that part and apply in your team. And um, so that's really the first thing that I would recommend is build the filter that I need to know. Okay, this is something that it can be relevant for me in the context of what I'm trying to do and the outcome that's trying to provide in my organization. You can be just for the sake of one of the things that I believe I heard at the beginning, 18 two years ago, we were saying, okay, AI is just another tool. I don't think it's really another tool. I think actually it require more than that. It required to being able to filter out what is relevant for the problem that you have now and you're seeing in front of you. I want to give an example because I think it's important to contextualize. One of the things that many engineer teams that I work with as a um challenge has been um, the amount of alerts that they need to process and triads were on call. Now if you start from this problem and you're trying to solve this problem and say okay, how can I leverage AI to reduce the burnout on my team or on call which uh, today is generating to my team to be inefficient, to be overwhelmed and probably not to make the right call because they're not able to distinguish between what is important, what is not. When you have an overflow of uh, alerts that are coming. And so if you start talking starting from that problem and you start looking at okay, how I can leverage AI to triage the alert that are coming, how I can leverage AI to um, look at the runbook, look at the documentation that I have and how I can start categorizing the learning. Low signal or low value. High value, such as only the one that matters reach the developer. This is a way to think about solving a problem and then you plug in the AI solution that you need or tool that you need and that's one way to filter this. Um, and when you do that, you're building the small wind that you start expanding your area of uh, um, your area of um, uh influence in terms of what you can change in your arc Adopting AI Gotcha.

Speaker B: Okay, so have you found any trusted sources that hey, like if, if these guys say this I feel pretty good or has it been just like it's all noise and you still have to do a lot of work? Because that's one thing that I haven't found that AI has been able to do is I haven't found an AI to help me wade through the AI noise, you know, to get me like this is what you should pay attention to. So I'm hoping maybe you have something like that or a trusted source.

Speaker A: I don't think there is one person or another. I think everybody has his own set of resources uh, they use. Sometimes there is redundancy. Honestly, yes. I mean there's been a time when I was reading funerals letter that was. I could recognize that they were talking about the same thing. Right. And so there is not a place where to go. I Think, uh, what you need to do is really being able to scan and filter what you care more than where you get the information. Uh, if right now what you care most, because that's what is your team or your organization is about. Okay, how do I manage the operation of uh, our solution? Because I need to elevate the problem that I have today in terms of, uh, um, as I mentioned as an example, in terms of alert, in terms of servability, that's where you start applying your filter in what you read. Is there anything that I can leverage from. There is everything that I can apply from what I read into that problem.

Speaker B: Yeah. The challenge that I feel like we're up against in the industry that we're in, especially as leaders, which makes it even harder, is ambiguity is at an unprecedented level. And you said that earlier in the uh, discussion. But part of what people look for us to do is people look for us as technical leaders to have the answers. And it's almost impossible to have the answers because what might be the right answer today will be different tomorrow because of the rate of change. So how are you managing that with your team across the organization when people are looking at you, Jean Luca, what's the right answer? What model should be using? What, what agents should we have up and running? How are you managing that? Because it's impossible.

Speaker A: Yeah, yeah. Well, we are in a time where ambiguity is super real. Uh, and I think it's going to stick there for quite a bit. And so the first thing is recognizing that when we talk about ambiguity, there are a couple of reaction, a couple of way to manage it, which I think both, they bring into another result that you want. The first one is you think about, you're looking, you're seeking for the information that you need to create clarity, full clarity, and you keep waiting. That brings you to the point where you stay behind, you don't move. Then there's the other aspect where actually the ambiguity comes and you think that you have figured out everything and you set the team and you set the organization to operate with assumptions that you made. And most of the time those assumptions, especially in ambiguity and contest environment, they come also from other pressure. Right. Because, uh, there's not only ambiguity in terms of, okay, what do I do or what do I need to learn. There's also the fact that when everything is moving, when everything's moving fast, there's repercussions. Everything in terms of the decision that you may need to make, the, the sense of urgency that you need, you have as a Pressure to deliver result and uh, the team morale. There are multiple factors that kind of push in multiple direction. And you say, okay, I need to take a decision. And I think that's what we should be doing. And that's how I figured it out. Okay. Both I think are, ah, to the extreme. One of the other one, I think what you really need to focus on is, uh, to build the path, to work through the ambiguity. So first you need to live into the ambiguity. You can't get out all of a sudden. And to do that is, uh, how do I, how do I create, um, to do that actually is also, I have to say there is also the fact you need to be willing to say that. Okay, out of the 10 things that I'm being asked, there are certain things that we don't know and we don't know yet, and we'll figure it out, but let's focus on the things that actually we know. And uh, the landscape is changing so fast that, uh, very likely moving down the road, we will find out our answer. So my first suggestion is bring clarity. But, uh, bring clarity when you can bring clarity and call out the things that you don't and then we'll figure out together. That's the first things. The second thing is really about how to, um, how do I set the direction and so how do I set this small win that I was referring before? And because when the team has a direction and there's a direction that sounds reasonable and sound, that's where you start building the trust and become contagious. Um, we start the call saying, yeah, I think most, we have figured out how to write code and how to leverage that to write code. We know that. I mean, not many companies are doing that. All of them, actually. Not many. So that part is being mostly addressed now. There are, uh, other new part that are emerging in terms of, okay, what are the other things that we need to figure it out? Because the building software and shipping to production is not just writing code. Uh, there's way more than that. Now you start looking around, what are the signals that you see that you need to address? How do I operate the software, how do I do PR review? How do I take care of security and quality? So those are the things that right now everybody is very, very, uh, focused on.

Speaker B: Yeah, I have a sneaky suspicion that the ambiguity is here to stay. Uh, I think of it like the speed limit on the highway. The speed limit only ever goes up. They don't ever lower the speed limit on a, uh, expressway. So I Feel like this is unfortunately the new norm. So everything that you talked about, about being willing to say I don't know and knowing what you do know and being able to lean into that, I think really makes a ton of sense. So let's talk about exactly what you raised is that coding has uh, solved is the strong word, but I don't have a better word for it. Coding is solved, but there's still the engineering that is required to take a product from concept to getting it into a user's hands where they are able to take advantage of it and find value. So talk to me about the work you're doing outside of just the coding piece. Before you get to coding and after the coding's done, what kind of work are you and your team doing to make that better?

Speaker A: Yes, yes, absolutely. So the speed of uh, generating code right now increased tremendously, um, is um, at unprecedented rate. Right. So what we need to focus right now is that, okay, that is only one part of a long chain that we have. And how do I scale the velocity to the other part of the software development, um, from the design to the PR review to the testing to uh, the CICD and then operating production. The solution which is uh, more code means statistically more bugs, right? So um, that's the part that you need to start focusing on. And there are few, few, few way to look at this. The analogy that they do have is it's like sitting uh, in the car where the engine all of a sudden is able to go, uh, go for 300 miles per hour. Right? But um, that's your code production, but co generation more than production. But if you don't have around a system that control where the car is going, you have a high risk of uh, adding into a wall. And so think about the cars, right? The car. We do have a lot of systems, uh, that control where you're going independently by the speed. You have line control if you're drifting out. You have control in terms of the car in front of you. You have control in terms of the um, status of the road. This is freezing or not. So when we apply that one to engineering is very similar. You need to start building all the uh, indicators that you need, such as, you know, when your car is driving and drifting from the lane. This is where in my opinion, the indicator that we use in the past are even more important today. So the number of defects compared to the frequency of releasing code, uh, if you see in your um, rca a trend in terms of, okay, the root cause has been mostly because we have code that we push which was Genai. Well that's a signal that your system is giving you that you have lost faith or you don't have a system ah, of control in place that can guarantee that you can operate the speed. And I want to make clear that this is not about is because we use AI, it's not that I think uh, this is because we didn't have the right governance around it and the system of control in place. Um, so this is where we need to focus on one aspect and the other aspect is really to keep scaling the velocity gain in all the part of this dlc. So testing if you're not able to automate your testing, even if you can generate testing with AI, but you're not able to automate your testing doesn't bring you anywhere. And uh, if you're not able to triage your alert and your defects at the velocity or with, with, with the rate which is correlated to the velocity of the rate that you push code to production, you're going to bring your team in the status of paralysis on point. So there are two aspects. There is understanding scaling the velocity for the full sdlc and there's another aspect which is having the system of control in place. And uh, and we, the other thing that I want to mention, this one which I think uh, is very indicative, we've seen and we're seeing in the industry already this problem quite a bit. And um, if you, if you look at Amazon, Amazon, um, as of March of this year they have at least I think around 13 or 16 hours of outages. If you compound them all together, uh, and the loss for the company is around $6 million of revenue of order that will not be generated for that. What this tells me for me is that when you have velocity in production and pushing coal to production, the mistake that you make are uh, amplified um, by the velocity that you have gained. Because now everything, all the pressure, the velocity keep going down into the chain of the development where if you're not able to detect issue, if you're unable to have this control in place in what you're doing to make sure that you guarantee the quality, to make sure that you guarantee the security of what you produce, the impact of not doing that is way more in cost than the impact of not gaining the velocity. At the time that we're talking about writing code, in fact Amazon, one of the things that they did recently was they want to make sure that every code that's pushed to production is reviewed by at least one person, if not two. So those are the things, the lesson that we need to learn because this is what we are experiencing right now every single day. And that's another angle of looking. Okay, how do we scale and do we protect and what are the implications if I don't do that? What is the cost? And the cost can be amplified by quite a bit compared to before.

Speaker B: Yes. If we stick with your analogy of a car and coding as the engine and as you've been trying to improve the steering and the brakes and everything of the vehicle that's going down the road to make sure it's safe, have there been any surprises, good or bad as you realized, oh boy, our brakes are really bad, or our brakes are better than we thought and. Or anything around that, where, where it's been a surprise?

Speaker A: Well, there have been definitely some surprises. I mean, one thing that we need to, we need to be able to do faster and automate more is all the, um, CICD part. Um, that's one angle where I think everybody is right now paying a lot of attention. Right. So the continuous integration is key and uh, you need to scale that one, uh, as part of your SDLC improvement. So that has been one. Another area where we're paying a lot of attention is about the quality of the code. And, um, because the gain that you have in going faster is not meaningful. M. If you are actually delivering something which is not up to the expectation of the customer. And so I was mentioning before, we are very customer in terms of what matters the most for us is having our customers successful in what they're doing. And uh, if we give them something that doesn't meet their expectation, we'll lose their trust. So it's very important that also the quality aspect and doing quality right now definitely needs to be revisited, but it's very important. So those are the two areas CICD and quantity work. Uh, we are investing a lot of attention right now.

Speaker B: Cool. Do you have any early wins with quality? Because quality takes a lot of shapes. Both the review of the code by peer developers or if you have a quality team or automation and the whole combination thereof. Do you have any early wins? If you've tried to look at how we get better at, uh, that this

Speaker A: is where we need to think about leveraging what we have today and how can help me to solve the problem that they have. Right. So right now for sure, uh, we don't have team writing test, but with team writing spec about the test that needs to be done. But when you in a sense democratize what is the testing? What is the workflow or the end to end user, uh, story that we expect our customer to be able to do? And you're able to do this in a natural language and just claim this into a file. That's where you start democratizing the testing and the use cases that you want to cover to something that everybody, especially domain expert, Domain expert, they can leverage to make sure that your testing is accurate. So that's one area where it's very important right now to focus on. Um, the other one that uh, company in this specific sector, but also company that just produce software is about observability and streamlining, uh, the feedback loop. Right. Uh, being able to, I was mentioning before, the example that I made is very real. Right? Real, at least for me, which is, uh, how do I, how do I empower my teams to take the feedback coming from the operation of the system and identifying what are the trends, what are the insight that we get from that information? Uh, because that one also will drive how we're gonna, we'll drive and reshape our Roma. So uh, usually historically that is something that require a lot of analysis from engineers to look at. Historically, okay, what are the alerts that we had, what are the bugs that we have? And is there any pattern that we see that we need to do something about that we need to fix something? Our software, now you can do that in a matter of few hours. And so, uh, this is uh, another aspect where investing into solving a problem, which is accelerating the feedback load by leveraging what you have, show that the approach is really outcome oriented. And so you said, what are your expectations and what is driving you to an experiment, but you anchor that one to metrics that you want to get out. Those can be insight in terms of where to invest in the roadmap. Those could be, um, part of the product where you want to extend the testing starting by the user Persona and uh, the domain expertise they have in the company and you empower others, ah, to chime in and to provide real value, which is uh, the expertise of the domain in what you're building. So those are two angles that uh, uh, AI can help you a lot.

Speaker B: Okay. All right, I want to um, start to wrap it up here. And the last thing I want to leave with our viewers and listeners is something that we talked about where with all of the changes that's happening, you have two choices and you talked about a little bit, but I just want you to expand a little bit further about the ambiguity. You can either run from it or run to it. And something that I was very impressed with when we talked the first time was you're trying to run towards it and you're trying to lead an organization that will do the same thing. And that's easy to say but hard to do. So talk to me about how you're approaching that with your team and getting them to be willing and ready to lean into it.

Speaker A: Got it. Well yeah, I mentioned before, ambiguity is something that is here and it's going to stay here. You need to get comfortable with that. And so at the end, uh, you need to anchor yourself in what are the principle that you use to navigate through ambiguity. You don't get out of it, you navigate through. And uh, I was trying to mention a few of this uh, in what we discussed before, right. Which is um, there is an aspect in terms of listening for the human signal that you have in your org. That's one. There's another aspect which is about really um, making sure that you are real and honest with all the people in your organization and your team in terms of what you know and what you don't know. Um, uh, is also true that when, if we look historically about uh, the most successful story that we have in the tech industry, for example, there can be most of the time from. It's not a straight line. So usually you go through uh, time where well probably you also fail but you learn from that and you stick with something that is the principle you're driving. Uh, think about Slack. Slack was not thought and was not didn't, was didn't start as a uh, communication company for enterprise. They start as a game company and they fail. But when they fail they look at what they built and they look at okay, what is the value that we have which is the system of communicating internally that they add and the pivot over. So this probably is an example where you need to keep, anchor yourself into principle how you operate but also to look at. And this is something that is very important, you need to look at at any time in ambiguity. You need to look at forward as much as you can with answer, but also backward and backward. What I mean is that look at the progress that you made. Look where you were a uh, month ago, three months ago, six months ago. And what are the good things that are coming out of that? What is the foundation that you have that you build confident in the direction that, in what you're doing, the direction that you're going. So to answer your question in terms of uh, how to deal with that and what, first of all, ambiguity is going to stay there. But the second is that, ah, you need to be able to look also at. You need to step back and look at where you're coming from, what did you achieve and be honest about what you know next. And to do that, people need space, leaders included, this space to, uh, step back and get out of the day to day, the reactive mode. But really think about retrospectively with stepping back for me, for me. I do that. I do love biking, so I do. This is one of the time where when I'm biking I have my mind really clear out and you can really think about. Okay, now hold on a second. I didn't think about this way. Right. This is what for me is the space that I have for my brain to detach from the day to day and to think more broadly and also retrospectively about what we've been doing for other can be meditation, take a walk. Uh, but I think my advice is for everybody, every leader today is really also to find the space to step back and to think a little bit more broadly. Both look looking forward. Also what you learn and what are the things that you want for your next move. What are the principles that you're using? My principle has been so far has been to really, and I mentioned the beginning, the switch framework, which I think is really where I anchor a lot of my, um, thought in terms of how to deal with ambiguity, um, and which is based on the small win and taking care of the emotion of people. And then building the path was one step at a time.

Speaker B: All right, so we know that when John Luc was on his bike, get out of the way because he's thinking through some stuff. Uh, do you find that you go faster when you're working through a problem, or do you go slower whenever you're on your bike or you don't know yet? And I'm sorry, if I just asked you a question like, oh, no, I might go faster.

Speaker A: Well, when on my bike is really what I actually, I don't think I'm going faster. I think I'm going to, uh, slower in terms of thinking, but more thoughtful. I, uh, my state of mind allowed me to think, uh, a little bit more in broader term. And uh, that's what it is.

Speaker B: Gotcha. Gotcha. Okay, cool. Yeah, it's a walk for me. A walk will get a good problem solved for me. So I certainly align with that. Definitely. Okay, we're gonna wrap up here and we like to end with a handful of what I call the leadership read Me question. So this tells all our listeners and viewers who you really are and what you really care about. Um, so these are six questions that John Luca has not seen or heard, but they're not scary, don't worry. Um, the first one, there's a animated image format that is spelled gif, but there are a couple of different ways to pronounce it, and it's usually combative the way people talk about it. How do you pronounce that?

Speaker A: The. The format of the pizza.

Speaker B: Yeah. Do you say gif or gif? Which one is it?

Speaker A: Gif.

Speaker B: Gif. You're a gif. Okay. Uh, I'm a. I say gif. Uh, but that's okay. That's okay. Uh, all right, let's talk about, um, some piece of leadership content that always lives in your head and is trusty. It could be a book or a quote or a podcast or anything that whenever you get stuck, when you're on your bike and you're trying to figure something out, that that book always helps you figure things out.

Speaker A: One book that I keep going back and, uh, I find it very, um, useful for me to reset in the sense how I think about things going on in my life is the seven, uh, habits of successful People. Um, which I think apply a lot into what we're living today, especially with AI. Um, definitely that one is a book that I keep going back to. Um, I think provide a very

Speaker B: excellent,

Speaker A: um, framework to go through challenges, problem, and also making the decision for the person that you want to be and how you want to interact with people.

Speaker B: Gotcha. Gotcha. Yeah, that's a classic for sure. Okay, um, Operating system of choice. Mac, Windows or Linux or something else.

Speaker A: Mac.

Speaker B: Mac. Okay. Gotcha. Gotcha. Um, let's roll the clock back to when you shipped your first product. If it was you by yourself or you as a member of a team in your first job where you were delivering a software product, what technology was it? If, if you can remember what it was?

Speaker A: Yeah, good question. Well, there's been a time where I was, uh, working on few things, so I want to mention this one, which is, um, a solution that we built for, um, the web 2.0, at that point, application for, um, sending, um, digital coupon to people who subscribe, um, was way before LivingSolo Groupon was few years before that. And, uh, we built it with few people using it was a lot of fun. And, um, the technology was Ruby on Rails.

Speaker B: Okay.

Speaker A: At that time, I think everybody was building Rubio Rails. So that's it.

Speaker B: That's Good. That's good. Yeah. There's a ton of great products that are built on that for sure. Yeah. Okay, so you have the magical and wonderful two hour block of time where no one's going to bother you and you have a clear list of things that you need to get done. So it's just you and your computer and you can go knock off a bunch of things off your task list. How do you do the work? Are you a keyboard only guy or are you a mouse and keyboard? Are you a trackpad or do you have some other input device that you like to use?

Speaker A: I understand, I did understand this.

Speaker B: Um, so, so it's rare for us as leaders to get dedicated time or we can just do a bunch of heads down work. And there are different people that like to use a mouse or mouse and keyboard, or there's some old school coders that never take their hands off the keyboard. How do you do really intense work?

Speaker A: Oh, got it. Got, uh, it. Well, I do, I definitely use mouse and keyboard when that focus time, especially right now, the time that I have to do, um, focused work is really time that I dedicated to, um, exploring, writing code while writing, probably, uh, explaining to a, uh, few agents how to write code, to be honest. But uh, it's really closest to software engineering work. Um, and so uh, that's what I use as a keyboard, as a mouse. That's what I'm used to use.

Speaker B: Okay, so even though you're a Mac guy, you, you prefer a mouse, not the trackpad, is that correct?

Speaker A: Correct. I don't, I don't find myself, uh, uh, I, I try. I, it didn't work out well for me.

Speaker B: Okay. Hey, you know, at least you gave it a shot. Okay, final thing.

Speaker A: Uh, I do use the per minute. I have to say I like to use a lot of the keyboard as much as I can. But, uh, um. Yeah.

Speaker B: Yeah, gotcha. Okay. Um, all right, so final thing, uh, for everybody that's stuck around and wants to hear more from you, is LinkedIn the best place to track you down or do you have other social media profiles that we should point people towards?

Speaker A: Sure. LinkedIn is the best one. I, I went off a social media diet.

Speaker B: That's fair.

Speaker A: So that's the one that I use actively. That's the best.

Speaker B: Simple enough. All right, Jean Luca, thanks so much for being a guest. Was wonderful having you. And we are done here.

Speaker A: Thank you very much. Thank you for having me.

Speaker B: Josh, that was Jean Luca Bickery, Senior Director of engineering at Open Gov. I know there's at least one person you can share that with. Go ahead, share with them. That's how we grow this show. Thanks for helping us out. Tech Teams today is brought to you by Revelo. If you're looking to build out your engineering team with world class vetted talent from Latin America, that's time zone aligned and ready to ship, check us out@the Revelo.com. i'm Josh Anderson. Thanks for being here and I'll see you next episode.