Moving from Project to Product with Sejal Amin

[adinserter name=”PM Leadership Series Connector”]
Sejal Amin is the newly-named Chief Technology Officer at Shutterstock, where she has a broad mandate to drive Shutterstock’s digital transformation into a full-service creative platform for hundreds of thousands of creative professionals around the world. She talks with 3Pillar’s Scott Varho and Elisabeth Beller about moving from software project to product on this episode of The Innovation Engine.

It’s an enlightening conversation that touches on why the project-based annual budgeting process is more fantasyland than real world, how Sejal sees value stream management changing the way we think about product development, and why it’s important for companies and teams to focus on performance rather than productivity.

Listen to the Episode

These were just a few of the highlights of the conversation with Sejal about the key differences between project and product.

Product Always Puts Customer Needs Front and Center

• With such a broad transformation happening at Shutterstock, the company needs to think about the way its products will meet the changing needs of its customers not just now, but in the years to come as well. The company is shifting from mainly licensing stock photography and video to meeting the needs of creators everywhere. This means making Shutterstock the destination for doing creative work, including work traditionally done elsewhere.

Products Require Continual Evolution

• Shutterstock is transforming into a multi-purpose platform that enables creators to tell amazing stories. This means looking at what they provide to customers as a portfolio of assets that provides various capabilities to its customers and contributors rather than one homogenous product.
• The company has grown largely through acquisitions, and with these assets come new capabilities to the platform. It also means making rapid decisions about what capabilities to invest in first, what features to double down on, and understanding what the best spread of features looks like.

Understanding Value Streams Must Inform the Development Process

• A value stream is an end-to-end system of activities that collectively creates value for your customer. “When you’re developing a value stream map,” Sejal says, “You’re illustrating the steps your organization goes through to deliver that value.” Practically speaking, any workflow with a customer at the end of the experience can be considered a value stream.
• Talking with your teams about value stream management is important. Value stream performance is tied directly to team performance. When you look at how efficiently information flows within the system, how people work together, what the bottlenecks are in that workflow, and how to make improvements to that system, it quickly becomes a priority conversation.
• A big part of “speed” in product development is putting value into customers’ hands as quickly as possible. An important distinction that Scott makes is that speed and velocity are often considered to be the same thing. There’s a closer relationship between speed and capacity, which has to do with how quickly a team can actually go from idea or feedback to in-market. “A lot of organizations are building faster than they’re shipping,” Sejal says. “All too often, people think the problem is engineering, but if you look really closely, the problem could be anywhere.”

Tune in to the full conversation to hear how Shutterstock is making the leap from project to product, what a value stream is and how to manage it within a company, and why using a body of metrics is vital to drive decision-making during digital transformation.

Episode Highlights:
[01:44] The biggest distinctions between a software development project and building a software product
[06:28] Convincing an organization to move from project to product
[10:15] What value stream management is and how to talk about it with your teams
[19:07] How Sejal is pushing digital transformation at Shutterstock
[23:51] The metrics worth focusing on and looking at them across functions
[26:33] Understanding the end goal and the definition of “speed” in your organization

Resources:
Connect with Sejal on LinkedIn
Read: Accelerate: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, PhD, Jez Humble, and Gene Kim
Read: Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework by Mik Kersten
Read: Sooner Safer Happier: Antipatterns and Patterns for Business Agility by Jonathan Smart
If you have any feedback about the podcast or guests you’d like to hear interviewed, send your suggestions to info@3pillarglobal.com.

Transcript

Scott Varho: [00:00:04] This is the Innovation Engine Podcast from 3Pillar Global. Your home for conversations with industry leaders on all things digital transformation and innovation.

Welcome back to The Innovation Engine. I’m Scott Varho, 3Pillar’s Chief Evangelist and your host. And I’m excited to be speaking today with Sejal Amin, alongside my colleague, Elisabeth Beller.

Sejal is the newly named Chief Technology Officer at Shutterstock, where she has a broad mandate to drive Shutterstock’s digital transformation into a full-service creative platform for hundreds of thousands of creative professionals around the world.

She previously held technology and product leadership roles at Khoros, Thomson Reuters, and Thomson Scientific. In a career that spans more than 25 years, Sejal has led product and technology teams of more than a thousand to shift how they think in work, resulting in experiences that delight customers and drive business growth.

Sejal, without further ado, excited to have you and really excited for you. I know you just started in your new role at Shutterstock. And I wanted to, first, just let you know that we really appreciate you being with us. That has to be quite an experience being in a new leadership role. How are things going?

Sejal Amin: [00:01:18] Well, they’re going well. And I’m recording this with you just about 30 days in or having passed that 30-day mark, and it’s been an incredible experience so far. Busy albeit, but incredible.

Scott Varho: [00:01:29] Did the 30 days feel like they’ve gone by really fast, or it’s been an eternity, or both?

Sejal Amin: [00:01:33] No. No. So, I feel like 30 days, and I’ve been here for a very long time. I’ve settled right in. The environment is really comfortable and it’s a great culture.

Scott Varho: [00:01:42] That is fantastic. So, let’s set the stage for our topic by just diving right in. What do you see as the biggest distinctions between software development projects and building software products?

Sejal Amin: [00:01:56] Well, you’ve chosen a topic or we’ve chosen a topic that’s near and dear to my heart. And I think we could spend an entire podcast just talking about this one question, but let’s dig into a few things to help us get moving.

And I think I want to start with a really timely example because I’m going through it now. Many of you are probably going through your annual operating planning cycle, and the funny thing about project models is that they quite often assume projects will magically finish on December 31st, and new ones start on January 1st.

And while we all desperately wish for things to be just that predictable, we all know that that’s not really how product development works. It’s not how the markets that we operate in work. And it’s really not how customers expect us to work.

So, I think product oriented companies think about funding and timeframes very differently. They recognize that products are never finished, at least not until they’re retired. And while they might adjust funding rate over time, they do that based on business results and business strategy.

In this model, we don’t see fatalistic budget changes on December 31st. Instead, we’re constantly monitoring product performance and market opportunity. And we justify our ups and downs and run rate based on continuous incremental delivery. And I think the side effect here is that we reinforce the idea of building in small batches because we’re assessing product outcomes and business impacts more frequently than just once a year.

So, while I think budgeting and timing is the first big difference, the second one to call out is staffing. Project driven organizations are more likely to shuffle their teams around and team structure to match the needs of their project.

And in project mode, we talk about sending individuals to the work. And in product mode, we play the game of moving people around. And the unit of performance is the individual and not the team. And because of that, they end up moving people around constantly because it perceives that it gives them the best return on investment.

And, of course, that comes with side effects. Individuals lose their sense of team, product knowledge gets lost, and code ownership gets lost. And engineers, I think these days, just don’t want to hangout in that kind of environment.

Product-oriented organization, on the other hand, focus on team stability. So, instead of sending individuals to the work, they send work to the teams. And I think this is just one of the ingredients of building high performing teams. I think long lasting teams build performance over time. You keep them together. You give them vision. You give them purpose. You allow them to learn from one another and you get out of their way and let them do what they do.

Scott Varho: [00:04:54] One of my favorite lines – and Elizabeth just had to hear me say this so many times – Marty Cagan was quoting John Doerr when he said, to build great products, you need missionaries, not mercenaries. And we have taken that a little bit further and said, we need mission driven teams, not mercenary teams.

And it’s kind of ironic, and I talk about this inside 3Pillar all the time. Technically, we are mercenaries. We’re in-house using vendor. But our differentiation is that we’re building teams that are hungry for a mission. They want to sink their teeth into something and make a difference. And so, what you’re talking about absolutely resonates with me.

But I think the insight around funding is a really great one, because that model, in every organization that I’ve been at, we play the budgeting process and I’m like, “This isn’t how this is going to play out.” Like, I need to be able to say enough pretty things in front of enough people who are going to give me money. And then, I’m going to go spend it in the best possible way every single sprint that has nothing to do with the one I told the executives I was going to do.

I mean, directionally, of course, yes. But it’s just unrealistic. It’s just not connected to how products are actually built. And it would be irresponsible for me to act on yesterday’s assumptions today when I don’t have evidence that that is the best place to put your money.

So, it is really interesting. I’ve been in that kind of reality distortion layer of, “Well, let’s tell them it’s a project and it’s one you’re funding.” And that’s fine because they won’t shut it down after a year anyways, so that’s interesting.

Elisabeth Beller: [00:06:25] Sejal, have you convinced others to make that leap from project to product? Like, what are some of the arguments you used to help convince them. I mean, you’ve just used some really good one with us, but what are some of the things you hear them say that make you realize, “Oh, this person really needs to understand the difference between project and product, and why product could be a more effective mindset.”

Sejal Amin: [00:06:51] Yeah. That’s a really great question. So, when I think about projects, projects are usually time bound and cost bound, right, Elisabeth? And I think the consequence, that is all this time, is that affects quality. And so, if organizations are still running separate build and run teams, I think that impacts quality over time. It becomes a compounding problem.

And so, one of the key selling points here is that, I think, product oriented organizations have a higher sense of awareness of the impacts on poor quality, because they are more in tune with what product and business outcomes they’re driving through incremental delivery.

So, if you’re working in an organization where you don’t think that you have a clear line of sight to what outcomes you’re influencing through your work, that tends to be a huge red flag. And it’s one of the big talking points in a conversation, that three-legged stool and what compromise is being made.

The other thing – and, again, I’m probably living some of this now – I think it requires executives to have an enterprise view of their product taxonomy or their portfolio or their product ecosystem. The language being used could vary from context to context. I think it’s a really important way to ground leaders and ground the entire organization to understand that. Because at the end of the day, it gives you a way to traverse the organization, communicate in a language that means the same to everyone. And that grounding, I think, helps executives and the people who work for them make good decisions.

Elisabeth Beller: [00:08:51] She’s whispering, Scott.

Sejal Amin: [00:08:53] Yes. I’m whispering. Someone’s going to hear me over there.

Elisabeth Beller: [00:08:56] She didn’t want anyone to hear her say that.

Scott Varho: [00:08:59] That’s beautiful. To be revealed later. But the point on quality, I think, is really interesting because you talk about the compounding nature of problems, especially quality issues. And I’ve always found it fascinating that so much of quality is not written into the user stories. We don’t tell engineers, “I expect this to have a 99.99 percent up time. And I expect this to load in under a second.” Or all of this performance and qualitative are expected to be maintainable and easily changed later. These are facets that are under the hood. They’re unspoken requirements.

But the fact is, is that if you don’t pay attention to those things, you have compounding problems on one side. But if you’re able to do it well, you have compounding interest on the other. Your ability to make medium and long term value, because a little bit of value over a longer period of time can be a lot of value. And, obviously, it goes up from there. But you love that compounding interest and nature of digital product if you’re on the good side of this equation. If you’re suffering for bad quality, then that’s much more difficult to realize.

Sejal Amin: [00:10:09] Yes. No, I completely agree with you on that.

Scott Varho: [00:10:12] So, kind of pivoting a little bit on that, we’re really big believers here about minimizing time to value. We love it. We want to get something out there. We want to start that learning cycle as soon as possible. Obviously, start the revenue cycle as soon as possible. That helps as well. Again, time is the factor of value.

When you talk about value stream management, now this is a term that we are seeing more and more in more and more places, and I understand you’re an advocate of value stream management, how would you explain that in layman’s terms?

Sejal Amin: [00:10:45] Really, really simple. I think of value stream is an end-to-end set of activities that, to your point just a few moments ago, collectively creates value for a customer. Super simple. So, when you’re developing a value stream map, you’re illustrating the steps that your organization goes through to deliver a unit of value to a customer. And I think, roughly speaking, if there’s a customer at the end of the process, that’s a value stream.

So, when I think about product development and engineering, I think delivery and operations is representative of a value stream. If you run a website, a mobile app – I don’t know – an API, you’re working within the context of a value stream.

Scott Varho: [00:11:28] And would that include any analog customer experience? Sorry, I didn’t mean to cut you off there. But any offline customer experiences as well? Or is that out of the scope of a value stream?

Sejal Amin: [00:11:38] No. No. I think it’s inclusive of that as well.

Scott Varho: [00:11:42] Okay.

Sejal Amin: [00:11:42] Yes. Yes. And what I was going to say is, the thing that’s drawn me to value stream thinking is just how complex product development is. And, say, to broaden a diverse range of skills and people and organizations involved in developing and operating a successful digital product. And so, it’s that online, and to your point, it’s that offline experience as well.

Scott Varho: [00:12:10] Wow. You just told me to spend more time with value stream management as a framework. Because it really does amaze me sometimes how simplistic people think like, “Oh, I just need engineers and we’re good to go.” And there’s, obviously, a lot more that’s needed to build value, basically, to build great products but also to realize the value from those products. They’re usually only part of a larger ecosystem of factors. That’s interesting.

Scott Varho: [00:12:43] Hi, friends. A quick favor to ask, if you’re enjoying the Innovation Engine, please give us a rating and leave a review on your podcast player of choice. It helps us get the word out about the show so we can continue to bring you more high quality episodes.

If you have any feedback about the podcast or guests you’d like to hear interviewed, send your suggestions over to info@3pillarglobal.com, that’s 3pillar with the number three. And if you’re looking to drive innovation and transformation in your organization, look us up at 3pillarglobal.com. Now, let’s get back to the action.

Elisabeth Beller: [00:13:17] Sejal, how do you talk to your teams about value stream management? You gave a good sort of philosophical explanation. How do you talk to them about it on day-to-day basis?

Sejal Amin: [00:13:26] Yeah. That’s a really great question, Elisabeth. So, just taking a step back, when I started my career in engineering management – which was a long time ago. I won’t date myself – people like me, including me, that many years ago, we were really operating in a very narrow, narrow awareness of the value streams that they operated in. And I say, the project paradigm dominated back then, and our job and our only job was to deliver what we were told.

And so, my awareness of the other people in organizations in the value stream, whether it be upstream or downstream, honestly, it was quite poor. And so, I had very little ability to improve the value stream and to improve the outcomes that the value stream delivered.

And so, I’d say, largely in my past ten years, I’ve been all about building teams with that value stream awareness with a focus on breaking down barriers between project management and engineering so that we’re improving the quality of what we produce, and the speed at which we’re producing it.

And so, when I talk to teams, we’re talking about value, we’re talking about quality, and we’re talking about speed. And so, I think visualizing the value stream is the first step in being able to understand and improve value stream performance.

And, again, when we’re talking about value stream performance, Elisabeth, I like to tie it to team performance. All too often, I think when we talk about engineering organizations, we talk about productivity like it’s a thing we can tweak. And so, this is another topic that’s near and dear to my heart is the difference between productivity and performance. To me, those are two very, very different things.

Scott Varho: [00:15:15] You are singing my song.

Sejal Amin: [00:15:17] Right, right. And so, when I talk about value streams – to just close the thread on the question that Elisabeth asked – I’d like to talk about value stream performance, team performance, and taking a look at how work and information flows the system, the people in it, how well the system is working, where information stops, where it’s bottlenecked, and how you can then build a foundation on which to make improvements. And when you talk about it in those terms, there isn’t anyone that says, “Hey, I don’t want to talk about better performance.”

Elisabeth Beller: [00:15:51] Right. Right.

Sejal Amin: [00:15:53] Because it affects the customer, it affects the business, it affects the team, it affects everything around you.

Elisabeth Beller: [00:16:00] I think we’re starting to hear a lot more people in the product development world being more comfortable talking in those terms. I noticed on your LinkedIn profile that you had a statement that said, “In the next five years, we’ll see value stream management extend to every point of enterprise value delivery, not just software development.” I’m curious about that statement and how that looks with you.

Sejal Amin: [00:16:00] Yeah. So, I think for product developers like myself, the value proposition is super clear. I think the three areas of focus, so continuous value stream budgeting, and the emphasis of big annual planning events – which I talked about when we opened here – continuous product value stream and business outcome measurement, and the inherent really good and positive consequences on product and solution quality.

And then, the last thing is, we are going to have a clear understanding of the efficiency and effectiveness of the value stream with insights on how to improve it, with a focus on performance, not productivity. Because those are two really, really different things. And I don’t think anything or any business in the world would want to take advantage of that. Who doesn’t want to talk about those things?

And so, when I think about it more broadly, to the quote that you just said, I think anything that a customer has is a value stream. So, the application of the framework is fairly wide. There are clear applications outside of product development and operations. And I’ve seen some success in marketing, in sourcing and hiring, and sometimes even in sales. So, I think it goes beyond product development. I think there’s broader applicability.

Scott Varho: [00:17:44] Just to share a personal point on this, because it fascinates me that there are still companies out there that want to build teams and build it versus operate teams. And I’m like, “No. We got a way for that. Remember DevOps? That was the whole point, we bring these things back together.” So, fascinating to see that that still happens.

And, literally, in a job before 3Pillar, I was asked to do that several times. And I’m like, “No. No chance will I allow that to happen on my watch.” But the next thing that happened was interesting, after I left that organization, instead of being aligned by product, they aligned the teams by backend, frontend. So, there’s a solid line somewhere and a dotted line somewhere.

But they made the solid lines in the backend engineering because they’re having quality issues. I was like, “But you just took the value off the table.” That’s no longer what they’re talking about is providing more value. They’re talking about being better at backend engineering. And I always wanted their focus to be, first and foremost, obsessed about the value you are providing because we are expensive and we want to return way more than our company is spending on us.

Sejal Amin: [00:18:51] Interesting. Yeah.

Scott Varho: [00:18:52] But it’s still there today, this engineering mindset of we’re better at backend engineering, our problems would be solved. And it’s like, “Yeah. Typically not.” That’s not usually how these works.

So, when you joined Shutterstock, CEO Paul Hennessy said in your press release that hiring you is going to help Shutterstock continue it’s – I’m quoting here – “digital transformation to a full service creative platform that democratizes creativity, pushes creative boundaries, and provides unparalleled experiences for our customers and contributors around the world.” That’s a big statement.

Sejal Amin: [00:19:29] Huge. I have no problem, I’ll have it done before the end of the year. End of the quarter.

Scott Varho: [00:19:34] That’s amazing. I bet he’s thrilled by that news. Yeah, so talk about that. How do you plan to go about doing that?

Sejal Amin: [00:19:44] Yeah. So, Shutterstock is such an interesting place. And like many others, this portfolio has grown through acquisition. So, in its current state, parts of it, like, when I got here, require investment in that integration so that it enables the strategy that Paul so eloquently described. And Shutterstock’s origins are a stock photo company. And we’re evolving into a platform of many capabilities that enables creators to tell amazing stories.

So, operationally, this means that we, too, are taking the project product journey in which we’re managing a portfolio of assets that provides these capabilities to our customers and contributors. And all of the things that we’ve talked about today and we haven’t covered, we’ve only just touched the tip of the iceberg. All of those things are coming to life in this environment. I see it all here, which is why I’m so excited to be here.

There’s so many interesting things to uncover, but the journey from taking Shutterstock from the stock photo company, to one that is a platform of many capabilities that’s enabling creators is the great part.

Scott Varho: [00:21:01] That is exciting.

Elisabeth Beller: [00:21:03] Yeah. It sounds like a big challenge, but it should be exciting. Can you talk a little more specifically about how you see that change division playing out as you move from being a stock photo company to creative story telling?

Sejal Amin: [00:21:15] Yeah. Sure. So, like I mentioned just a minute ago, this company has largely through acquisition, so there’s been a number of assets that have come into the portfolio that have brought new capabilities to the table, Elisabeth, that will help us enable that journey.

But right now, we’re in the process of assessing what that looks like to us come next year, what capabilities are we going to invest in, and really double down on and treat it the way that we talked about. This is a marketplace, and into that marketplace, like I said, we’re extending that marketplace so that when creators come and they’re dropping an asset off, that they have the tools available to their disposal to do the creative work that they would have to do outside of the platform.

So, from an engineering and building perspective, it’s about building those assets out. Now, operationally, like I said, it’s that typical journey where we’re looking at a set of small projects and we’re pivoting to a portfolio where we have products and capabilities and services that support those capabilities and understanding what that spread and sprawl looks like, what the right investment is.

And then, as an organization, how are we now pivoting people to work on those things, stay fixed on those things, what data are we gathering. The data that’s coming in, the data that’s going out that’s enabling us to make better decisions. We’re literally establishing all of that foundation as we speak. That is super exciting. Super, super exciting.

Scott Varho: [00:23:03] Super exciting. And it’s rather encouraging, discouraging, comforting that so many companies are struggling with these themes. It’s not unusual but the opportunity for what David DeWolf, our CEO, talks about another way of digital products that are coming. And I think he’s right because so much of business doesn’t have this, so, obviously, there’s a long way to go on those products, a lot of room to add more value and to be more usable, more valuable, more transformative in the way we live and work, which is pretty cool.

You know, in one of your articles, you mentioned data and you mentioned in an article for Forbes that part of the transition from project to product is around data and metrics, that that has to be a core focus. And you mentioned earlier about performance versus productivity, which I love, because – gosh, who knows – I run into so many people who want to talk to me about how many points per sprint – let’s not talk about that. I will stop a sprint if I can get more value by stopping a sprint. So, I’m more focused on value than throughput.

But talk to us a little more about that. Like, what kinds of metrics do you tend to focus on? You talked about speed. What do you mean by speed [inaudible]?

Sejal Amin: [00:24:26] Yeah. Yeah. So, just on the topic of metrics, I think especially in large organizations where they are super functionally aligned, I think if all of the groups are not oriented around the thing, and the thing being the product, the capability, or whatever language you want to use to describe the thing that they’re building, if they’re not aligned with those metrics, it creates misalignments and behaviors, quite candidly, that work against each other. Completely undermining the transformation that the enterprise is on.

And so, when I think about metrics, I like to think about a body of metrics that tell us everything about the health of the product, that tell us about the health of the customer who is using that product, that tell us something about the health and the culture of the team that’s building that product, that tell us something about the system. And when I say the system, the system we’re supporting. So, there’s delivery performance, there’s system performance, there’s all of those things that happen.

If you’ve read some of Nicole Forsgren’s research, her DORA report, it talks a lot about that information that tells you about the health of the ecosystem. So, to me, I like to think about an entire body of data and, really, product and engineering and business leaders have to get to that cross-functional alignment so that we are having a conversation together so that a set of metrics isn’t used in isolation across functions without understanding what the dependencies are.

Scott Varho: [00:26:14] That, I think is probably the hardest part is understanding the interdependencies of those metrics and how one moving up or down may or not be the one that you should be focused on.

Sejal Amin: [00:26:25] That’s always the hardest part is understanding what winning looks like for an organization. And to your other question, you asked about speed, right? What is speed? You’re trying to get value into the customer’s hands as fast as you possibly can. And so, anything that affects and influences that should be at the top of mind. And once you solve the problem in one place, it just moves to another. And so, you need to track that.

Scott Varho: [00:26:58] It’s interesting. So, agile and then it’s poor cousins, I get so upset when I hear that people have not read the manifesto. But Scrum misdescribes speed as velocity. And what they’re really describing is capacity. But when the business talks about speed, we’re really talking about new information to something deployed into market that’s valuable. That’s speed, which is a very different measure of speed than velocity is.

So, it’s one of those things that I think Agile got wrong, that we’re living with a legacy in a lot of the work around DevOps and operation is now trying to come back and deal with some of those gaps in our thinking. But being really clear about that has helped me a lot in helping clients think differently about how their team should be structured to get value to market faster, exactly as you said.

Sejal Amin: [00:27:53] Yeah. Yeah. And I think a lot of organizations, by the way, they’re building faster than they’re shipping. It tends to happen, I think, 95 percent of the time for lots of different reasons. It could be because of automation, to your point. The continuous delivery or deployment style, it’s not getting them there. There’s only downstream partners, like sales or enablement, that are not staffed to cope with deployment frequency.

And so, that, too, has to be part of the conversation. Often, they’ll have really heavyweight or cumbersome go to market processes that aren’t aligned with continuous cadences. And I think, all too often, people think the symptom is it must be an engineering, not fast enough. Or they haven’t invested enough in the deployment. But if you look closely, the problem could be anywhere. Sometimes it’s downstream.

Scott Varho: [00:28:52] Yeah. Well, along those lines, I thought it was sort of fascinating to learn. I’ve worked at tech a long time, and one of the interesting things about selling and tech is the market itself cannot consume change in between semesters, or intra-semester, I should say.

So, you can deploy changes and they can even be directionally correct, but they will completely throw off your customers because they have a set of training materials that have been handed out to their teachers or to their faculty or whatever. And if the screen doesn’t match exactly what they see in that handout, that book that was carefully created with a version of your product that existed at the beginning of the semester, you have just destabilized that institution entirely.

And so, it was an education that we can continuously deploy, but we have to manage the change in a cadence that suits our customers and our market. And that was a fun learning curve. We got faster and they were like, “Whoa. Whoa.”

All right. You know, we like to do a little speed round to round things out. So, if you don’t mind, I’m going to throw a couple questions at you and we’ll do this. You’re a long time New Yorker, which means having strong opinions, typically comes with the territory, what is your favorite borough?

Sejal Amin: [00:30:15] So, I’m probably going to give you the answer that everyone gives here, it’s Manhattan. Because where else can you get the diversity, food, and culture it has to offer? I think every corner of the city is so fascinating and different. And the thing that’s so interesting is it has – and I just read this somewhere, I don’t know why I did – 1,700 parks with Central Park just being spectacular. I think one can come here and find something different to do every single time.

Scott Varho: [00:30:45] That’s incredible. Now, I will say, other people will answer that question differently, so strong opinions indeed are native to New York. I understand you’re teaching a class or classes at NYU.

Sejal Amin: [00:30:57] Yeah, yeah, yeah.

Scott Varho: [00:30:57] Which ones?

Sejal Amin: [00:31:00] Yeah. So, I will tell you, this has been one of my favorites experiences this year. So, I had an opportunity to put together a class for their CTO Executive Education Program. I did that with a colleague, and we focused on how to run high performing technology organizations. I’d say, it’s a topic that I’m particularly passionate about.

So, very interesting, we worked with NYU and their vendor to develop the content structure and record it for the learners. And the topics I covered or designed, how to build an organization that learns, leadership behaviors, diversity and inclusion, and the use of metrics to enable success. A really good topic.

Scott Varho: [00:31:44] Did you wind up going into Accelerate, the book by Forsgren?

Sejal Amin: [00:31:49] Of course, I did. Of course, I did. Yes.

Scott Varho: [00:31:53] I’ve been handing that book out at 3Pillar like it’s candy.

Sejal Amin: [00:31:55] You give it out like cupcakes. And by the way, I’ve been giving it out here. It’s one of my favorite books. And I covered that content plus the use of that data, what it means, the flow framework, all of it, you name it. It was a lot of learning material, so I had a lot of fun doing it and I’m hoping that I’m able to do more. I’m talking to them about my next gig there, so more to come.

Scott Varho: [00:32:22] That’s fantastic. I got the chance to teach at the beginning of my career, and that’s one that that is how I will end my career. I love it. I was terrible at it when I was 21, but I really did enjoy doing it poorly. Maybe now I’d actually be better at it.

So, having to take that book off the table, what is the most impactful business or technology book you’ve ever read?

Sejal Amin: [00:32:45] That’s a really good question. Candidly, I always answer that one because it’s such an impactful read for CTOs, engineering leaders, and engineers because it lays a foundation for the organization. You know, there’s so many others that’s in that camp. Mik Kersten’s Project to Product book is an excellent one, Sooner Safer Happier is an excellent one. All of these are really great reads that help you understand the levers that enable a high performance software delivery organization.

Anyone who’s worth their salt should know what those things are, what those books are, and the key themes that are thought. But the Accelerate one, which we already made mention of, that really lays the foundation. And then, from there, there’s many other reads, like the ones I mentioned, that support the content in this book.

Scott Varho: [00:33:38] Yeah. I mean, for those of our listeners who haven’t read it, the rigor behind it is dry as it makes it to read is fantastic. It really lends a lot more credibility than some of the books that cover the same material or same topics, but don’t have the same level of rigor. It was transformative for me. Though, I kind of felt a lot of those things, but just to see it laid out with that much research behind it was fantastic.

Well, thank you. This has been fantastic. And I can tell we’re very like minded and we’re really excited to hear about how this chapter goes from here at Shutterstock for you.

Sejal Amin: [00:34:16] Absolutely. You’ll be hearing from me more on that, for sure. But thank you both for having me here. This was a lot of fun.

Scott Varho: [00:34:23] Yeah. Thank you.

Elisabeth Beller: [00:34:24] Thank you, Sejal.

Jennifer Ives: [00:34:28] This has been an episode of The Innovation Engine, a podcast from 3Pillar Global. 3Pillar is a digital product development and innovation partner that helps companies compete and win in the digital economy. To learn more about 3Pillar Global and how we can help you, visit our website at 3pillarglobal.com.

Lastly, remember to give us a rating and leave a review on your podcast player of choice. If you have any feedback or guest suggestion, send them over to info@3pillarglobal.com. Thanks for listening and see you next time.