How do you make incredible software?
You might think one way to do it would be to hire the most amazing designers, testers, and developers you can find, equip them with top-notch hardware and software tools, give them a room with a bottomless fountain of caffeine, hand them a deadline and some requirements, and then just walk away for a few weeks. Pop in to check on them every now and then, but they’ve got this, right? No worries if anything changes or they run into problems. They’re smart and they know their individual roles well. They’ll figure it out. Won’t they?
Well, maybe they will. But what happens if they don’t? What would that mean? Would it mean they weren’t as smart as they seemed? Would it mean something is wrong with the plan, or the requirements they were given? Would it mean they needed more management telling them what to do or when to do it? “It seems like we started with all the right things. Why weren’t we more successful?” This is the question leadership would be asking, and it’s a question with an answer — maybe just not the one we might expect.
It starts with people
To start thinking about why a setup like this one might be vulnerable to failure, consider that the words ‘person’ or ‘people’ don’t appear at all in this story — just abstract functional terms like “designer” or “developer”. The thesis seems to be that all that is needed for success is for the right kinds of experts to be on the project with the right set of instructions. This is a common — but at best only a partial — view of what a software development team should be. Two critical ideas are missing.
The first is that skill sets are attached to human beings. Humans get tired. They get along with each other, or don’t get along. They don’t just have professional opinions about their work, they have feelings about it, and those feelings affect what they do and how they do it. They have lives, partners, families, and pets outside of work. They experience illnesses and have struggles others may never even know about. All of these things are in the room with them when they’re working. Focusing only on their functional area of expertise brackets their humanity in a way that just isn’t realistic.
The second missing idea is that in order for these highly talented, wonderfully complicated humans to make software, they have to combine their knowledge and experience and work together as a team. Creating software involves working through complex problems with multiple possible solutions. Humans with expertise will absolutely have ideas, preferences, and a history of things they’ve tried and how they worked out on other projects. They may interpret requirements differently and need to get aligned, or need more information in order to understand stakeholder priorities. There is going to be a lot of conversation, and most likely some disagreement. Some of that disagreement has the potential to test their ability to work well together. If enough attention hasn’t been paid beforehand to fostering a sense of safety and belonging, in times of high stress, like when dealing with deadline pressures or high-stakes change, they may lose their cohesiveness as a team.
Because the philosophy of Detroit Labs puts people first, these are core realities that we embrace as part of what gives this work meaning and importance. “People first” is more than just a slogan. The clearest illustration of this is in the role of Delivery Lead.
The secret sauce
Every Detroit Labs team has at least one Delivery Lead. In addition to project management duties, Delivery Leads are accountable for team health and morale in the broadest sense. They facilitate supportive and respectful communication both within the team and with stakeholders, assisting in the evolution of constructive norms of disagreement and decision-making. Facilitating communication across roles is just one way in which Delivery Leads foster a sense of cohesiveness and inclusion on their teams that helps team members feel safe, supported, and valued.
Delivery Leads also collaborate with stakeholders in client leadership to make sure the team produces the work with the highest value possible. Knowing they’re working on what’s important energizes the team and helps enhance focus. It also ensures that client priorities are well understood and appropriately prioritized. Where the team needs information, client resources, or domain expertise that doesn’t exist on the team, the Delivery Lead is there to see that those needs are met as well.
Finally, Delivery Leads operationalize Detroit Labs’ commitment to a people-first approach to making great software by making sure that all team members, as much as possible, experience a productive harmony in their work-life balance. They help rebalance workloads in ways that are equitable and in alignment with team member strengths and energy levels, and they watch out for unsustainable patterns of overwork that lead to stress and burnout. When a team member needs time off, the Delivery Lead makes sure they have coverage so the work can go on while the team member is away. In these and other ways, Delivery Leads make sure that the team continuously has the balance of skills, energy level, and understanding necessary to meet the demands of the project.
This post started with the question, “How do you make incredible software?” The Detroit Labs answer is firmly anchored in the belief that, in the end, technology is about people. We make it because it helps our clients improve people’s lives, and we make it in the people-first way that we do, with Delivery Leads on every project, because designers, testers, and developers are more than just their skill sets. They are people, too. Centering that fact at the heart of what we do makes our teams resilient and adaptable, and creates the conditions in which their talents can truly shine.
