How to Achieve Software Development Excellence

Dan Drasin: A lot of times companies just bring a consultant in and they think of them as a craftsman that will solve a particular technical problem. They say, "Go do X, Y, and Z." But it's really critical for the consultants that come in to understand the big picture and take a holistic approach.

About software engineering at Shift4

Michael Krigsman: We're discussing engineering excellence with Dan Drasin, Chief Development Officer of Shift4.

Dan Drasin: Shift4 is an e-commerce enabling company. We do over 3 billion transactions a year and we process those transactions for over 200,000 customers worldwide.

Michael Krigsman: Dan, you're chief development officer. What does that role encompass?

Dan Drasin: At Shift4, I'm responsible for all software development. We think of three basic pillars. We have our customer-facing applications. We have our payment platform that processes transactions. And we have our internal systems that are sort of the foundation or operating system for our company, if you will.

What is “engineering excellence”?

Michael Krigsman: You talk a lot about the concept of engineering excellence. Tell us about that.

Dan Drasin: It's really important that we build systems that have the right balance between different qualities. The first thing I think is important to have in mind is you've probably heard of the iron triangle before that all software development has to obey.

You could choose how much you want; how rich it should be in features. You could choose how much you want to pay for it, how costly it should be, and you can choose how fast you want it done.

But you can't set all those parameters to be anything you want. If you want it to be really fast, you may have to make some compromises in feature set or perhaps quality.

Engineering excellence is about having a strategy for where on that iron triangle you want to be for the particular problem you're trying to solve, for the particular customer target base (if you're product company), and then it's about execution to make sure you optimize for where you're trying to be on that iron triangle.

Michael Krigsman: You're trading off time, cost, and quality, essentially, the features, number of features.

Dan Drasin: In the last 25 years, there's really been a lot of work done to give development teams and companies more options on how to do that. A lot of product companies, it's really important to get into market very quickly and maybe with what they would call a minimum viable product, which kind of implies that you're going to go emphasize speed, and you may not worry about feature set as much.

It doesn't mean that you're going to produce bad quality. It doesn't mean that you're not going to make a great product eventually. It just means that you want to make sure that you can get into market as quickly as possible and then potentially iterate from there.

Michael Krigsman: How do you make these decisions of where to balance?

Dan Drasin: Every company is a little different. For us at Shift4, getting into market in new verticals is really important. And so, for those projects, we emphasize the time to market aspect of it. In some of the other verticals that we're in where we have more established products, it's more around feature set and quality that we dig into.

For both of those cases, though, we leverage a version of scaled agile which allows us to iterate very quickly. It allows us to get releases out to our customer base quickly. And most importantly, then get feedback from those customer bases as to what we've done well, what we need to improve on, which helps advise us on how to do the next iteration.

Michael Krigsman: But how do you make the decision of whether to add features or reduce cost, for example? Those are very tough engineering choices and product design choices.

Dan Drasin: We have a group of people who are figuring out, looking at the market, figuring out what needs to be done and what are the timeframes that make sense. They have something; we'll call it a backlog, a product backlog. They're working on that. These are people who are very familiar with the product space.

At the same time, we have groups of engineers or, let's say, development professionals who are not just engineers but quality professionals, analysts, who are working on the actual code. They're looking at what's in the product backlog and the teams that are available. They're sort of deciding which things can we make the most progress on the most quickly.

We found that two weeks is pretty good for us to get an idea of we build something, get a reaction from the product team as to whether we've built the right thing. If so, we push it out the door, get a reaction from our customers in terms of how well they like it.

How Shift4 aligns software engineering and product development with company business strategy

Michael Krigsman: All of these small, very frequent decisions ultimately roll up to the business strategy. This is the mechanism by which you align software development with the higher-level business strategy. Is that a correct summary?

Dan Drasin: One hundred percent. It's a case of constant adjustment. I used the word engine before, I think, and it's like a multi-stage engine which has different characteristics that you're looking at as you move through that process.

At the very beginning, the folks who are thinking about the product are looking at things like market potential and what are our competitors doing and what's the total of available market to be attacked. They prioritize the work based on that.

You can think of that as strategy. It's sort of in that strategy sphere. But it does also get into some of the more practical questions about how our users are going to interact with this. It gets into application design questions.

As we move through that engine, it gets now into smaller, more detailed questions of, well, how quickly can we implement that feature? What language should we use? What technology is going to help meet those objectives?

Michael Krigsman: Again, all of this rolled up together ensures the alignment between software development, product development, and the ultimate business strategy.

Dan Drasin: You have an organization. You may hear the term in agile scrum called scrum of scrums where you have designees from each of the different teams that are working mostly in parallel but they still have to be coordinated at some point to make sure that the problems that they're running into are addressed and understood by the other teams.

Michael Krigsman: Your engineering organization is also structured to reflect this kind of iterative, almost fractal-like mirroring across its different parts. Then you have an overarching coordination layer.

Dan Drasin: If you have all of these different layers that have to interact in different ways, it's probably obvious that a typical hierarchy in an organization can't really do that. So, we really operate as a matrixed organization.

We certainly have reporting relationships, but we have lots of other relationships in terms of how we organize that are outside of, let's say, the traditional hierarchy.

A great example is you might have an engineering manager that has a lot of engineers report to them, and a QA manager with a lot of QA professionals reporting to them.

Working with Intevity to align business strategy and software development

Michael Krigsman: Dan, it sounds like you're very philosophically aligned with Intevity around the importance of bringing together the business strategy and the software development.

Dan Drasin: Absolutely. When it comes to consultants, in general, I'm pretty skeptical. I think that using consultants is a really important lever, but it's also one that can be tricky (just in general) because you need to make sure that all people on the development team are aligned to a common outcome and sort of have the same cultural background and are basically pulling in the same direction.

A lot of times companies just bring a consultant in and they think of them as a craftsman that will solve a particular technical problem. They say, "Go do X, Y, and Z." But it's really critical for the consultants that come in to understand the big picture and take a holistic approach, which means they need to understand what kind of strategy the company has.

You have to be able to quickly come in and understand a domain and be able to ask the right questions. Intevity has done a great job of that every time we've brought them in.

I think it's really important to make sure that you're using consultants who understand your goals, who can understand the business problem and who have tools to help dig into that. Know how to build models, know how to do analysis and design and not just, let's say, throw code.

Michael Krigsman: All of this sounds great, but how do we measure? What kind of KPIs, metrics, measurements do you use?

Dan Drasin: As a product development organization, we want to get our products out quickly. It's very important for us to be agile and fast. And so, a lot of these rigorous techniques that I'm talking about are difficult for us to implement and achieve those outcomes.

I call those output KPI, first-order KPI, and we use what I would call second-order KPI, which are more internal measurements of our SDLC (software development life cycle), that engine that I described earlier. Rather than looking for absolute numbers saying we want this number to be 10 or 20 or 5 million, we're looking for gradual improvement of those second-order KPIs.

What are important KPIs to achieve engineering excellence in an agile development environment?

Michael Krigsman: Some organizations also look at KPIs in areas such as adoption, operations, ROI. Do you think about it that way as well?

Dan Drasin: Absolutely. Those are all part of what I would call the second-order KPIs. There are a couple of different areas where we really look at this.

In an application, you want to understand how users who are interacting with that application are using the functionality that you put in there. If you put out a new feature, you want to know that people are actually using that feature.

You can look at what's called cohort analysis to try to understand the pathways that people follow through the application. Are they successfully able to use the new feature? Do they stop using the application (sometimes called abandonment)?

Those kinds of cohort analyses are really helpful to understand that aspect of the problem. But you also want to understand the technical side of it.

We put out a new feature. Is it now using twice the CPU or memory that it was before? These are the operational metrics that you also want to keep an eye on. That's why people don't use it.

Software governance to achieve engineering excellence

Michael Krigsman: Dan, you've been alluding to this without saying the term, but where does governance fit into this concept of engineering excellence?

Dan Drasin: Governance is really about making sure that you are doing what you say you're going to do or say you are doing. And so, the framework we use for thinking about governance is as a layer of visibility on all those different engines that I talked about, the software development lifecycle and the scrum of scrums, vertically.

You need to make sure that you have a way to have insight into what's happening across each of those processes and workflows. Governance is about making sure that you not only have that insight but that you have people who are responsible for validating that the insight tells them that things are going well.

Product ownership is a key part of that. But then you also have governance around the technical aspects as well.

Certainly, we talk about metrics for operations. Are we using more memory than we should? Is the cost per unit of processing too high?

Then you also have what we traditionally think of, of course, as governance which is around things like security and data stewardship. Governance is that last piece where you actually look at the outputs and validate the way the project or product is proceeding matches your original expectations at the beginning of it.

Michael Krigsman: Dan, how do you build a culture of engineering excellence?

Dan Drasin: You need to establish a culture where everybody enjoys coming to work, they enjoy the project that they're on, and they want to win together.

The second part is then you have to establish a software development process (that we talked about earlier) that encourages a meritocracy, that encourages good development. And when you have bad development, you recognize it, and you correct it.

Michael Krigsman: Developing this kind of culture doesn't just happen magically. How do you train your folks to fit in and to enjoy and flourish in this kind of culture?

Dan Drasin: It starts with the hiring process. You want to make sure that, as you bring people into the organization, you're signaling them that this is a culture that's fun, that's highly collaborative, that is a meritocracy, and that they can excel and have career growth.

Even starting with simple processes like asking the employee, "What are your career aspirations? What would you like to do?" and doing it in a consistent way across the company. Once you have that information and you're creating dialog around what people want out of the culture and what's important to them, it becomes very straightforward (in many cases) to simply provide that.

Michael Krigsman: We live in a world where demographics tell us that, for years to come, it's going to be hard to find the best people. There's so much competition. How do you manage that?

Dan Drasin: We know that there are a lot of challenges when we have to work remotely. As simple as it sounds, sometimes we have a casual chitchat over our Zoom meetings, so we have a Zoom meeting that isn't around anything technical but it's just about talking about what's going on in our lives where we try to build some of that same rapport that happens naturally around the watercooler. But there are lots of other techniques as well where you might have an opportunity to travel and meet each other.

Advice to technology leaders on agile software development success

Michael Krigsman: Dan, as we finish up, what advice do you have for business leaders and technology leaders who want to start this journey to be more deliberate in their approach to engineering and to align engineering with the business goals?

Dan Drasin: I think there are two main areas of advice. The first relates to what we were talking about culture. And it's really the sort of opposite use case from establishing a great rapport that we discussed earlier.

That means you have to jealously guard that trust and that meritocracy that you establish, which means you sometimes are going to have team members who don't align with that. You need to be very, very focused on making sure that you – forgive the phrase – remove the bad apples because while most engineers are going to be diligent, that doesn't mean every single one of them. You have to take seriously any threats to the culture you're establishing and be very, very forceful in making sure that you protect that culture.

As a leader, you really need to look and care about every single team member. Their outcomes not just of their projects but of their careers. You really have to genuinely care.

Michael Krigsman: Once an organization has started this journey, what advice do you have for making it as simple, as easy, as successful as possible?

Dan Drasin: I think it's important to have people who have been there before as part of your journey. You're always going to have people learning and developing new ideas.

But you also have to have people who have some experience because they know what mistakes are easy to make. You'd rather learn from someone else's mistakes than your own.

But at the same time, you want some people who are looking at things with new eyes. It's that blend of experience and, let's say, young, youthful exuberance that makes a perfect combination for new product development.

Michael Krigsman: Dan, how can folks make this journey as simple, as easy, as successful as possible?

Dan Drasin: I think the most important bit of advice I would give is to have some people who have been there before, which means bring in some people with experience to help augment your team. It doesn't mean that you need a team full of journeymen who have been doing this for decades, but a small number of people who have made the mistakes before can help you, as a team, to avoid some of those same pitfalls.

Michael Krigsman: Dan Drasin, Chief Development Officer of Shift4, it's been a fascinating discussion around ensuring that development aligns with business goals. Thanks so much.

Dan Drasin: Thank you for having me.