How to Increase Adoption of Internal Developer Tooling | Bloomberg’s Luis Vega

0:00I was so excited about it because it was such a technical challenge that I started coding all the critical parts. and I didn't realize I was literally blocking the team because the team was waiting on that big infrastructure that was going to connect all the pieces together. That realization of like, you're not here to be the star in the code. You're here to make sure they become the star. So when it really hit me that like, I just needed to get out of the way of the tough technical coding, things really start happening. But I really wish people think about this now that are becoming managers for future managers because they will not have to get burned so many times.

0:40And, you know, people have to learn sometimes by getting burned and go ahead, do the critical part and learn yourself. But that's the one lesson I will tell any future engineering manager. How can you drive developer productivity, lower costs, and deliver better products? On June 20th and 27th, Linear B is hosting a workshop that explores the software engineering intelligence category. We'll showcase how data-driven insights and innovative workflow automations can optimize your software delivery practices. At the end of the workshop, you'll leave with a complimentary Gartner Market Guide to software engineering intelligence and other resources to help you get started.

1:17Head to the show notes or linearb.io slash events to sign up today. Hi, everyone. Welcome back to Dev Interrupted. I'm Ben Lloyd Pearson, Director of Developer Relations here at Linear B. Today, I'm joined by Luis Vega, an engineering manager at Bloomberg. Luis, it's great to have you here today. It is my pleasure to join you. And I'm pretty excited to be in this bubble. A dome, please. A dome. I'm sorry. So you were recently recruited to lead a team that owns, revamps, and creates applications for Bloomberg's JavaScript framework, which is used by thousands of developers across the company. And your goal was to develop internal tools that follow many of the same application development, research, and UX design principles that are used in Bloomberg's client-facing tools.

2:08So from what we understand, the challenge was not only that there were very few internal tools at the company to aid you in that process, but the ones that existed weren't very well embraced by developers, like even including yourself. So I want to dive into what it took to revamp the internal applications at Bloomberg and the path that you followed to become a manager along the way. I think that sounds like a pretty interesting story. But before we jump in, because we may have an audience that's not as familiar with Bloomberg, can you tell us just what is Bloomberg? Yeah, absolutely. So you probably hear from Bloomberg if you go to like dark news or if you happen to be on our Bloomberg TV channel.

2:47but that is actually not what we do. Those are just information sources that feed to the Bloomberg terminal. So Bloomberg, a main product is called the Bloomberg terminal and it really powers financial professionals around the world. If you really want to do serious stuff in finance, you need a Bloomberg terminal, basically how it works. The best way to think about it, imagine your phone and you have obviously tons and tons of applications from your app store or play store, whatever. The Bloomberg terminal has over 20 ,000 applications. We call them functions. You're going to hear me say that a lot.

3:23Installing to the Bloomberg terminal on the get-go. So somebody with access to the terminal can basically type one to four letters and run one of these applications. The internal tools use the same technology. Talk about eating your own food. So in order to make an internal application, you can also use the same technology and the same things. And we put it in the Bloomberg terminal. So employees at Bloomberg actually have free access to the Bloomberg terminal, little employee perk there. So that's a little bit what we do in engineering. So that is the core of the company there. Great. And I love, this is going to be horrible to say, but I love hearing about tools that developers ignore.

4:03As a developer who, as a former developer who used to love to find ways to circumvent coding standards, I want to hear a little bit more about the state of internal tooling when you joined and why developers, including yourself, failed to embrace them across the organization. Yeah. So we have to dial back the clock to like 2000, maybe 17, 18, right? And since engineering teams in software infrastructure, let's say they were providing frameworks for other teams to build these tens of thousands of applications. Sometimes they were like, oh, but we also need, you know, an internal tool to manage our particular framework or whatever it is.

4:44So engineers will build an application as part of a managing kind of like their framework. But it was more of, oh, we need that tool rather than really carefully plan it from the beginning. So the same team that, you know, provide a service or a particular API to the whole rest of the company was building these tools as a side project per se or as a need basis. Let's call it like that. At the time I was a senior engineer in Bloomberg at a charts and data visualization. We had to interact a lot with software infrastructure because of the tech that we were using, all of the widgets and the graphing applications.

5:26So we had to use a lot of these side tools. And I've been very vocal all my career, I think. So whenever we see something, you put a ticket, is my saying. So I ended up dealing with a lot of tickets of these tools with these software infrastructure counterpart. To the point that I was known for being the person demanding things. And this is how it all began. So that was the state of the world kind of like for some years at Bloomberg. Yeah, and I imagine developers do not respond well to demands, right? Well, you know, the response varies, depending on how you ask for sure. But yeah, so to continue on your question there.

6:09So what happened was the manager of these tools, I had a relationship with him, you know, and then he saw me in the elevator one day and he said, Luis, I was talking about you. I was like, okay, this is not going to be good. But then he surprised me and he said, we've been thinking about building a team dedicated to build these internal tools because you're right. We had it. You're showing us that we can do better. And then he literally offered me to lead the team to build the tools that I kept complaining, not complaining, but, you know, opening requests about with proper support, full time support.

6:47And I thought. This is an excellent opportunity. Maybe we can really turn this around, right? So after a lot of hesitation or like personal hesitation that I went over to my talk, I decided to do it. And then I started this team, right? And then we started like saying, you know, what if the internal tools are awesome? What if we actually put the time and engineering resources and UX resources to make them great? And that's how the whole dream started. We started with a small team. Actually, it was me. Two pre-trainees, a fantastic pre-trainees, by the way, and a UX person. And that's a little bit of the secret superpower that we found out.

7:29We were able to work with a UX colleague of ours that she had a lot of technical background. And she was like from day one, a member of the team. So we treat her as an engineer, right? She was part of our sprint planning, sprint reviews, all of the rituals. and we started really designing these tools, interviewing our engineers, right? One of the things that was a missed opportunity is that these tools were for our own colleagues. We know them, we have lunch with them. So we actually said, hey, why don't we just book meetings in their calendars and let's meet with them. Let's see what their pain points are.

8:07So we actually started exploring that. And before we started doing all of the development, we started like investigating what we were gonna do. Then we came up with the whole idea of the mascots, which is, if you haven't watched a talk, watch it. Lead dev. Lead dev, sorry. Okay, so the mascot development. The idea here, so in Bloomberg, I mentioned you have all these tens of thousands of applications, right? We call them functions. The name of these functions is one to four letters. That's it. I'll give you an example. GP, graphical platform. And then it gives you a price graph and things like that.

8:43They're letters. We call them mnemonics. So our idea was, instead of using conversant mnemonics, let's create words. Or, you know, words that people understand and remember. So our first application was called Jack for Lumberjack, because it was an application to bring logs from our customers. Whenever they have errors, whatever, we can bring the logs into engineers' desks so they can analyze them. So we called them Jack. Why Jack? Because it's Lumberjack. And the mascot is like this very cute Lumberjack that was inspired on one of our colleagues, actually. The lumberjacks bring the logs, which are the customer logs, whatever.

9:17It was like a little cheesy explanation to support it. I love cheeky names like that. Yeah, yeah, yeah. That's wonderful. But the point is, now people are talking about Jack all over the company. And they're like, oh, have you used Jack, Jack, Jack? Oh, they have stickers. They have a mascot. And then the engineers start being like, I developed Jack. While all of the other engineers were developing letters. So it really created this identity and this passion on our engineers to be like, we need to build. Jack has to be awesome. I mean, you're effectively turning engineers into like celebrities almost within your company.

9:47It is true. Yes, because they started getting so much exposure, you know, and recognition of like, and Bloomberg has a lot of ownership. So people already have the whole concept of like somebody owns something. So when you start owning the stickers that like managers and like start having in their laptops there. Yeah, you're right. They start getting popular, which is a great thing. So just have an OKR for the number of management people that have your sticker on their laptop. I definitely did a little desk drops. So I would like identify the desk of like the top head departments in engineering and come early and like drop some stickers there, see what happens.

10:25Sometimes they stick on their laptops. I'm like, what is this cute doctor? So anyway, so that was the idea. And then, again, the superpower of the UX, I have to say, because people were used to the applications we had internally. But then you really come and hit them out of the blue with this well-designed. Kind of like my manager used to say, look, everybody, and not to, you know, throw shade on any cars, but this is what he said. Everybody's used here to like all Toyota countries. And you're building like a Lamborghini, like with top design, with all of the tools, belts and whistles. and we're like, okay, I guess that's what we're building.

11:01We're building a Lamborghini of an application. And so, yeah, we started with one, with Jack, and then it was wildly, wildly popular. And then we said, okay, let's keep revamping all of our tools. And then we're rapidly starting doing the same process for all of our portfolio of tools. And before you know it, you fast forward the clock, one year and a half, one year, and then we have recruited top engineers because they get like, oh, I want to be part of that team. Of course. That's what I want to be. How do I get my own sticker? Right, right, exactly. Like, I want to own my own thing, right? And, you know, I really thought I made it when I saw one of our engineers having the sticker on the back of their cell phone.

11:41I was like, that's it. That's wonderful. They're bringing this to brunch. They said, we made it. They're talking about, you know, all these applications in their daily lives. This is amazing. This reminds me a lot of, like, the Lumberjack example in particular of how, like, a lot of open source communities sort of brand themselves, you know? So it's like, I don't know if you're familiar with the concept of inner source, where you take the practices of open source internally into a company. But I love that. And it's such a, like, it's silly, but it's such a motivating factor. Because, like I said, you're creating this shared identity that you can then celebrate and that you can then elevate people who are involved with that.

12:17And I mean, that's beautiful. Yeah, yeah, it was good. The mascots came from another colleague of ours, a visual designer. and he does amazing visuals for work and outside of work. Nice. And then he had a good relationship with the manager. I met him. We really kick it off. And then, you know, all he wants is to make sure that he's building cool mascots and that people can see them. So when we told him, you know, we can't put in the stickers and everything, he got really excited. Now, the word got out. So obviously other managers were like, whoa, have you seen what Luis is doing with his team?

12:54Who is your designer? Oh, my God. So they talked to him and he became really popular. Yeah. So you can imagine today, I believe he has built over 50 mascots all over the company. He has a backlog of mascots. It's hard to get one now. Wow. But the real story here is that this idea of creating a personal identity for what you build has really spread across the company. Yeah. And I really think that that's what's pretty about it. Because it's not like nobody's taking the credit of the idea, but it's more like as a culture, it's evolving towards that identity and that brightness of like, this is my code and it's good code, you know?

13:38So I think that's beautiful. Yeah. So we talked to a lot of people who work in platform engineering on this podcast and at our company. Would you classify like this work as a form of platform engineering? or is it different in some way? So particularly what I do is tools for developers to be more productive in their entire life cycle. Coding, finding documentation, finding code samples, all of that discovery phase. The releasing part, knowing all of the assets they own, making sure they release consistently, making sure they don't forget one and the debugging side. So obviously the part of, you deployed everything and things crash, we built a lot of applications for that.

14:25In between, we have a team obviously dedicated for all the ticket management. We're actually on the ticket platform that Bloomberg uses. So it is definitely, I don't know if it's platform, but it's more, I would call it developer lifecycle. Okay, or developer experience. Developer experience, which is the name of the department. Yeah, okay, wonderful, wonderful. We got there. So I want to touch on a comparison that you made a little bit earlier. So you're in a world where everyone at Bloomberg is driving Toyota Camrys, I think you said. The Lamborghini dealership opens up next door. Obviously driving a sports car like that, if you're used to just driving an automatic Camry every day, leveling up to that higher quality, to that deeper engineering, the more complex feature set.

15:14Did you have to do a lot of training to sort of like level up engineers that were using some of this stuff? Or did you try to make it the Lamborghini that's as easy to drive as a Camry kind of thing? So, yeah. We definitely value, you know, making it easy to onboard. But as you said, you had to have some learning. So we actually did something for this that I want to comment on. And we are big on chats in Bloomberg. We have a chat for everything. We use our own platform, Instant Bloomberg. Think of your instant messaging. We also use it internally. It's also an external product of Bloomberg, so I can talk about it.

15:56But we have chats, technical chats for absolutely every community and stuff in Bloomberg. So what we did in our applications is we created a reusable component basically called live support. So on the top right of any one of our applications, you have this live support button. you click it and it's kind of like a little bit of a clickbait because it automatically adds you into the support chat for that given application and now you're there in a community of people that are that know this application going back to the popularity and the rockstar engineers they are the ones that are answering all the questions because they're the ones that know so when somebody wanted help they have this live support button and now they're talking to their colleagues.

16:37And that created multiple things, right? It created our engineers to be much better at communication by answering questions from their users. It created a community of people that train itself on how to do things because the third time you ask something in a week, people know. We're like, yeah, yeah. People that are not of your team start answering the questions. They're like, nice. Maybe we should hire them. Maybe we should recruit them, right? So it created that community base. So yes, there had to be some learning, but I think we really use what we call our support chats as a self-growing community of experts of each application.

17:21And, you know, kind of like a subreddit that like becomes expert on how to share best at Costco. Right. Every niche question you can imagine there's someone there. Exactly. And obviously the history is there and then there are like facts. And so, yes, there is a learning curve, but we leverage our community for it. Yeah. So is there is there some sort of extrinsic, like motivating factor for people to answer questions or is it simply just like you have a culture of people wanting to be experts and wanting to lead and just sort of intrinsically wanting to make make that, you know, that effort to help out colleagues?

17:57That is a good question. I really think it's the culture. I really think in Bloomberg, we're just so ingrained on helping each other and on teamwork that if you know something, you just want to share it. But it's a good question. I wonder the people that participate a lot, if they have some other motives on them. But really, like I participate in the things that I know and like I do it because I think it's the culture. Yeah, I know the answer to that. So why would I keep it to myself? Yeah. Yeah, I think we have a culture of like sharing. That's really awesome. Like, do you know where the source of that culture is by any chance?

18:33I mean, it's a large company. So I really think it's ingrained in the way. Well, I'm going to be a little cheeky here, but I really think it's what Michael Bloomberg believes because he always like promotes talking to colleagues and you see this in the form of the elevators not stopping in every floor. And then you have to see people. And, you know, as Chickas, it's up. I can attest to that because I got my managerial role because my manager saw me in the elevator. You know, years later, he confessed to me that he had a second person in mind. And I was actually number two in the list. But he saw me first.

19:10And you convinced him while you were in the elevator. That must have been a good elevator pitch. Right. So, you know, it's fine. I got, I accepted. I mean, his number one pick is an awesome colleague of mine. But, you know, it works. So I think it's ingrained in the culture. And we have a pantry where everybody gets food and talks. And it is well seen. And people get known, I guess. Maybe we can just step back just for just one moment. So let's go back to when you set out to create this tooling. So what was the biggest or the most important thing that you felt like you had to tackle when you were first approaching this problem?

19:52I think the first thing that we told the team and we told ourselves was we're not going to code. Don't code anything. We need to understand what is the problem so we can come up with a solution. Too often in engineering, you want to answer before you have a proper question. So I feel like we really, it was a little bit of a tough sell at the beginning. I remember my managers were like, but why are you not coding? I'm like, no, no, no. I need to interview people. And it was literally like a roadshow. Like we had meetings back to back with the UX person we're working with. I've actually had a lot of success with roadshows in the past.

20:31Yeah. And like, and we started interviewing. So when we understand the question, the problem, then we said, why don't we just build that solution and start from there? So we started with a very simple MVP of like, hey, let's download the logs. Let's make sure we can bring the loans through to, you know, to be able to open them. And then we started from there and building from there. Different organizations have different experience working with UX all over the spectrum, I bet. But what we have really found extremely successful, and I almost call it, I mean, I really call it a superpower for us, is to be able to ingrain them as part of the team and not use them as consultants.

21:11Like, oh, you know, we'll send these documents to UX. No, no, get them in the meetings, get them involved. And if they lack a little bit of technical expertise, get them a little bit on board, like get them to understand what's happening. Get them in the chat again of like where all the PRs are flying by and like they can see what's going on. And yeah, I think that was very useful. Nice. And then you talked about a little bit of resistance from from leadership around like how you approached your first step. Was there anything else that you felt like some resistance so that you had to spend a little extra time getting them on board with this effort?

21:46Like, and maybe this happens like long before you even kicked off this initiative. Yeah, I mean, everybody's going to at some point talk about ROI, right? Okay, so we're investing these resources. What are we getting back, right? And I feel like more than resistance, that was a very burning question. Because at the end of the day, we had the opportunity of creating a roadmap and decide what was more important if A was more important than B. but we needed, we know, we knew, I knew that I had to show to management that what we did made sense and that it's successful. Now, with that in mind, we took advantage of a lot of usage tracking technologies that we have at Bloomberg to make sure that users are running the application, what features are they using, what workflows are they following, and the usage numbers and then really took advantage of my years in charts to put everything on a chart.

22:46I'm, you know, on the tagline, like your status in the IB chart, my status was put a chart on it. And yeah, I really, I'm very visual. So I made sure that everything we do, we're measuring so that when we release it, and look, not every application was a success, right? But when it wasn't, it was clear that it wasn't and maybe we needed to shift gears to something that was skyrocketing. We had to migrate a couple old applications to new ones. And we use charts to show like literally using the dropping of the old one and coming to the new one. We had a lot of features to make certain workflows faster.

23:26And we measured that to the point that we had a chart of hours of engineers saved by going a new workflow, like the new workflow versus the old one. And we had like a big number that keep growing. So I think that was one of the things that I anticipated to be resistant. I'm actually curious, how are you measuring the number of hours saved? Yeah, well, this one was very easy. I'll explain. So you had to, in order to release code, they had to like select the stuff that they're moving, they pick their deployment, like a number of sets, a number of steps, think like three steps that they had to do.

24:04But a lot of them became a little boilerplate, and you can actually derive the information a lot. So it became more like, you know, like checking a form when you entered somewhere in America, like everything has a form and it's like, are you guys really processing this paper or it's just paperwork? It felt like that and we could derive it. So now we created a quick way of doing that, which was a single click. You pre-fill all the information, like the format where to parse the data once and then you just click it. So what we did is we released it to half of the population and we start measuring the time that they took before, for months, before we had this feature.

24:38So we knew that the average of creating this process was about, let's say, 40 seconds. But in the new one, it was instant. So it was like, we were generous and said, okay, we take two seconds to process it. So let's say two seconds, but it's to 40. And then we just measure, we basically backtest on how many times this request used to happen before we created it. And we start measuring the new one. So you interpolate, you like supersede the graphs and then you can see how much time was spent before and after. So this one was very straightforward. One of the few that was straightforward. Yeah. Have you been able to do anything to tie what you've done to like the quality of your engineering?

25:19Like are you shipping more reliable code? Are users happier? Or have you seen anything like that? Definitely the user happiness. I think it's a big one. And we do have this document where we keep all of the quotes that come from users that we capture in all the communication channels. And we're very eager to display this to management every time there are questions about things. I'm like, oh, you know, this person that started with you at Bloomberg 25 years ago, look what they have to say about the application. So definitely customer feedback is huge. And one of the things I really, really learned is like my first seven years at Bloomberg, I was working on client-facing applications, right?

26:01Hundreds of thousands of users per day. all of the Bloomberg users in the world use it. And that felt great. But the feedback loop is harder because customers are not in your company. And, you know, they're busy doing work. Sometimes they give feedback. But when I moved to engineering tools, I really thought, oh, am I not working on the most, like the bigger thing, right? Like how am I going to get that customer feeling? But the reality is when you work on engineering tools, you get the feedback loop right away. So that was very gratifying. And I guess customer feedback to answer your question there.