Alyssa and Chanda share stories and mental frameworks about how to strategically think about and accelerate your career journey. You’ll hear examples of how to navigate between large and small companies, how to level the playing field by strategically leveraging emerging tech fields, intentionally harnessing skip-level managers, and establishing a growth mindset.
Alyssa Henry is the Seller Lead at Square, which creates tools that help sellers start, run, and grow their businesses. She leads product management, design, and engineering for Square’s seller- and developer-facing products. Alyssa has been integral to shifting Square from a single app focused on payment processing into a broad financial services platform and commerce ecosystem that serves the complex needs of verticals from restaurants to retail. Prior to joining Square in 2014, she previously served as VP of Amazon Web Services (AWS) Storage Services and Product Unit Manager for Microsoft SQL Server Data Access.
People want to work on something that matters, something where they’re growing and learning. Autonomy, mastery & purpose resonates with everyone.
- Alyssa Henry
She is currently the VP Engineering at NodeSource, bringing 20+ years experience leading Engineering and Product teams with a strong focus on emerging trends and new technologies. With a solid mix of both global corporate and startup experience, Dharap has a proven track record of excellence, most recently in the Node.js ecosystem, leading cross-functional efforts around solutions to drive the API economy. Prior to joining NodeSource, she held a product leadership role at Adobe, where she was responsible for the vision and technical direction of a next-generation search platform for Adobe’s cloud ecosystem. Dharap holds a Master's and a Ph.D. in Computer Science from Pennsylvania State University and has also earned a certificate in Strategic Decision and Risk Management from Stanford University’s Center for Professional Development.
So this is really cool, you know? It's the first time I'm here, I've always been used to Hackathons and meetups that are related to actually hands-on. And I've always missed this, you know? Which is talking to other engineering managers and leaders and people who are aspiring to be managers and engineering figures. So this is really cool.
Generally, when you do panels, they give you this little bio and you go off and you figure out who the person is that you're talking to and then no need to 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. And now you're gonna get a lot of hits on your LinkedIn profile.
But she and I share a little bit of similarity. We both have a Bachelors's in Mathematics and that's pretty cool. And we both programmed a long time ago in Cobol and Fortran, and all of the age-old beginnings of computer science languages. And then I looked at her work experience with... 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, I'm just blown away. She's my hero from now on. And so Alyssa is now at Square and she's a leading... She's a lead seller at... It's a GM role the way I understand it and leads a gross functional team of engineers and product managers and design, sellers, you know? 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 wanna 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 it's 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 and payments or whether it's storage and compute. That helps anyone really get started to 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 Oracle licenses. And so you really didn't have a broad range of people participating in or starting tech companies. And that just really exploded with AWS. And with Square it's the same thing, how do we give the, you know, from the smallest businesses to the largest businesses but really focusing on the small, the new entrepreneurs.
How do we give them the tools to effectively compete against the Amazon's of the world and the large companies in commerce.
Certainly interesting. So can you talk a little bit... I've always gone from 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. So what was it like? You know, zooming out into a smaller company from 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 3000 people with probably 2000 of those people be working in fulfillment centers. And so actually pretty small from a corporate perspective and from an RND 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 1000 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 sort of new formation but I also like the process of scaling. And so it's kind of that adolescent phase where there's something 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.
That's actually an interesting part of doing management and for the audience, right? Maybe you can talk a little bit about how one of the challenges there, for example, I've always done engineering and then had a 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 the engineering half the time, in my experience. So how do you do that? What were some of the things that helped you?
Again, I've had kind of a funny path. I started up my career as an engineer and did that for several years, a number of years. And then into engineering management and then I moved from a engineer management into PM. But when I moved into PM, it was working on developer tools. And so working on Microsoft back in the day and all of the data access stack and sequel server. And so while I was working in product, it was still a very technical product and my customers were developers and working fairly low in the stack. This allowed me to stay technical, then moved into managing, product management. And then into general management and so managing 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 move back into engineering management from a 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'd not done before. And figuring out how to hire someone, I knew I was in incompetent in that area. I'd never run large scale services, I didn't know anything about operation/SRE I think some of the companies call it. And so hiring a really great leader that can effectively teach me their function. So that was a real kind of key skill to learn. And then at Square, I have a range of functions from sales to customer support to design to engineering but then 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 UI was a new thing for me.
Correct, yeah. That's very interesting. So in that, just shifting tracks a little bit, about the team itself. What were your... How did you grow a team? Can you talk about what are some of the things you did to grow your team, maybe hiding it, maybe other... Did you bring in coaches? Did you bring in people who understood process? Or did you have the team organically grow? 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. Growing culture, team, they all kind of go together 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 as much as possible, how do you figure out how to enable and 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 cultural perspective, from how do we go higher, you know. What should hiring buyer look like? What should our... At Square, we had helped bring folks together across engineering, across the company to define what should the engineering career level... What should the ladders be? How do we want to reinforce that? How do we... In our promotion 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 start-up, right? Well at that time a small company, you would have to have more than processing, more grassroots type of approach to hiring as well, right? Did you do any such things at all? Like we... When I did the 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 kinda scaled at that point. So we have a great talent team--
Who helped with some of that but ultimately the best recruiting comes from hiring managers and the team themselves being involved in it.
So in terms of growing so that you... 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 of the things that people should look out for in order that they grow in the direction that they want to. You know, career development.
I think particularly in this industry, constantly learning is critical. 'Cause 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 and 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, continue to do that. And also I like to work on kind of a... The edge of where tech is going because then you learn through your job.
But I'll also say that one of the great things about the fact that tech is kinda 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 the 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 kinda get on, same with Cloud and a bunch of these new trends, if you're an early 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.
So that's interesting from the technology perspective and growing your understanding of technology, keeping current. But what about the team itself? It's one thing managing 30 people versus managing I don't even know how many that you are. Did you get any help along the way? Any mentorship maybe? Your peers in the community, anything like that?
You can learn from everyone, right? And so like I've 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 Wilke 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, from his perspective.
So I think you really... 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 wanna retrace something that Alyssa you've said about skip level because I've noticed when I have been in larger companies and I've 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 the skip levels and if you don't have skip levels in your own company because it's small, look outside. Look at leaders outside and connect up with Alyssa. Because it's actually really an ear full 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 the order of 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 two? I spent 20 years at tech in Seattle and Venture Capital's pretty much not a thing in Seattle. It's growing a little bit now but pretty much not a thing in the way that it is down here. And this area is really the heart of tech and I wanted to learn about that. I'm not getting any younger, I've never done a start-up 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 gonna be any good at this, I don't know if I'm gonna be successful but I'll try. The same thing when I went from Microsoft to Amazon, kinda crazy that Amazon hired me to run initially all the order processing. So when you click buy on the cart of the systems that did that, I'd never run a service before. I'd never operated the 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'm either gonna do okay, I'm gonna learn a ton or I'm gonna fail and I'm gonna learn a ton and I'm okay with that risk.
Interesting. So that's like another takeaway, right? Take risks. Take risks where you can. Cool. We are at... If you have questions this is the time. So question from the... I cannot read the name, it's too small here. Oh, okay. When should product engineering be in the same organization versus different ones? Interesting.
Well I mean at some level they are always in the same organization 'cause it's the same company, right? So it's just a matter of where... 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... You'll have a, you know, CTO and a CPO or something like that, right? 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 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 were organized with more of a general managing 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. And then the... Well, we answered the first one. The next one was, as you've seen several companies grow at hyper-scale, are there any lessons that you can share with us?
Hyper scale's fun, growing was fun. I always go back, I worked a lot in distributed systems. Organizations are distributed systems, so the way I think about those 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 yesterdays... And whether that monolith is a monolithic organization or 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? And again, it's whether it's teams or code.
Yeah. I love that, cell divide, I'm gonna use it. So can you... The next question is anonymous, how do you retain core members of a team? In particular the .
Yeah. People wanna 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 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 interests so that they can bring greater purpose to their work. But it's really kind of thinking through those things.
Thank you all.