Angie Jones (00:00)
the engineers are taking the heavy, meatier, riskier task. But those things that are pretty straightforward to do, assigned it to Goose. Goose did those too. A second time.

They were done. They had to pull in more work. This is developer velocity. We are changing how we do software engineering now.

Ankit Jain (00:23)
Hello, and welcome to HangarDX podcast. This is a podcast about developer experience and how engineering teams solve productivity challenges at scale. I'm your host, Ankit, co-founder of Aviator. At Aviator, we build developer productivity platforms like Runbooks, which is a multiplayer AI coding platform. Today, our guest is Angie Jones, joining from Block. And we will be diving into some of the new transformation that Angie has driven at Block and some of the

ways through which other organizations can learn about improving AI adoption. But before we get into the topic, Angie, thank you for joining us. I'm looking forward to this conversation. Why don't we start with your background a little?

Angie Jones (01:02)
Yeah, sure. ⁓ So I am the VP of Engineering, focused on AI tools and adoption at Block. And I've been in tech for many years, 20 plus years, and started as a software engineer, focused a lot on ⁓ automation and things like that. am ⁓

an IBM master inventor. So I've always been like just at the kind of cutting edge of technology and wanting to work on the new hot things that are even inventing the new hot things, you know? And so naturally ⁓ I've been talking about AI even before the Gen. AI explosion, you know, ⁓ and kind of warning people that this era was coming, like that AI would become a part of our job. So fortunately,

⁓ I worked on teams where we utilize things like machine learning and stuff like that and automation. And so I felt pretty well equipped for this new age, even though it's not what I imagined, you know, fully. And so I feel like we're kind of all in the same boat as far as engineering and like learning how these tools work and how to.

best make use of them. They're non-deterministic tools, which is a new type of tool that we're adding to our toolbox, not just adding to our toolbox, but kind of ⁓ being pushed by companies around the world to incorporate them. And so that's a lot of what I'm focused on these days.

Ankit Jain (02:38)
That's amazing. obviously, AI is changing every discipline in an organization. And Block is such a large organization. If I remember correctly, it's about 12,000 employees. So tell us a little bit about how did this all start, like this AI transformation journey? Was it sort of like gradually building up to it? Or was it at some point a tipping point where it was like, OK, we need to kind of rethink our strategy and start building?

Angie Jones (02:43)
Mm-hmm.

Ankit Jain (03:07)
better or like more focused.

Angie Jones (03:07)
Yeah,

like most companies, there was definitely encouragement from leadership for folks to explore these tools and how they might make them more efficient at their jobs. But also, our engineers, they were probably like most shops, like the first adopters of, you know, Gen.E.I. tools

And so they were moving incredibly fast. now you engineering isn't the only party involved in shipping products, right? Everybody else is involved too. And in order to even keep up with them, I think this is my theory that, you know, everyone felt the need like, oh my God, we have to use these tools if we're gonna keep up pace with the engineers.

Ankit Jain (03:57)
OK, so a lot of this conversation now started from the article that came out recently. And this talked about how there was a two-month period where it did a lot of push towards AI adoption and built out a lot of tools. Can you share a little bit about the background of that? How did that kind of start it? And what came out of those two months?

Angie Jones (04:18)
Yeah, so this is a really exciting journey for our company. So we have ⁓ an individual contributor, an engineer by the name of Bradley Axton, who is a machine learning engineer. And Bradley started tinkering with trying to build out ⁓ an agent that can help us automate some of our ⁓ engineering.

tasks, ⁓ Things like setting up environments, know, things that are like

I have to do this, but I wish it was faster so that I could get to the real work. And so as he began to tinker with this, this was before function calling was even available in the LLMs. And so this was quite the challenge to be able to do. And then when OpenAI released models with this capability, that was a game changer. And so he was able to build this internal tool called Goose.

And Goose is an AI agent and it was really, really cool. It was amazing. Engineers were blown away by what it could do. And of course they wanted to connect it to various systems that they interacted with. And so each of those connections was ⁓ basically you had to roll it in yourself. Like it was a one-off integration that you had to basically like code it up.

And ⁓ Bradley started thinking, man, I think we need some sort of protocol or something to be able to do this. And so he and a couple of other folks, they started thinking about what that might look like. They sent it over to our friends at Anthropic, who quickly responded, we already working on something. He showed us MCP spec.

before it was launched and we were like, oh, this is beautiful. This is exactly what we need. And we actually became one of the launch partners for MCP as far as the client. So when we talk about MCP, everybody thinks MCP service, but you know, there's clients too, right? And so we rebuilt Goose as an MCP.

client and ⁓ we launched it as an open source agent. We had been finding such ⁓ productivity gains internally. We decided to go ahead and open source it. And so ⁓ that was one of the first MCP clients ⁓ available.

Ankit Jain (06:53)
Very cool. So yes, I have also been following a little bit of Goose journey. Can you share a little bit about how is Goose compared to any other MCP clients? So for instance, if you will say like cloud code or even like a cloud desktop app, how do you see Goose fit into that picture?

Angie Jones (07:14)
What I think Goose's role in this picture, so by Goose being one of the first ones and also completely open source with the most permissible license out there, right? That invites the community to the table. And so what we see is the community now has an avenue to craft what they want a genetic AI to look like.

and they're able to contribute these features to the project. So Goose is typically the first agent with any given feature or pattern. Like it really is. And then we see the others adopt these patterns as well because the community has spoken, right? They've said, we want ⁓ sub-agents, we want repeatable workflows, we want to be able to show you eyes in the... ⁓

in the agent chat. Like these are things that community members have built inside of Goose and then others adopt this. And we love that. So we feel Goose's purpose, ⁓ one of course is to be used as is, but also it sets the stage in the trends of what agentic AI should look like. And we believe that should be open.

Ankit Jain (08:36)
It's amazing. So is Goose built for engineers or non-engineers? Are there different sort of like, know, verticals around how you approach Goose? Just share a little bit about like the adoption itself.

Angie Jones (08:50)
Yeah, so Goose was built as ⁓ an engineering tool. And when we launched it, it became like number one trending on GitHub. It was trending on Twitter, like a big deal, right? And so other people in our company, they saw this news and they're like, what is this tool?

And hey, we want an agent too. Can we use it? And because these agents, interface is just natural language chat, that makes it accessible to anyone. And so our other employees just naturally started picking it up.

and doing things with it, especially since there's MCP servers for just about everything. You know, I see a lot of discourse. I gotta write a blog post on this. It's on my to-do list about how, you know, developers, I see them on Twitter and things like that saying, I don't know about MCP. And that's because I believe they are not thinking big enough, right?

MCP is not just for engineers, right? MCP, like even if you think about APIs or anything like that, other people benefit from APIs who are not developers. They might not touch it. They might not even know it's there. And MCP is the same way. It's an implementation detail, right? So.

It's not just to serve developers, it's to connect their agents to the tools. And we saw this very quickly when everyone in the company, and I mean every department, marketing, finance, product, design, ⁓ customer service, executive assistants, like everybody was picking up Goose and they were requesting.

⁓ MCP servers for the tools that they interact with every day. Hey, I need goose to talk to Figma. I need goose to talk to Google docs. I need goose to talk to snowflake, you know, Jira and linear and Asana and all of the things. Right. And so, ⁓ we quickly realized like, Hey, this doesn't just have to be a developer tool. This actually could be a general purpose agent.

that anyone can find benefit with. And that's the beauty of MCP. Look at that. Without us doing anything, just because MCP exists, everyday people could take a developer agent and find use in it, right, for whatever their workflow is. And it's as simple as toggling on an MCP server that connects to theirs, right, or multiple MCP servers.

that they wouldn't have been able to do this before. Now you're integrating three or four applications in a single workflow and moving a whole lot quicker, right? And so ⁓ we saw this internally, the demand for MCP service skyrocketed. As you can imagine, so Block does financial services.

⁓ So we have a pretty sharp security team who was really freaked out about people just grabbing MCP servers off of random ⁓ people's GitHub repos. And so we decided to build our own MCP servers and we started building them for ⁓

the various use cases that our employees were requesting. And this all happened right around our internal hack week anyway. So we had developers who were outside of the Goose team and they'd been hearing all the buzz about MCP and they wanted to get involved as well. So people just jumped on and started cranking these MCP servers out. By the end of a week, we had 60 plus.

MCP servers now that's ⁓ doubled in number, but any application that we use internally, there's an MCP server for it available. So all of our employees are able to utilize ⁓ Goose or whatever tools. That's another beautiful thing about MCP is that it's agent agnostic. So even if they choose to use another ⁓ MCP client, they can still utilize these MCP servers that we build.

Ankit Jain (13:17)
Very cool. So ⁓ this brings us to also an interesting technical challenge. So ⁓ everyone knows using too many MCPs can also become a bottleneck and sometimes also reduce quality, because it takes up also your context window. How do you solve some of those technical challenges ⁓ at scale, especially if there's going to be a ⁓ crowd or a wave of new MCP tools being created?

How do we kind of like make it so that a system can actually handle these MCPs?

Angie Jones (13:51)
Yeah,

you know, we solved for this months ago and I see ⁓ companies ⁓ posting blog posts today about this, ⁓ we kind of solved the context problem with MCP servers and I chuckled to myself because, know, this is, again, the benefit of open source. You see these problems much earlier and you can solve them. But also of us using it internally at

scale, we were able to identify a lot of these issues months ago. Already the solutions already been implemented in Goose before the summer, right? So ⁓ yes, turning on all these MCP servers because at Block internally, we have our internal Goose, which is, ⁓ I strongly recommend companies kind of adopt this. Goose is open source.

just grab it, you don't have to pay us anything. And then ⁓ what you can do is set up like your kind of enterprise workplace configurations that work for your company. And so we have all of our MCP servers just automatically already installed in Goop. So every employee just already has these, they don't have to figure out how do I grab the JSON from an MCP service configuration and.

API keys and tokens and scope they don't have to do any of that It's already built in you toggle it on or your toggle it off. But of course Without knowing about all of this stuff You just turn everything on because I might need it who knows what what I'm gonna get into with my agent, right? I just turn it all on and of course, you know with all of those ⁓ tool descriptions being sent over to the LLM on every single ⁓ call

this was eating up the context window. And so we quickly did a solve for this where ⁓ we only, we use the LLM to determine like, what is the user asking for? We look at that configuration file and then we can just turn on or enable the servers that might be needed to complete their request versus having everything on all the time. And so that was our approach to it.

Ankit Jain (16:05)
Interesting.

Angie Jones (16:07)
Again, this this is all open source all of our code is out there and available so if anybody wants to implement that in Your agent or anything like that feel free to check it out in how we?

Ankit Jain (16:22)
Very cool. Is there like a governance aspect on these MCPs as well? Does it require some sort of like a process to for a person to ⁓ use an MCP in Goose?

Angie Jones (16:29)
Yeah.

Internally or just period? Yeah, internally, we do have a governance process. so we have a set of developers who are very familiar with MCP ⁓ as a spec, as well as good engineering practices who ⁓ needs to review, and then also someone from the security team. So those are the two gates that we have before we will

Ankit Jain (16:36)
internally.

Angie Jones (17:01)
⁓ Add an MCP server to this allow list that we have

Ankit Jain (17:06)
Very cool. Okay, so ⁓ switching gears a little bit, one of the things that come up very commonly in our conversations is just a tool overload, right? So everyone sort of like has their favorite tools, which means, and you know, every organization is trying to be AI-first which means that it is generally a little bit more liberal policies around like what tools people can use and not use. Obviously there is a bit of a security check, but other than that,

Angie Jones (17:24)
Yeah.

Ankit Jain (17:35)
the challenge becomes in most organizations is fragmentation and just like tools overload. How did you come up or like drive this strategy which helped you kind of like try to centralize a lot of adoption towards Goose or whatever other AI tools that you're using? How do you kind of like ensure it's not just we build the tool but like actually everyone is using it?

Angie Jones (17:58)
You know, I think it's much too early to place a bet on any horse. I really do. ⁓ like the, the landscape changes on a daily basis. Like might be this company winning a race today and then tomorrow, boom, somebody hits them with the big joke joker. And then everything changes. And so to be honest with you, we have not solved the tool overload problem. ⁓ my focus,

as someone who wants to enable our employees to utilize this stuff is to give them a toy box of choices. And what I do see is people naturally start a conversion towards maybe a certain one in groups, right? So for example, if we see our...

⁓ Android engineers, they have found that FireBender works really well for them, better than all of the other tools, right? And so they just naturally have decided this is the one that we would like to adopt, right? That's different for our iOS engineers and even for our backend or web engineers, right? So giving them that choice, I find really helps with adoption.

You know how engineers are you try to force something on them and all of a sudden they're very resistant to it versus you give them some options and let them choose what's best to solve their use cases and they'll they'll be more inclined to to give it a shot right and so that that's really helped I feel with adoption and So we just have a variety of these things at some point

I would love if this got narrowed down to one or two. But for now, I don't think we're in a position to make that.

Ankit Jain (19:52)
Interesting. There's also generally with many AI tools, bit of a learning curve cold start problem in some ways or sort of like maintenance problem. Can you share a little bit about maybe some of the challenges that you folks had in the early adoption of ⁓ Goose or other tools?

Angie Jones (20:09)
Yeah, yeah, exactly. It is a cold start problem. And so, ⁓ one of the teams under me is a developer relations team. And that came in so handy for this AI era because they were out teaching external engineers.

how to use Goose and a lot of the lessons that they teach apply to any coding agent, right? All of this stuff is kind of the same. do I basically efficiently use an AI agent in my workflow, right? That's what it boils down to. Pick whichever one you want, but the lessons kind of are the same. And so as we were doing that externally and Goose was, people were starting to use Goose internally.

There became a clear need that there we needed some training inside the house, right? And so ⁓ I had a couple of my ⁓ Developer relations engineers do internal dev rel for the company which was really interesting because Everyone was used to you know, I teach engineers This is what I teach, you know And so now you come inside and you're talking about CLIs and all of this stuff nearly. I don't know you

Yeah, so it was a really good lesson in like, okay, how do you just like talk in regular, plain language to help people understand this and how to use it. And so we did, we set up a couple of Slack channels. One was for help. So anyone can come in there if they're stuck and like, they can't figure out how to do something in Goose or anything like that.

somebody will jump in and help them. So my team jumps in sometimes, but ⁓ we're not a support desk or anything like that. And so the Goose team would jump in and just power users. Now it's like anybody will jump in and just help a fellow colleague get unstuck. But we also had an inspiration Slack channel where people can share the amazing cool things that they're doing and building. And when you see the sales guy post, hey, ⁓

I just processed 80,000 leads in a couple of minutes. This would have taken me all week. Exactly. You saw that? That's what everybody does. And so then all the sales peers go, wait, what? I better try this out. And then they start doing it too. Hey, bro, teach me how to do it. Or you see ⁓ someone say, I just went, had a meeting with the customer and they said they really want this feature. ⁓ They're not gonna buy unless they have this feature.

Ankit Jain (22:27)
you

Angie Jones (22:46)
On the train ride back home, I pulled Goose up. Goose is a local thing. You use Goose with a local model, you don't even need internet. know? They say, I prototype this feature for them. They were so excited. They had solved their customer's problem before they even needed to get to an engineering team, you know? And now, of course, the engineers will take that and harden it and stuff like that, but that really saved a lot of cycles of you needing to explain what the problem is and write a design doc.

and get it in the backlog and all of this. You've done most of the heavy lifting already.

Ankit Jain (23:23)
Very cool. So just to understand the journey a little bit, so when Goose was initially launched, it was mostly focused on engineers. But you're saying kind of like over time now, a lot of verticals, would say, departments in the organization have adopted it. ⁓ How does that play into the product roadmap of Goose? Is it sort of like some things where now you have different verticals? Is it like, OK, we're going to build these things for marketing teams, these things for sales teams?

Angie Jones (23:29)
Mm-hmm.

Yeah.

Ankit Jain (23:52)
⁓ And I know also it's open source, it's sort of like you just let the community drive all of those things. Share a little bit about how it is evolving.

Angie Jones (24:02)
You have really good instincts. tell you, because that definitely, that definitely was a challenge. ⁓ so remember I said this was Bradley accent, just a IC. This was not ⁓ a, anything that was on any product board to build. It just was an engineered tinkering and this thing exploded into a company wide product and also external open source project. Right. ⁓ and so.

When we decided to open source it, we had a small team that was dedicated to doing that work. you know, it was basically two open source groups. That was the goal. And so then you had everybody in the company using it. And now like the work, was just a lot, right? You're basically supporting a general purpose agent for the world internally and externally. And we had other things we wanted to build as well. Like we didn't plan to keep these

⁓ AI engineers like focused on this like that long, right? And so what we did was we made a dedicated ⁓ group of engineers to be focused on open source Goose We really value that open source project and we didn't want to just throw it out there and leave it unmaintained. So that group is ⁓ ring-fenced.

from the rest of the company and they kind of operate independently with their own independent budget and things like that. Because we don't want Block to, know, our goals to influence that project, right? And so we want them to kind of be independent and have their own agency. And so that's how that works. Internally, ⁓ we have expanded Goose to do other things. Now we have...

⁓ a dashboard of agents, if you will, like many Goose agents that everybody can use. So the interface has changed quite a bit internally where people just have these tiles that are like several agents that are running simultaneously and we can share these agents with their colleagues and they can have automated flows just running. Like basically you wake up and you go to your dashboard and has

a report ready for you for the day of what you should be focused on and things like that. And so that was a separate team, like kind of working more on ⁓ the automation for employees, right? And so that's a separate team and it's not limited to Goose. It's all sorts of AI enablement there. And so that's how we've approached it so far. Then of course we're building products as well. So we've launched Square AI, which ⁓

is built on top of the foundations of Goose. ⁓ And so now any seller now has AI in their seller dashboard so they can ask questions about their business and get insights, things like, hey, Thursday nights feel a little slow. What would happen to my business if I closed an hour earlier on Thursdays? And this agent

Ankit Jain (27:22)
Hmm.

Angie Jones (27:23)
assess metrics and things like that and say this how much money you would be losing if you did that, you know, and help these business owners make a sound decision, you know.

Ankit Jain (27:34)
Amazing. So it sounds like there's a big roadmap for even building this into the core square workflows. ⁓ How do you think about the success of all the things that you do? How do you measure ⁓ what's the expected outcome from all the efforts that you're doing? Are there specific goals? Are there specific ways to think about successful and not successful experiments?

Angie Jones (28:05)
Yeah. Um, and I'm glad you said experiments because that's exactly what it is. Um, you know, we're a pretty bold company that we've always pushed the needle on innovations. Like we're the ones that kind of led in the forefront of, uh, allowing any merchant to take payments. Like you're, you're doing a garage sale. Why can't you take credit cards? You know, that was us that introduced that feature, you know,

⁓ cash app and peer to peer payments and things like that. So we've always been about innovation and experimentation and AI is no different. And so we're definitely trying things out. We're seeing what's working. We fortunately have a wonderful foundation. We were privileged to learn early. You know, that's the good thing. When you do good, you get good. So by us very humbly.

and genuinely just wanting to contribute Goose as an open source project with no arterial motives. We got so much insight into how people use agentic frameworks, what they want out of it, what frustrates them. And we were able to take a lot of that insight, especially on internal users, because now you have a broad spectrum, not just engineers.

a broad spectrum of people using these tools and we'll be able to take those lessons and apply them to the new stuff that we're building. So we feel pretty confident.

Ankit Jain (29:36)
Awesome. So kind of like becoming a little bit towards the end of it, but I would want to at least understand all these organizations who are trying to get better AI adoption internally. Do you have any recommendations from your experience getting kind of like Goos or like other products adopted internally? How should these platform leaders in these organizations approach this in some ways, AI transformation?

Angie Jones (30:01)
Yeah, ⁓ you know, I'm doing a lot of work now with our engineers now we got everybody else set up now I want to push our engineers like what is the next level? How do we get you outside of your IDE and applying AI into all of the other areas of software engineering and so ⁓ I've stood up a AI champions group that's of 50 engineers now we have thousands of repositories in block

⁓ and so, ⁓ I can't take them all on, but I strategically picked 50 people where their efforts will affect about 60 % of those repos. And in doing that, I'm, we're experimenting. this is part-time work for them. They still have to do their day job, but they dedicate 30 % of their time to AI enablement work and experimenting, trying things out and figuring out.

how to utilize these non-determinational tools and things like CI and PR reviews and things like that. We are doing some amazing things and that brings everybody else along. For example, something that we just had recently is where we're able to tag Goose on like a Jira or a linear ticket and just say, just assign Goose. You just assign it to Goose. So we had a sprint team that tried this out.

And it was a three week sprint. After the first week, they were done with all of their work. And so they were like, whoa, we got to pull more work in. So they pulled more work in. know, the engineers are taking the heavy, meatier, riskier task. But those things that are pretty straightforward to do, assigned it to Goose. Goose did those too. A second time.

They were done. They had to pull in more work. This is developer velocity. We are changing how we do software engineering now. And so I want to roll that out to the entire company ⁓ next year, probably Q1. ⁓ But yeah, these are the types of things that we're doing. And that enables everybody, again, not just the engineering team, but the product teams and things as well.

Ankit Jain (32:23)
Very cool. So you're saying in some ways, like find the champions and kind of like have them sort of like lead these specifically vertical experiments.

Angie Jones (32:28)
I think we have to, I think we have

to, it's going to be too hard to uplift everyone at the same time. What you need to do is find a core group of people who are willing to dedicate and who won't be discouraged by the failures. Some things are going to fail, right? They have to learn lessons and see why is it failing? And are there things I can do, like maybe use AI rules in my repo or better describe my task in linear or things like that?

to help the agents help you. And once people see the benefit, then they naturally will adopt.

Ankit Jain (33:06)
Amazing. So maybe sort of like last question then, NJ, what's next? Like kind of like, what are some of your maybe even predictions for the software industry in 2026? And like, what are you thinking about next in Goose?

Angie Jones (33:19)
Yeah, I try not to make prediction easy. I used to be a prediction girly, but I mean, things are moving so fast. What I will tell you is the early trend that I'm seeing is that for the last couple of years, I feel like junior engineers were kind of, can't take you on right now. And now there's a demand for them. I in fact have ⁓ posted, Block has launched ⁓ a builder fellowship for

entry level ⁓ builders. With these AI tools, anything is possible. I don't care about on the application. I don't ask for your resume. I don't ask for your educational background. Give me your portfolio, some links to your projects that you built with AI tools. And that's how we're assessing people. So we're going to start this and ⁓ bring them on in January about 10 fellows just to kind of pilot the program. But I want to do that.

throughout the year. So expect to see like more builders kind of joining the workforce there. As far as Goose, ⁓ we are continuing with ⁓ our building. We've started a grant program where we're encouraging people to contribute back to the project, maybe some wow, innovative ideas, like really push the needle. We'll give you a hundred thousand dollar grant for the year to work on this stuff.

And so it's been really exciting being in this space. I think I'm having the most fun I've had in my career, I must say.

Ankit Jain (34:52)
That's amazing and very inspiring also. ⁓ Thank you so much, Angie, for this amazing conversation. I'm sure a lot of people will learn a lot of things from this. And I will also link your ⁓ blocks ⁓ fellowship ⁓ stuff in the footnotes so people can find it and apply. ⁓ And yeah, again, thank you so much for your time. And thank you for the listeners. If you're interested in developer experience or work in DevOps platform teams, join us as HangarDX. do a

Angie Jones (35:05)
Thank you.

Ankit Jain (35:21)
virtual sessions, as well as invite people like Angie for these podcasts. And you can always find us on aviator.co slash podcast. Again, until next time, have a great day. Thank you, Angie. Thanks for your time.

Angie Jones (35:32)
Thank you.