Marqeta Dev AMA: How to Scale During Hyper Growth - Community Event

[Ricardo]

Scaling engineering teams is notoriously difficult to do well. As organizations grow, the things that worked in the past soon become unfit. In the forum below, ask our panelists of engineering team leaders what you'd like to know about the lessons Marqeta has learned along the way.

Tune in on 8/5 12pm PST to hear them answer these questions live. They'll share their experiences on how to take your tech, processes, hiring, and culture to the next level. 💻

AMA Panel:

• Femi Alashi
• Chuck McIntyre
• Ian Chesal
• Judy Tsui
• Neha Chriss

So, how does the event work?

1. If you don't have a Marqeta Developer Community account, yet, register for an account
2. To join the live session either Post a Question below or Subscribe to this thread before August 5th at 12 PM PT and you'll be notified of the details (plus get a gift card to enjoy lunch on us).
3. On August 5th at 12 PM PT, navigate back to this post to find the Zoom link and join the Marqeta team
4. Once the event has started, open this thread and if you haven't yet post your questions. The team will answer questions as they come in.
5. Once the event is over, the thread will be locked, which means that no new questions can be posted. However, anyone will still be able to see the questions and answers from the event.

Some things to keep in mind:

1. The Community Guidelines still apply, so keep your comments polite.
2. Clear and detailed questions are more likely to receive a useful response, so try to be specific in what you are asking.
3. While the team will make an effort to answer all questions, time constraints and company policies may prevent some questions from being answered. Questions that are out of scope: onboarding troubleshooting questions and support escalations

Pretty simple, right? Make sure to subscribe to this thread to be notified of any new posts, including the AMA thread. 🔔 Simply click on the "Options" link at the top right of this page.

Excited about the event? Any AMAs you would like to see? Share your thoughts below. We'll see you Thursday, August 5th!

[jc_paymentsdev]

What are your thoughts on the relationship between engineering and product during hyper growth? What things will change and how have you managed?

[Judy]

@jc_paymentsdev  I think really continuing to keep open communication will help. Making sure that we talk on a day to day basis, we're sharing the same vision, we're sharing the same goal and same process. Actually having this will really help in terms of the relationship between product and engineering teams.

To answer your second question, while every growing company goes through hyper growth, not one is exactly like the other, so you can't really say what you're going to expect. But what you can do is, always talk about what are the trade offs from a user impact perspective, business impact perspective or  scaling perspective. One of the things that really changed from having a couple of people talking about something  to having a group of folks talking about it, was we really started clearly articulating, in some type of shared form of documentations. So you could then discuss, share that knowledge and spread it to a greater team, depending on how large your team size is.

[Femi]

Alignment and capacity planning. You need to align especially when two parties are trying to figure out how to scale the product and how to improve the capacity of this product. We know you can't really fully plan, but you can leave space out for any requests that might come. That's how we are currently managing hyper-growth.

[Neha]

I would just add that something to think about is the tightrope walk of hyper-growth in security engineering and that space can be very, very complicated. There are times where we have to really do a lot of deliberation.

So for us, communication is really important for product roadmaps, to really understand where products are actually trying to go with the vision is really important. That way we can create risk consciousness and we can sort of encourage our product engineers and our product folks to think in terms of risk going forward.

[jrhoades]

How do you navigate organizational structure change? As growth occurs, roles and responsibilities often get more specified and tiered. People become team leads and the like when there was never such formal structure before. How do you maintain clear communication, responsibility delineation, and team culture throughout that process?

[Ian_Chesal]

@jrhoades...some of it is letting go of things. Culture is an interesting one to have on here because culture is hyper local, but also very global to a company. You've got a top down culture that's going to come from the C-suite, that informs how people act. But, there's always pockets of culture within the teams. As the company grows, you have to accept that there's going to be some modification of culture. So you have to think, from the top down as a director or as a VP, what are the most important cultural aspects I want all my teams to carry? And it can't be complex, it can't be a myriad of things. What are the two or three very clear cultural aspects I want all my teams to carry? Make sure your managers know about those and then have them carry those to the teams. Then let go of the fact that all the other types of culture that's going to develop within those teams are out of your control. Don't try and manage that to any degree or it's going to fail. 

Within my work, there's a transparency culture that I value. We talk in the open about everything we do, we share notes about everything we do. It should be very clear to know what my teams are up to at any point in time for anybody in the company. There's a retrospective and introspective culture that I try and promote, where on a regular cadence teams ask each other and ask themselves "What do we do that we don't like that we need to change?" "How are we operating in a way that we think is good that we want to reinforce?" And, "what should we be doing differently?" Those two things are really the things I try and uphold. 

When it comes to people changing roles and growth, you have to accept that some people are going to want bigger roles. You find those people and develop that talent and coach that talent but also accept that there's risk in doing that. So if someone wants to try on management, how can you let them do that in a way that they can go and do it and if they fail, they can come back to doing a job that they were much better at. If you can get that right, you can at least give people a chance to try and grow, and do roles that the organization is starting to need that they didn't need six months ago or 12 months ago, in a way that's safe for them and their careers, and helps them develop new skill sets.

-Ian 

[Neha]

I would add, the idea that you will maintain culture, always has to be considered carefully. Culture evolves, always.

So the idea that you're going to keep the same culture...you're never really done with navigating it. These are things that you don't solve once and forever. You often have to constantly be retooling, reconsidering and evaluating where your team is and what is hindering or enhancing your organizational structure's success?

[Nicolas_S]

In addition to @jc_paymentsdev and @jrhoades., my AMA questions are:

1. Which are the main challenges for scaling culture? How can you deal with them?
2. How do you establish a reliable methodology for group decision-making so your team can reliably make the best call for the business — while still allowing everyone to feel heard and valued?

[Femi]

@Nicolas_S  Culture changes, it's an ongoing change. There's the culture when you have 25 to 50 people on an engineering team, or the company will be different from when you were like a 100 to 500 employee company. As long as we can ensure that engineers and ICs and the company are aware that culture is an ongoing task that we need to continue to change, improve on, at every stage of the company, that will make things easier.

[scm]

Reliable methodology, this is something we spent a lot of time on. I think the most important thing here, if you're going to make a group decision to begin with, it's to write down a problem statement and the definition of terms. A lot of times what happens is, you hear a thing. And what I hear is very different from what you might hear...so getting to that shared problem statement first with those definitions of terms, allows a lot of that to fall away and make sure that everyone is talking about the same thing. That can be challenging in and of itself, so you still need a mechanism for doing this and we have a number of internal processes around how to write problems, how to write decisions, that have evolved over time and are continuing to evolve. But if you don't get that right, you're not going to get the decision right. You won't even be able to reliably measure anything right. 

This is where you can make everyone feel valued, since you've written down the problem statement that you've all agreed on. Now, call for options...'what can we do here?' 'help me weigh these things,' 'this is what we're thinking about,' 'this is what we're leaning towards', 'this is why'.

You should do progressive levels of brainstorming, drafting, revisiting, because if you invite everyone at once, when it's unformed, you're going to get 10,000 different opinions, you'll have a document that's 33 options long and you can't make any progress, so you need to do that in a sort of progressive fashion. You roll it out to a couple of people, you roll it out to a couple more people. Ideally, you find the people who you are least likely to agree with, and get them to comment on your doc right and say what you've missed.

[Neha]

I would say creating space for divergent and convergent thinking is important, there are naturally and organically places where people are going to diverge, they're going to have different means or ways of approaching a problem. They may have differences in how they even sense a problem.

One thing that we have talked about quite a bit in product security is "sense-making," and developing sense-making culture. Really condense it down to to the finer points. The sense-making culture is one in which we are we are regularly and consistently probing individuals and the team collectively for the state of opinions, that there's a set of senses that everyone's working with. To never really make the mistake that some of us are more objective and some of us are not, but actually that we're all mostly subjective and as a result have to synthesize, that there's a synthesis that needs to happen and being really deliberate, when that synthesis occurs.

This is a hard problem, it's non trivial, and the sooner you recognize that the better.

[thiyagu_by]

1. What metrics do you follow to decide that a team needs scaling up? Is it directly related to the revenue growth of a company?
2. There are many types of Organizational structures, How do you decide which suits best for a company?

[scm]

@thiyagu_by I think these questions are inextricably related. 

When it comes down to it, the way you spend your engineering resources, is what you're going to build. And you can't have too many things, because if you have too many things you're just spread too thin. People can't do anything, there's sort of a minimum size of an effective team. That's something Marqeta is in the process of learning and readjusting continuously, we're going through some changes right now specifically in this area.

Team growth becomes an efficiency drain. You have too many people in the same team, you get all of these very complex human behavioral things happening. We're talking about distributing the work that the business wants to do and the way to think about that is in terms of Team units. The way to know that you need a different team is when your problem statement, your team charter becomes too big. If you know the one thing that I'm supposed to do this quarter and my team is supposed to do this quarter, that's a good sign, that means I have autonomy in that area, I can reliably iterate on that project and so on. If you don't, that's a pretty good sign that the team's either too big or just not valued enough by the business, one of those two things can be true, and if you're in either of those situations, you should get clarity. 

To answer your second question, I don't think there's an ideal. Recently @Neha reminded me that there's no such thing as a best practice, there are collections of related good practices. Human interaction is very, very complex and what is best suited for a company this week, may be different next week. So what you have to do is come up with measurements that mean something to you and what you do and what your mission is.

At Marqeta, we talk about building for builders. You, the developer community, we build for the developer community. But what do we want as builders? We want developer velocity, we want teams to be able to make a decision to do something on their own, and to do it and then make progress on that, iterative fast progress. So when you don't have that, when your team is continually running into roadblocks because they're waiting on another team, or you know when a lot of teams are that way or they can't seem to make progress...I think that's the time to think about a different organizational structure.

[Ian_Chesal]

@thiyagu_by  I do like tying what you do as a team and organization back to the success of the company. That doesn't necessarily have to be revenue growth, there are ways to make a company successful without just directly tying it to business dollars that are earned for the company by doing work. But I think it's important to connect teams to that top level, "what does success look like for the company?"

Whether it's growth in revenue, cost savings, preservation of growth through security and enhancing the stability of your platforms. If you miss that or don't do that, teams will float and they'll tend to feel like they don't do something that's valued by the company. So as a leader, as a manager, I do try and make that happen as much as I possibly can.

-Ian