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.
We're discussing engineering excellence with Dan Drasin, Chief Development Officer of Shift4.
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.
Dan, you're chief development officer. What does that encompass, that role?
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. You talk a lot about the concept of
engineering excellence. Tell us about that. 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.
You're trading off time, cost, and quality, essentially, the features, number of features.
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.
How do you make these decisions of where to balance?
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. 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. 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.
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? 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?
Again, all of this rolled up together ensures the alignment between software development, product
development, and the ultimate business strategy. 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.
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.
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. Dan, it sounds like you're very
philosophically aligned with Intevity around the importance of bringing together the business
strategy and the software development. 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.
All of this sounds great, but how do we measure? What kind of KPIs,
metrics, measurements do you use? 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,
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. Some organizations also look at KPIs in
areas such as adoption, operations, ROI. Do you think about it that way as well?
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.
Dan, you've been alluding to this without saying the term, but where does governance
fit into this concept of engineering excellence? 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.
Dan, how do you build a culture of engineering excellence?
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.
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?
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.
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?
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. 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?
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.
Once an organization has started this journey, what advice do you have for making it as simple,
as easy, as successful as possible? 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.
Dan, how can folks make this journey as simple, as easy, as successful as possible?
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. Dan Drasin, Chief Development Officer of Shift4,
it's been a fascinating discussion around ensuring that development aligns with
business goals. Thanks so much. Thank you for having me.