Robert Clawson

All right. My name is Robert Clawson. I am a Senior Principal Product Owner. And I'm here with the undeniable Sat Agrawal, Expert Application Engineer, also known as Senior Principal Software Engineer. And we are here on behalf of Discover Financial Services. And specifically, Sat and I work in the DTA, which is the Discover Technology Academy.

It's a dedicated learning academy within Discover, where we have teams, job families, job competencies go through different either immersive learning exercises or hands-on context to either knock out their tech debt, learn new skills, roll on to new products, form new work streams, all sorts of things like that.

And today we're here to talk about some small technical things your teams can do — theoretically, that you would have full control over — that can slowly start to help you build trust and really help your teams start to hold themselves accountable, avoid being managed, avoid being overmanaged, and really avoid being micromanaged.

So at Discover, they did start with a top-down approach, 'cause the message did have to come top-down from the leaders. They wanted to make sure that when we talked about our transformation, we weren't just saying we were going to go agile, we were going to do this. They wanted to say they had a hypothesis: that we could create more business value by changing the way that we develop and deliver our software products.

Specifically — a few people have talked here about having autonomy within guardrails. They wanted to make sure that teams had the autonomy to deliver, develop in their best way. And the only guardrails that they wanted to provide we'll talk about a little more later on.

So that approach came from the top down. And leadership is important. When we talk about how culture is formed, how culture is manifested within an organization, it's often difficult to sell engineers on what we're trying to get them to do is actually going to influence culture. Engineers are a dubious type, believe it or not.

But there's a study by this gentleman here — Ron Westrum, who's an American sociologist. And he did a study that looked at how the flow of information affected organizational culture. And he had this to say about culture. He said: leaders, by their preoccupation, shape our unit's culture through their actions, as well as their rewards and their punishments. Leaders communicate what they feel is important, and these preferences then become the preoccupation of our organization.

So it's how our leaders talk versus how they walk. And the gap between those two is what everyone sees, what everyone pays attention to. And ultimately, that's what's going to shape our organization's culture.

And Westrum's study found that organizations' culture typically fell within one of these three categories. We see the furthest to the right [on the slide]: pathological, power-oriented. It's categorized by fear and threat — people hoarding information to make themselves look better. Low cooperation. Responsibility is shirked. Failure is scapegoating — that "single neck to choke," if you were just next door [in another session]. Pathological.

He also found that there were bureaucratic organizations — ones that were obsessed with following the rules. They protect their departments — we've referred to those as silos. They want to maintain their turf, insist on doing things their way, insist that what they know is more important than what you know. Modest cooperation. Messengers neglected. Failure equals justice. Novelty being problematic.

I think I can confidently state most of us don't want to work in organizations in those two pillars.

And then we found that third pillar: generative, performance-oriented, where your organization's focus is on the mission. The best way to accomplish our goal — where we're really obsessed over the progress towards our goals and nothing else. It's ultimately about the success of the organization. There's high cooperation. Messengers are trained. Failure is nothing but a chance for inquiry. And novelty is embraced.

And what Westrum found was that the flow of information — amplified feedback loops — is what led organizations to this generative culture.

And aligns very well with what Gene said on day one about scenius. If you're not familiar with Brian Eno — I had never heard that term, scenius, before. But Brian Eno is a musician who collaborated with David Bowie. I think they built the first synthesizer — Bryan Ferry, among others. But scenius — that's a very real thing in music, in art, in culture. Often the person who comes out of the scene is not necessarily the best from that scene. But that scene cares about that scene. They harvest it.

Anyone here from Chicago? Okay, anyone? Okay, a couple folks from Chicago. I grew up in Chicago. I played in bands all around Chicago for years and years and years. A lot of them sound the same. It was the scene that swelled up. They obsessed with the flow of information before social media. They utilized things called guest books, if you remember those, to really connect with their fans. They stuck around at each other's shows. They promoted the hell out of each other's shows. They sold each other's merch. They wore each other's merch. They were obsessed with building that scene. And that scene got enough attention where one of them got really big — the one who was best at feedback loops. They actually asked the audience for their band name, and a Simpsons fan shouted out "Fall Out Boy." And that was the biggest band to come out of this scene. They may not have been the best — they may have sounded the same as all of them — but because that scene was curated, that star kind of came out of it. And that's that generative culture, where you don't care about how good your band did, or you care about how good the show was, how good the door was, because that builds up the scene.

So it really aligns well to that generative culture, to that scenius that Gene talked about.

But again, we want to talk about small things your technical team can do that you have full control over, that is going to drive you to that culture. I'm going to turn it over to Sat a little bit for that.

Sat Agrawal

Thank you, Robert. So I'm just going to try to go quickly, but you know, the devil is in the details. So let's go to automation.

Automating repetitive and error-prone human tasks can reduce the likelihood of failure, the risk of symptoms of failure reaching our customers. We don't want that. And what that does — it increases the reliability of our processes. And that in turn builds trust in the team's ability to deliver high-quality products quickly and consistently.

The great example is DevOps. We've heard this term so many times, right? When we organize engineers, developers with a support team — you build it, you run it, you grow it. Technical transformation, which emphasize automation, are catalysts to a culture shift by introducing a standardization of development and deployment practices.

Lastly, when we collaborate by breaking down silos between product development and operational excellence, teams can embrace collaboration and share ownership of problems.

When we automate, we have to create a standard. This is a shared agreement. We can feel comfortable holding ourselves accountable to, avoiding the need to be managed — let alone micromanaged. And Rob said that earlier.

Moving on to CI/CD. Implementing CI/CD practice helps ensure that the code changes are tested and deployed every time, and they're done frequently and reliably. This can create a culture of shared responsibility and accountability, as well as promote trust in the team's ability to deliver new features and/or fix issues quickly.

So practices — particularly practices like trunk-based development — we all pull and push to the trunk. So we all have changes, not just you. But along with that, good branch hygiene, such as short-lived feature branches — those are important. Once you do a PR, it gets merged. The feature branch is gone, and everything is deployed from the trunk.

Moreover, trunk-based development is a capability that's required to meet the goal of CD — continuous deployment, continuous delivery — not a goal in itself. Because if you are always releasable and can always deliver the latest changes to production — new features, new fixes on demand — using our standard process (which again, standard helps us hold each other accountable), we are closer to CD, which is the ultimate goal.

All right. That brings us to monitoring and logging. Implementing comprehensive monitoring and logging can help to detect and resolve issues quickly and efficiently. This can foster a culture of transparency and trust, as it allows team to see the impact of the work in real time and enable them to take proactive steps to prevent issues from occurring in the future.

So both monitoring and logging are important, because you have to learn to log enough data so that everybody has access to the same data — everybody knows it came from the same source. And monitoring allows you to create those alerts. So you proactively catch, "hey, I may be missing my SLOs," or "my customers are not getting that experience that we had promised them." And then teams can come together like 9-1-1 responders. They come together, they know the information, they quickly come and resolve it.

Collaborative tools. So, things like facilitating open communication. We all have Teams, Slack, right? That's a great place that you can come together — open communication, bring people together, talk about it. Fostering transparency. Wiki tools like Confluence allows you to put documentation, the knowledge that you have, progress, goals — so everybody sees that.

Encouraging active listening. Get on a video call with a team member or somebody else and hear them out, or let them hear you, to know each other's perspective. Promoting shared ownership. We all use GitHub, right? We use GitHub or Bitbucket. Many other tools where we work on the same project. Everybody knows what's being changed, what's being added.

Enabling cross-functional collaboration. We use Jira, we use Rally — so many. Cross-functional, so there's full transparency. We can do virtual whiteboard sessions with Miro, Lucid. And we can also use Jira and DORA metrics. So all these are great tools, but Robert told me earlier that when you use these tools, don't abuse them, use them. A great example — if you're doing a PR, get on a Teams chat with the reviewer, get it done, and then stamp it. Because you've got to stamp the PR anyway, right?

All right, so the fifth one: emphasize on learning and experimentation. This is very dear to me, because I'm an engineer all my life. So encouraging experimentation — give your team members, your developers, like 20%, 30% in a day or in the week, whatever, to do experimentation. Encourage them to fail. Learn from failure. Encourage them to do blameless post-mortems. Find what went wrong — not who did that wrong. Foster a learning environment, right? Encourage them to attend conferences — we are here, right? Encourage them to do learning from your internal teams.

Emphasize learning from failure, or decide that — recognize and reward learning. So if somebody did good, reward them, and make it organization-wide. Lead by example. Our leaders always lead by example. They show the growth mindset. They say it's okay to fail.

Some of the practices and tools that I think — we can do hackathons. Learning platforms — we have Udemy, Pluralsight, O'Reilly, so many of them. Innovative time off, mentorship programs, retrospective, design thinking. And last but not least — which is most important — system flow. It is very important as teams and developers to know how your component will affect the entire system. Because it's the what, why, when, where. Without the holistic view, you really would not know what your changes can have — big impacts. And I think the CTO of Sophie earlier was saying, this is very important. You have to ask questions to know how you're providing value through the system, right? Anything else you want to add?

Robert Clawson

You don't arrive at that — if Jon Smart were here, he'd tell you you don't arrive at that overnight. You have to have deep knowledge. You have to have deep understanding of the variance of how what you think you know varies from what's actually happening. You have to have psychological awareness of how your contextual problems affect your organization. And then you can really understand your system, your systems thinking.

Sat Agrawal

Absolutely.

Robert Clawson

But what all of these represent at a really high level are agreements. If we're coming up with automation, we're coming up with the standard that we can all hold each other accountable to. If we're trying to do CI/CD, we can make sure that we're constantly refining our pipeline, that we are not the ones breaking it, that we're always using the most recent branch — whatever it is, we can hold each other accountable to it.

Monitoring and logging — we know when our stuff's down. We don't need to be told when our stuff's down. We have alerts telling us that we're coming up on the threshold so we can be proactive about it. We don't have alerts that we ignore — we don't — everybody knows we don't need to worry about that. We take the time to knock that out and make our alerts actionable.

Collaborative tools, like I said, you can't abuse them. Working in isolation — most of us are introverts. It's a lot easier to do something and then throw it over to Sat for a PR. But if he's just going to rubber-stamp it anyway, let's pair on it. If we have a rule where you pair on everything, who cares if we just rubber-stamp it because two of us worked on it anyway.

The fact that we exist — the Discover Technology Academy — shows that we have support to keep learning, to keep experimenting, and we hold each other accountable for that. If we're doing user story mapping and you're not really paying attention, you're not really engaged, we should feel comfortable calling each other out. 'Cause it's going to bite all of us anyway.

Sat Agrawal

Absolutely.

Robert Clawson

Thank you, Sat. And leaders can do a lot here too. I'm on the product side. There's a lot we can do to help our technical teams as well.

We want to make sure that we align our product vision towards our technical goals. We do deep product discovery to make sure that with the value we're delivering to our customers delivers corresponding value to the business. It costs a lot of money to develop solutions, and we need to make sure that we are monetizing them in a way that's profitable, that keeps our teams long-living, our business sustainable. And let's face it — our customers sustainable. We can't stay around if they can't stay around to keep paying us.

And on to that note: when we learn something new, we need to support the response to technical change on the product side. When we're considering the desirability, viability, and feasibility of what we're preparing to deliver — if we discover that it's not feasible, we need to prioritize a different type of effort to either get this done, to pivot, to get something else done, to explore hiring contractors or other teams to help get this done. We can't just stick to a plan. We can't just keep driving when we have data in our face telling us to stop, turn, or slow down. So we need to really support that response. But we won't know it unless we have short, loud feedback loops and have frequent collaboration.

If you're meeting with your directors once a month, it's probably not enough. If you're meeting with them every other week, that's probably not enough.

We heard Carol [Gastal] from SiriusXM talk about how their weekly Friday demo really started building trust. What's a demo? A demo is that flow of information — information about what you've done, and then information back from your customer and stakeholders about how they feel about it. So amplify feedback loops. Theory of constraints is all about amplifying the feedback loops, making sure that our leaders understand the things that are making our work unfeasible, things that are preventing us from achieving our organizational goals.

And again, if our leaders aren't spending time in the trenches with our developers receiving that information, having the chance to challenge that information directly, they're not going to understand the context. They're not going to have that holistic picture of why our systems are failing.

One way they can do that is to be an internal customer advocate. Again, we talked — I talked about our deep product discovery. We want to make sure that the value we're delivering to our customers delivers corresponding value to our business. And that includes our internal customers — our engineers, our developers. Different concepts we've heard floated around here this weekend — were platform as a product, data as a product, right? Testing as a product.

When you treat your internal customers as importantly as you treat your external customers — when you have personas for them, when you talk to them frequently, when you prioritize things based on the value they articulate to you — you are making your product self-funding. You are making it chosen, and you make it evolving. You help your developers stick around, you reduce your attrition, you keep your developers happy. Taking that product approach to your processes, your services — the things that support your developers — absolutely paramount. And again, it helps with that flow of information, because your developers now understand that all your leaders want to do is get us closer to our organizational goals, and they're going to give you the technical tools to help you do that.

And then lastly — or second to lastly — prioritize experimentation and learning. Again, at Discover, we are very, very lucky. The fact that the DTA even exists, the fact that we have this technology academy, is a real testament to how we really embrace that part of our culture. And it aligns with our values.

Living our values is the last one. This is easy at Discover because they're very high level. When you set more prescriptive values and goals, you really limit your teams on how they can embrace them. But we know that as a technical organization, if what we're doing is in the name of playing to win, getting better every day, or succeeding together, we can challenge our leaders. We can provide value, we can provide data about that value, rub their faces in it, and they're going to support us.

But we're not going to pretend like this isn't hard. At Discover — you know, we've made headlines over the past couple years. Yes, this is really hard to do in a highly regulated environment like financial technology. We have really strict compliance requirements, and compliance is not "I'll deliver an iteration, see how I did, and get some feedback." You're either compliant or you're not. So we are struggling with really being able to embrace that learning as we go, and pivoting off what we learned, as opposed to more upfront planning. Because there are so many requirements regarding compliance that we need to make sure we're adhering to.

True. And the same is with attestation, audit, documentation. We're a financial organization. We need to be able to provide evidence of record, like I said — attestation. And that's a challenge as well. Those types of things are time-consuming. A lot of developers will consider it toil. But one of the things we really get to do in the Technology Academy with our immersive learning opportunities is get the chance to help teams make that documentation a byproduct of their work. So it's happening alongside what they want to do anyway.

Lack of transparency — again, tying it back to compliance — sometimes things aren't known intentionally, so that they can "get us," if you will. And that's always a challenge. And additionally, it's not just lack of transparency because someone knows; sometimes someone just doesn't know. We don't have the right expertise in the room, we don't have the transparency we need, and we made the wrong decision.

And lastly, we are in a high-risk industry. We're dealing with people's money. We're dealing with their ability to know how much money they have, their ability to spend money, their ability to acquire new customers, to process transactions for customers, to pay their bills. So we really need to be available. Our customers need to be able to count on us. They need to be able to trust us.

And we've seen that manifest in a couple of different ways. We've seen our communities really get built strong through innersource. If you saw — I forget his name, maybe Michael — Michael's talk on innersource. We use a lot of those principles at Discover to help build our communities. Sat's going to talk about some of those things.

Sat Agrawal

So I don't know if you remember, or Robert did say, about the Agile Way of Working, which is AWoW. That's a framework that we go by, but I take it a step ahead — I call it "Oh Wow," one Way of Working. So what that means is, like, by breaking down silos and encouraging cross-functional team formation — not an easy task — individuals are able to work together. You've got to do this every day. They can work together more effectively, and they understand each other's roles and responsibilities. What that does is it improves that trust, because team members can rely on each other to deliver on the commitments. And they also feel comfortable holding each other accountable, and they understand the impact of their actions on the entire organization.

So to bring people together, we have introduced a practice — same as open source. We call it OpenWorx, like W-O-R-X. What that is — it is a set of practices that promotes code reuse. So if somebody has a good library they're using and maintaining it, you can use it. You don't have to reinvent it. And also collaboratively do development using the core principles of open source.

Innersource is very powerful, because that really brings people together in that experimentation mode. They can try it, they can invite people. But it's a job on its own — to maintain an innersource project as a full-time job. But if you're passionate about it, you should do it.

So the first one that you see — Trident Pipeline — that's an innersource product that's been maintained very well. And what that is, is our DevOps pipeline. Highly opinionated. And Discover decided to make that a standard across all the product teams. You're going to use Trident to deliver, to build, tests, whatever — to deploy your products.

OpenWorx, like I said. OpenWorx also follows three Cs: which is Community of developers — internal Discover developers. The other C is Contribution. And the third C is Consumption. So if you're consuming, you also contribute. And contribution doesn't have to be code all the time. You can do documentation, design — there are many things.

So innersource became so powerful that one of our open source projects — we actually handed it over to FINOS last quarter. And why is that? Because we were looking for a larger community to contribute to that Theme Builders. Actually, it closes the gap with digital accessibility for developers. It produces consistently accessible products to promote DE&I — and of course, in risk compliance.

Robert Clawson

And yeah, the reason we turned it over to FINOS — or "Finos," whoever you say it — that really eliminates a lot of the risk from us at Discover. They can worry about a lot of the security. The project is outside of our firewall — we can really start getting outside contributions.

Sat Agrawal

Absolutely. Absolutely. So this one that you see — these are actual sayings or quotes from application engineers, principal engineers — because they have really started using these practices in their daily lives. You can read them. But what I want to really emphasize here is — here is why this can really make an impact. Teams who deploy easier are happier, right? We all done that. Have more time to innovate and develop themselves. What this does is enables the autonomy to scale up mastery. As we get new apps, new teams on the same deployment process, and the purpose — we see increase in team and the profession.

So in fact, Jon Smart actually says this: when people have their intrinsic motivations fulfilled, they're less likely to leave or unthoughtful in the work, not checked out, and more likely to be engaged and creatively driving towards desired outcomes in effective ways.

Robert Clawson

So in short, we'd like to kind of leave you with these three pillars that are really going to help your kind of top-down culture requests going to actually make it happen.

Make sure that you have an obsession with technical excellence. Make sure that your teams — the teams you have control over — get gradual, practical guidance on their problems contextually on their products. And that's going to help build their trust. Help them hold each other accountable so that they don't need to be micromanaged, so that their leaders can actually do what they need to do. And make sure you're supporting innovation. Give them time to learn. Give them time to fail forward in the name of our organization's goals.

Really empower teams with the flow of information. Nurture that scenius at your organization. Get to that generative culture where you're only focused on your progress towards your organization's goals. Why OKRs work well is because your team should align up to your organization's. And if you don't know your organization's and how yours aligns up, that is a lack of information flowing.

When we build teams that are truly cross-functional, when everyone on the team can do everything the team needs to do, we can all deploy. We don't have any dependencies. We have embedded architects, we have embedded QA, whatever it looks like. That's a real cross-functional team. If you have dependencies, more than likely you're not.

Radiate transparency — that flow of information. Talk to your leaders more than once a week, more than once a month. Good googly — more than once a quarter.

And then lastly, diversify teams. There's a lot of evidence out there that shows working with diverse teams welcomes diverse perspectives. We obviously take this pretty seriously. We don't look alike, we're not from similar backgrounds — we really like working with each other. When you build products with more diverse audiences, they are adopted by more diverse audiences. So your products will be more adoptable, your teams will have more diverse, more thoughtful ideas that lend to that adoption. And you're going to learn — you're going to learn from each other's backgrounds. You're going to learn technologies that you didn't know before.

When you really obsess over these things — over that technical excellence, diversifying your teams, and radiating that information flow throughout your organization — you're naturally going to lead to that generative culture.

Sat Agrawal

True. And that's all we've got for you. You can keep up to date about what we're doing here at technology.discover.com. You can scan that. We've got some blogs, we've got some videos about what we are doing. And that's it. Thank you very much.