Zooming Out From Engineering with Square's Alyssa Henry | Greymatter

This episode of Gray Matter is in partnership with sfelc, a curated community of engineering leaders working to evolve the way leadership is implemented in the tech industry. At the annual SF ELC Summit, Square's Alyssa Henry and Node Source's Chandra Dharup discuss managing cross functional teams and learning lessons from growing teams at Hyperscale.

Our next session features two amazing leaders in their own right. The topic is zooming out from engineering. We are featuring Alyssa Henry and Chanda Dharup. I have the pleasure of introducing to you the moderator for this panel, Chanda Dharup. Chanda is a VP of Engineering at Node Source. She brings 20 plus years of experience leading engineers and product teams specifically focused around emerging trends and and developing technology. She brings a robust mix of global, corporate and startup experience to this conversation. So please join me in welcoming our moderator for this conversation, Chandodhara.

Thank you, Patrick. So this is really cool. You know, it's the first time I'm here in a. I've always been used to hackathons and meetups that are related to actually hands on and I've always missed the this which is talking to other engineering managers and leaders and people who are aspiring to be managers and engineering leaders. So generally when you do panels they give you this little bio and then you go off and you dutifully figure out who the person is that you're talking to and then read a little blurb about them. But I went off of the Bio, I went LinkedIn and I looked at Alyssa's experience and I have to say this has just been amazing just reading her LinkedIn profile. But she and I share a little bit of similarity. We both have a bachelor's in mathematics and that's pretty cool. And we both programmed a long time ago in COBOL and Fortran and you know, all those age old, you know, beginnings of computer science languages. And then I looked at her work experience. She worked for a decade at one of the largest companies, Microsoft, and then she went on to Amazon AWS Storage Services and you know, responsible for AWS Lambda. And I'm just like blown away. And Elissa is now at School Square and leads a Cross functional team of engineers and product managers and design sellers. And I'm going to let her talk a little bit about Square and for the audience who may. I mean I hope there's nobody that doesn't know Square, but in case you want to talk a little bit about Square itself and your move there.

Sure, yeah. So at Square we're helping entrepreneurs, in this case non tech Entrepreneurs start and grow businesses. And for me it's kind of an evolution or the next step from what I was doing at aws, where AWS was helping entrepreneurs, but tech entrepreneurs and really kind of two sides of the same coin. Excited about it though, because I do believe that in both cases, part of how we move forward as a country, even as a world, is helping entrepreneurs start new businesses. It's where job growth and creation comes from, is the start of new companies and then providing folks tools, whether they're point of sale on payments or whether it's storage and compute that helps anyone really get started and grow. Prior to aws, if you weren't pretty much a white guy down here in the valley with access to vc, you couldn't start a tech company because it was way too expensive to get going and you had to buy your sun servers and your Colospace and your Oracle licenses. So. So you really didn't have a broad range of people participating in starting tech companies. And that just really exploded. With AWS and with Square, it's the same thing from the smallest businesses to the largest businesses, but really focusing on the small and the new entrepreneurs. How do we give them the tools to effectively compete against the Amazons of the world and the large companies in commerce?

Interesting. So I've always gone from like small companies to big companies and then back again to small companies like Boomerang back to the small company. But I think your journey has been really interesting. Zooming out into a smaller company, coming from larger companies. What was that experience like? What was challenging about that transition and what were some of the things that you found on the ground?

Yeah, so my career transitions have always been from kind of larger, older into smaller and younger. So I was at Microsoft from 94 to 2006. It was still pretty, not all that big and still kind of scrappy back in 94 when I joined, kind of less so by 2006. We'd been declared a monopoly by then. And then when I joined Amazon in 2006, I think it was a sum total of about 3,000 people with probably 2,000 of those people working in fulfillment centers. And so actually pretty small from a corporate perspective and from an R and D perspective, by the time I Left there in 2014, it was a much, much larger company and has grown from there since. When I joined Square, it was about 1,000 people. We're now probably about the size that Amazon was when I joined. But it's been interesting, that progression. I like the agility that you get in new Formation, but I also like the process of scaling. And so it's kind of that adolescent phase where there's something that's sort of going, but it's still messy and sloppy and you're figuring out how to scale the code, scale the organization. Those two often go together and make it all work.

Actually, that's the interesting part of doing management. And for the audience, maybe you can talk a little bit about what are the challenges there. For example, I've always run engineering and then short stint in product management. But you've had a fantastic experience of real cross functional teams. How do you go from running engineering to running a team that is really cross functional with designers who are a completely different sort of mindset and product managers who are completely at odds with engineering half the time in my experience. So how do you do that? What were some of the things that helped you?

Again, I had kind of a funny path. I started my career as an engineer and did that for several years, number of years and then into engineering management and then I moved from engineering management into pm. But when I moved into PM it was working on developer tools and so working on Microsoft back in the day, but ADO and XML and ODBC and all of the kind of the data access stack and SQL Server. And so while I was working in sort of product, it was still very technical product and my customers were developers and working fairly low in the stack which allowed me to stay technical. Then moved into managing product management and then into general management. And so managing at the time test and PM and engineering, having had the background in two of those three as an IC but not in the third and then figuring out how to learn how to do that. Then moved back into engineering management from kind of a general management role when I moved to Amazon and then actually back into a general management role when I moved to AWS early on. But then that was interesting because I had operations as a new discipline which I had not done before and figuring out how to hire someone. I knew I was incompetent in that area. I had never run large scale services. I didn't know anything about operations SRE I think some of the companies call it. And so hiring a really great leader that could effectively teach me their function. So that was a real key skill to learn. And then at Square I have a range of functions from sales to customer support to design to engineering. But again it's the same thing. Figure out how you can find great people that can help teach you and then give them the space to do that and Respect the skill sets that they bring. Certainly design was a blind spot for me as well when I started at Square, because I'd always worked on API developer tools and where the UX was an API, not a ui. And so learning a UI was a new thing for me.

Correct. Yeah. That's very interesting. So in that just shifting tracks a little bit about team itself, like, how did you grow team? Can you talk a little bit about what are some of the things you did to grow your team? It may be hiring, it may be other. Did you bring in coaches, did you bring in people who understood process? Or did you have the team organically grow process? What were some of the things that maybe aspiring engineering leaders can take from your experiences?

Well, it's been different every place I've been. The growing culture team, they all kind of go together. And depending on what phase your product's in and what kind of industry you're in and what the culture of the company is, dictates some. So I don't know that there's a single kind of rule on this, but I will say that you know as much as possible. How do you enable folks within the team to help you build not only the product and the code, but have the team help build the team from a culture perspective, from a, you know, how do we go hire? What should hiring buyer look like? What should our. Where we had helped bring folks together across engineering, across the company, to define, well, what should the engineering career level look like, what should the ladders be? How do we want to reinforce that in our promo processes, how do we want to hire for those sorts of things? And I think as much as you can get a broad range of folks with a broad range of perspectives to collaborate on that, together you can build something great where you're building the company and the team, not just building the code.

Being a startup at that time, a small company, you would have to have more than process, like more grassroots type of approach to hiring as well. Right. Did you do any such things at all? When I did this at Strong Loop long time ago, we did a lot of hackathons and that was also not just to educate the community, but to attract talent. So things like that?

Well, I think Square was a little further along and kind of scaled that point. So we have a great talent team who helps with some of that. But ultimately the best recruiting comes from hiring managers and the team selves being involved in it.

So in terms of growing. So I've talked about growing the team and what are some of the approaches you've used in the past. What about growing yourself, your career, your path? Your path has been really fascinating to me. At least maybe you can talk a little bit. What are some other things that people should look out for in order that they grow in the direction that they want to? Career development?

Well, I think particularly in this industry, kind of constantly learning is critical. I started my career COBOL on the mainframe and worked with a bunch of people who had been doing the same thing for 20 years, basically had never learned and were rapidly becoming incredibly obsolete. And so learned early on that in this industry bad things happen if you don't stay current. And so I make sure to spend time continuing to do that. And also I like to work on kind of the edge of where tech is going, because then you learn through your job. I'll also say that one of the great things about the fact that tech is kind of constantly changing and constantly turning over is that it actually, in many ways is great if you're an underrepresented person in tech. Because on the day that iPhone launched and mobile iOS apps were a thing, there was nobody. It leveled the playing field. No one had experience in that. And so if you spot these things and you can kind of get on same with cloud and a bunch of these new trends, if you're an earlier adopter of them, you can quickly be a leading expert in the industry in a way that you can't necessarily in other industries where it's constantly just an evolution from where you've been.

Yep. So that's interesting from the technology perspective and growing your understanding of technology, keeping current. But what about team itself? It's like one thing. Managing 13 people versus managing. I don't even know how many you know that you are. Did you get any help along the way? Any mentorship, maybe in your peers in the community?

Anything like that, you can learn from everyone. Right. And so I've had, like I said, I've had people in my team that have taught me things about what they're experts in. I've had peers that have taught me things. I've had some great skip level managers. I learned a ton. And direct managers. I learned a ton from Andy Jassy at aws. He spent a lot of time with me as well as Jeff, Jeff Wilkie on the retail side. He was my original skip manager there. Learned a ton. Jack's been incredible in terms of teaching me a whole bunch of things that I really didn't understand at all and from his perspective. So I think you can learn from everyone around you. And I think it's just having a growth mindset and figuring out who has what skills in what areas and can teach you something. And I encourage that throughout the team.

I want to reiterate something that, Alyssa, you've said about skip level, because I've noticed when I have been in larger companies and have had the opportunity to think about skip levels for my directs, people don't take advantage of it as much as they should and do. I would encourage all of you to take advantage of skip levels. And if you don't have skip levels in your own company because it's small, look outside, look at leaders outside. Connect up with Alyssa because it's actually really useful to understand how people grow in their careers. It changes your perspective. So another question I had for you was, when you made these transitions, right, from Microsoft to Amazon AWS and then to Square, what are the kinds of things you looked for in you? What are the kind of things that attracted you to the next phase?

It's different, but I'm always looking at what can I learn and then what can I contribute and how do I balance those 2? I spent 20 years in tech in Seattle, and venture capital is pretty much not a thing in Seattle.

It's.

It's growing a little bit now, but pretty much not a thing in the way that it is down here. This area is really the heart of tech, and I wanted to learn about that. So I'm like, oh, you know, I'm not getting any younger. I've never done a startup or pre IPO company. I don't know what venture looks like, any of that. And so that was one of the things that made me kind of go, okay, gosh, maybe I should go and try this and give it a shot and take the risk. I'm like, I don't know if I'm going to be any good at this. I don't know if I'm going to be successful, but I'll try the same thing. When I went from Microsoft to Amazon, kind of crazy that Amazon hired me to run initially all the order processing. So when you click Buy on the cart, all the systems that did that, I'd never run a service before. I'd never operated a darn thing. And I was now in charge of running a service and building the code and operating basically the core revenue pipeline for the company. I mean, they're going to do okay. I'm going to learn a ton or I'm going to fail and I'm going to learn a ton and I'm okay with that. Risk.

Risk taking. So that's like another takeaway. Right? Take risks. Cool. If you have questions, this is the time. When should product and engineering be in the same organization versus different ones? Interesting.

Well, I mean, at some level, they're always in the same organization because it's the same company. Right. So it's just a matter of at what point do they meet within the hierarchy of a company? And I think it depends. There are a number of things to look at. If your company has one and only one product and everyone's working on the same thing, most likely they'll meet kind of at the C level underneath the CTO and a CPO or something like that. Product and engineering together under the CEO, because everyone's kind of working on the one thing, and the CEO is in effect, the general manager for the product overall. In a business like Square or AWS was where there's a large amount of products and individual businesses where each individual thing you can go find companies that do only that one thing. Both Square and AWS was organized with more of a general management structure where you push that down the organization. So you get product and engineering coming together lower down the organization, which just helps you move faster and reduces the organizational distance between those two functions for the product.

Thank you. So the next one was. As you've seen several companies grow at Hyperscale. Are there any lessons that you can share with us?

Hyperscale is fun. Growing is fun. I always go back. I worked a lot in distributed systems. Organizations are distributed systems. So the way I think about both organizations and code is from that lens. And in that perspective, it's about. You're kind of constantly figuring out, how do I kind of do cell divides, if you will? How do I take this one thing that is today's monolith that was yesterday's, and whether that monolith is a monolithic organization or a monolithic code base, how do you start to decompose and break it apart so that you can get stronger boundaries between it and the ability to iterate, whether it's between the organization or the code, in a way that you can make changes that don't ripple through everything else and you can reason about them independently against whether it's teams or technical.

I love that self divide. I'm going to use it. The next question is, how do you retain core members of a team in particular? There's such a high turnover in the behavior.

Yeah. People want to work on something that matters, something where they're growing and learning, autonomy, mastery and purpose, I think resonates with everyone. And so as a leader and as a manager, you're kind of constantly looking at how do I make sure that the folks in the team have sufficient autonomy, mastery and purpose in the work that they're doing such that they're engaged and love what they're doing? And sometimes it's like pushing someone to grow further. Sometimes it's looking at how do I align the work with the interest so that they can bring greater purpose to their work. But it's really kind of thinking through those things. Thank you all.