Disciplined Creativity: Lessons from Leading Product Teams with Derek Ferguson, CSO, Fitch Group Inc.

[00:00:00] Welcome to the Convergence Podcast. I'm your host, Ashok Sivanand.

[00:00:04] Ashok Sivanand This concept of working code versus just telling folks here's what it's going to look like, always, always stuff comes up. And when you can show that it's quick to be fixed in this approach, that's the best way of getting the business bought in.

[00:00:19] On this show, we'll deconstruct the best practices, principles, and the underlying philosophies behind the most engaged product teams who ship the most successful products.

[00:00:36] This is what teams are made of.

[00:00:39] Welcome back to the Convergence Podcast, folks.

[00:00:42] Today's episode dives deep into the complex balance of creativity and structure, especially while executing as a scaled team.

[00:00:50] Our guest today, Derek Ferguson, brings us a unique perspective that combines his background as a music major with years of experience leading innovative product teams.

[00:01:02] Today, Derek is the Chief Software Officer for the Fitch Group, a leading financial information services provider, where he focuses on driving innovation across over 600 software developers, while they manage the evolution of key products and workflow systems that provide credit ratings, research, and analytics to their global customer base.

[00:01:25] Prior to Fitch, Derek worked at the most successful products.

[00:01:28] Prior to Fitch, Derek worked at JPMorgan Chase, Bear Stearns, and InterAccess.

[00:01:31] And he also wrote a number of books from Microsoft Press that helped Microsoft on their mission to bring internet to the masses in the 90s.

[00:01:39] He was also the Editor-in-Chief at the .NET Developers Journal.

[00:01:44] In the first of our two-part conversation with Derek, we explore how disciplined creativity shapes exceptional product teams.

[00:01:53] Derek shares insights on how one of the largest banks in the world had three out of four things go right for them as they built one of the best digital experiences in the space.

[00:02:03] One that I will testify is pretty great.

[00:02:07] We get to hear about lessons in navigating the challenges of trust and collaboration with business stakeholders, and how, believe it or not, it was an agile coach that was instrumental in that journey there.

[00:02:19] Whether you're leading a product organization or an engineering organization, or you're curious about what makes teams thrive, this episode offers plenty of inspiration and actionable advice that can help.

[00:02:33] Next week, Derek will join us again, and we'll get to talk about his experience rolling out both generative AI and Dora metrics across his engineering team,

[00:02:44] and the parallels that he sees with the adoption of AI in the enterprise to when they adopted the internet back in the 90s.

[00:03:04] Here is Derek.

[00:03:09] Derek, welcome to the show.

[00:03:11] One thing that I was pretty fascinated and curious about your background is that you started out as a music major,

[00:03:19] and in the years of working with hundreds of product folks and software engineers,

[00:03:25] I've personally had a weakness for folks who studied music, especially classical music, and as in their earlier days or studied music in post-secondary.

[00:03:34] And I'm curious to know if you've got any similar observations around my hunches on why music majors tend to make pretty good software engineers when they switch over.

[00:03:45] Is it a matter of the fact that as people are learning that disciplined style of creativity,

[00:03:54] it falls somewhere on the spectrum the same place as software engineering does,

[00:04:01] which is it's neither a purely one side of your brain pursuit like painting, which is just, you know, thoroughly creative,

[00:04:09] and it's not completely mathematical on the other side.

[00:04:13] It really lies at the intersection of the two.

[00:04:17] It's applying principles of organization and structure to chaos to produce something which is ordered and serves a purpose.

[00:04:27] In the case of music, that's, you know, entertaining people's ears, but in the case of software, it's producing useful applications.

[00:04:35] You know, I really like the way you said a disciplined approach to creativity.

[00:04:40] I think a lot of folks have the misconception that those are mutually exclusive,

[00:04:44] that either you can be really structured and disciplined or you're being creative.

[00:04:48] And I think really great product teams have that ability to be really disciplined in their innovation and creativity.

[00:04:56] And as we know from design thinking, there's, there's room for divergent thinking.

[00:05:00] And then there's room for convergent thinking of taking all those wacky ideas and prioritizing them and putting them into action.

[00:05:06] So I know you've worked on one of the best digital experiences for a bank.

[00:05:13] And, you know, the industry and financial institutions, I think really requires that for a bank qualifier,

[00:05:19] which may or may not count so much as a huge accolade, just given how terrible some of the experiences are and may not have been updated from the early 2000s.

[00:05:29] And you did this at a really big financial institution.

[00:05:34] And I'm curious to know, what do you think set that team apart or that organization apart when everyone probably started from a similar place,

[00:05:43] but, you know, the spread was so far apart in terms of the really great experiences to the really average ones?

[00:05:48] And I think that's something that I think doesn't get talked about enough is that the evolution of team structure in agile

[00:06:01] and the revolution of design and architecture in microservices,

[00:06:09] those two things are really fundamentally interlinked along with DevOps.

[00:06:15] So I would put that as sort of the third point in the triangle that you can't have proper agile methodology unless you have software,

[00:06:28] which is independent enough that you can actually stand up squads to build and maintain that software that aren't constantly going to have these tight couplings.

[00:06:39] Mm-hmm .

[00:06:40] The software has to be decoupled in order for the teams to be decoupled.

[00:06:44] And then DevOps is the third part of that triangle.

[00:06:48] You got to have that too, because if all of the squads are independent from each other,

[00:06:53] but they still have to keep going to this third party to say, can you release our software, please?

[00:06:58] Can you release our software, please? Can you release it?

[00:07:00] That becomes that implicit connection between the three points.

[00:07:04] So at the organization I was at, all three of those revolutions were taking place simultaneously.

[00:07:12] And I think if I had to point to one thing that really allowed that process and that software that we built to be super successful,

[00:07:23] I would probably point to the fact that those three things were happening.

[00:07:28] And I guess if I had to add on a third, the organization I was at was famously slow to adopt cloud.

[00:07:36] The fourth thing is the thing that probably would have made it an even more successful implementation,

[00:07:40] but at least we had three of the four, right?

[00:07:44] For a big company to adopt a radically different style of working is like changing the direction of an ocean liner.

[00:07:51] We're not on jet skis. So three out of four is a lot better than I think a lot of the organizations of that size.

[00:07:58] One thing I am curious about is that while agile microservices and DevOps, even if cloud's not in there,

[00:08:07] and even if you've got four out of four, I think earning the trust of the more customer phasing folks or the business folks that are ultimately the stakeholders

[00:08:17] and likely decide a lot of the decisions that go into prioritizing a roadmap or even the nuances of user experience, how did those folks get bought in?

[00:08:29] When we first went to the business and said,

[00:08:33] what's the tiniest piece that we can give you that you will actually be using after two weeks?

[00:08:41] They were suitably mystified, amused, befuddled.

[00:08:46] It's like, wait, this piece is...

[00:08:49] Yeah, you can't give us anything that we would actually be using in two weeks.

[00:08:54] Um, and we happened to have the benefits. I can't take credit for this by I watched and I learned from it, but this was this was my formative experience,

[00:09:04] as opposed to me being the, uh, the wise and expert at this point in time.

[00:09:08] We had a great agile coach who, who was able to essentially embark on a negotiation process and an explanation process with the business to say,

[00:09:20] I know that you feel like you need everything before you can use any of it.

[00:09:26] But let's think back to other times when this has been done, because, you know, everyone on this team was experienced enough to have been to this rodeo a few times.

[00:09:36] Has that ever worked out well for you?

[00:09:38] Has it ever worked out well that you've told the technology team what you want and they go away for two years and they build and then they come back?

[00:09:44] And is it still the stuff you want? Let's just, let's just try a little piece.

[00:09:49] And, you know, sure enough, we, I don't think we got a piece that they could use after two weeks, but we had a piece that they were using after a month.

[00:09:57] And at first they had the hesitancy that a lot of businesses have, which is they had to go to their old system and do 99% of the work and then swivel chair over to the new system and do 1% of the work that first, you know, month.

[00:10:14] And then the next month they were coming over here and doing 95% of the work and swiveling over here to do 5%.

[00:10:23] But the reinforcement of the value of this, of course, winds up being when things get discovered.

[00:10:31] Because in that first month of using just that 5%, you know, I shouldn't even say the 5%, you know, that 1% in the first month, that bit that they felt, you know, couldn't possibly give them any value.

[00:10:42] Well, wait, why did you, why'd you put that button there?

[00:10:46] You just said, give a button.

[00:10:47] You didn't say put it anywhere in particular.

[00:10:49] Well, of course you can't put it on the right-hand side of the screen.

[00:10:51] You have to put it on the left-hand side of the screen or X, Y, and Z is going to happen.

[00:10:56] Guess what?

[00:10:57] It's not super easy for us to change that now, but if we'd done that change a year from now, that would be a change request and we would have built all sorts of code on top of it.

[00:11:07] Let's change that for you.

[00:11:08] Next day it's on the left-hand side of the screen.

[00:11:10] Oh my God.

[00:11:11] That's so great.

[00:11:13] Always happens.

[00:11:14] You know, I think understandably until customers have had the experience of seeing how much stuff.

[00:11:24] Because everybody comes to the agile process in good faith.

[00:11:29] This whole idea of conversations rather than documentation is, you know, that's, that's all goodness, right?

[00:11:35] But you forget how much ambiguity there is in human language that everybody can come to something in good faith and think that they're saying everything that needs to be built.

[00:11:46] And yet there's so much room for interpretation that it's one of the other agile tenants, right?

[00:11:52] This concept of working code versus just telling folks, here's what it's going to look like.

[00:11:59] Always, always stuff comes up.

[00:12:01] And when you can show that it's quick to be fixed in this approach, that's the best way of getting the business bought in.

[00:12:11] Fostering an engaged product organization and aligning them with the principles around lean, human centered design, and agile will more than likely lead to successful business outcomes for your organization.

[00:12:24] But getting started or getting unblocked can be hard.

[00:12:27] This podcast is brought to you by the player coaches over at integral.

[00:12:31] They help ambitious companies like you build amazing product teams and ship products in artificial intelligence, cloud, web, and mobile.

[00:12:42] Listeners to the podcast can head on over to integral.io slash convergence and get a free product success lab.

[00:12:51] During this session, the integral team will facilitate a problem solving exercise that gives you clarity and confidence to solve a product design or engineering problem.

[00:13:02] That's integral.io slash convergence.

[00:13:06] Now back to the show.

[00:13:12] I'm fairly skeptical oftentimes about agile coaches.

[00:13:15] I think they give the industry a bad name when they're really self-righteous versions of maybe an audio bot that regurgitates something from the safe playbook versus someone who can sit down and negotiate with the business and help them identify what exactly that first chunk of work is.

[00:13:32] It's a business if they're not used to thinking in one or two weeks chunks, struggles to maybe know what the most urgent is.

[00:13:39] But it takes a few questions, I think, and willingness and business savvy on the agile coaches part to start that journey of trust.

[00:13:46] And the other thing I really like there is that it wasn't just the first month that you had the win.

[00:13:50] It was a consistency that you developed every month where they were seeing more progress and there was less of the legacy application and more of the new application that the work was getting transferred to.

[00:14:01] Now the third one, of course, is having that working code written in a very flexible way where that request of moving the button from one side to the other because of good reasons that maybe were under-communicated actually got implemented.

[00:14:15] Because there's no way for us to really communicate 100% of the time.

[00:14:19] There's eventually stuff that they didn't know to tell us and we didn't know how to ask.

[00:14:24] But once you put a wireframe or working code in front of them to react to and you're able to respond very quickly, I think there are always really critical ways to earn trust.

[00:14:35] At which point they will likely meet you halfway and start telling you the next two weeks worth of requirements versus giving you a 40 page PDF of everything that needs to get done and having the team figure it out, right?

[00:14:47] And I'm curious, is there anything else that we didn't cover that you would do again if you had to work with a new business team and you actively had to earn their trust to get this very high performing velocity going?

[00:15:02] Business process re-architecture is often not given the due respect and consideration that it warrants in all projects, but particularly in upgrades and migrations.

[00:15:22] Business process re-architecture is often given the due respect to the students.

[00:15:28] Business process re-architecture is often given the due respect of the time of the business.

[00:15:36] Business process re-architecture is often given the due respect of the business, but they were actually, you know, they had a profit and loss center that they had to manage.

[00:15:44] And they would, when asked for requirements, as I think most of us would, having used the previous system for 20 years, when asked, how do you want this screen to work?

[00:15:56] Or how do you want this process to function?

[00:15:58] They would fall back initially on, well, here's how it works today.

[00:16:04] And they would essentially describe the same thing.

[00:16:08] But once again, we had the luxury of a great agile coach.

[00:16:13] And maybe it was the fact that this person had been a software developer and a software development manager in the financial industry for 20 plus years.

[00:16:23] So they were coming at it from a perspective where they'd seen plenty of these things before, but they would always say, that's the way it works today.

[00:16:31] But is that really the way that is going to be most effective for you going forward?

[00:16:36] Because the whole thing here is we want to deliver a system that's going to boost efficiency and productivity and all that sort of stuff.

[00:16:44] And what we found out as we went through the process was, as anybody who's done these sorts of migrations will be familiar with, there's so much stuff, which is, it's like superstition.

[00:16:55] You know, we just grew up over time.

[00:16:57] Somebody at one point in time asked for these three entries on the dropdown and no one ever uses them because no one, whatever the business need for them was, is long since past.

[00:17:07] That law has changed or that department has been closed or whatever.

[00:17:12] And so you want to have that sort of relationship with the business where you can be thinking about, my boss at the time would always say, skate to where the puck is going, not where the puck is at.

[00:17:24] You want to have that kind of relationship with the business where you can really talk about, even in a migration, how do you really want to be doing business?

[00:17:32] I remember on that project, a lot of it was, a lot of the requirements were, well, you need to put these fields here.

[00:17:40] Why do we need to put those fields there?

[00:17:41] So we can type it in.

[00:17:43] So you can type it in.

[00:17:45] Where do you get that from?

[00:17:46] Well, we get it from this paper over here.

[00:17:47] Oh, hey, I was like, oh, wait, is there a system?

[00:17:51] Oh, yeah.

[00:17:51] First they, they print the paper out from this system and then they type it in over here.

[00:17:55] You know, we could, we could actually do something where we just read that information in directly from that other system.

[00:18:02] And then you don't need that, those fields.

[00:18:04] And I was, yeah, that's, that's where you really start to get those great conversations with the business.

[00:18:08] Whoa, you can do that?

[00:18:10] Oh, yeah, we can.

[00:18:11] We can do that.

[00:18:12] You don't need to, we can knock 10 screens out of your process.

[00:18:15] You will never have to fill out again.

[00:18:17] And that's where things really get fun, right?

[00:18:19] Because then you're, the business sees, oh, wow, this is, this isn't just, this isn't money we have to spend to do a technology upgrade.

[00:18:27] This is really going to give us something better that makes our lives improved at the end of it.

[00:18:32] A hundred percent.

[00:18:33] I think that facilitation is such a critical skill in building that trust where you hear folks come into the rooms and use the jargony, the art of the possible.

[00:18:46] And, and kind of wave a magic wand, expecting things to happen as opposed to kind of sitting with them and trying to understand what the current constraints are of their business.

[00:18:56] And sometimes they don't know it themselves.

[00:18:58] And we got to go the next level of helping understand for ourselves and for them by just being really curious.

[00:19:06] And then I think it's, the other thing that comes to mind is about really focusing on the customer, whether it's an internal business customer or the external user to really try and have them focus on stating their problems.

[00:19:19] As much as it's human nature for them to state solutions that have the problems implicit to it.

[00:19:26] And I think another facilitation technique is not to put them down when they're telling us solutions.

[00:19:33] I go through the extra step and our team at Integral did where we would let them really ramble on about this amazing new solution that they had.

[00:19:42] And then understand that and then ask follow-up questions of why to that solution to really distill the problem.

[00:19:50] So you're, you're not cutting them off or telling them how they're communicating is wrong.

[00:19:55] And you're using that also as a little interpersonal technique to allow them to express themselves and feel heard, but also use that as a jumping off point to understand the underlying problem or constraint that they're trying to solve for.

[00:20:08] And then it's an open conversation of like, Hey, if we solve this problem, what does business look like for you in the future versus that problem?

[00:20:16] And then prioritization and everything else kind of also tends to have a little bit more of a natural flow versus trying to prioritize across solutions without knowing what the problem is.

[00:20:25] Right.

[00:20:31] Thanks so much for listening, folks.

[00:21:08] Thank you for joining me on the Convergence podcast today.

[00:21:18] Subscribe to the Convergence podcast on Apple podcast, Spotify, YouTube, or wherever you get your content.

[00:21:27] If you're listening and found this helpful, please give us a five-star review.

[00:21:30] And if you're watching on YouTube, hit that like button and tell me what you think about what you heard today.