Article summary
Atomic is adding a new type of maker called the Delivery Lead to our lineup. Recently, we’ve recognized ways to enhance the experience of our clients and teams and build better software in the process. The Delivery Lead position is the result of more than a year’s worth of experimentation in this area. As one of the first to hold that position at Atomic Object, I’d like to introduce the Delivery Lead role and share the context for how we got here.
Later in this article, I’ll delve more into what a Delivery Lead is and does. For now, the broad definition is that Delivery Leads are responsible for collaborating on and co-creating products with our designers, developers, and clients in the areas of communication, project and product management, and high-level product architecture. It’s our job to be the client’s proxy for the team when the client isn’t available. We make sure the team is unblocked, and we keep everybody in sync, marching towards the product goal.
How We Got Here
Our company turns 15 this year. Over our history, we’ve gone through a couple of phases and evolutions in our quest to make great software.
Atomic Object came onto the scene in 2001 during a very different era in the software world. Most consumer software was delivered on CD-ROM. Releases were very expensive, and bugs were rampant. Code quality was very poor.
Extreme Programming (XP or agile) was born as a reaction to these circumstances. Our company utilized XP practices and focused on building high-quality, bug-free software. And we were very good at it.
Soon, Atomic realized that high-quality software was useless if it wasn’t also useful and usable. We began engaging more with our clients at the product level, and we added designers to our teams. We were one of the first companies in the agile movement—or any software environment, really—to embed designers in development teams, rather than creating a separate design department. Our core belief was that without walls (either physical or conceptual) between the members of a product team, we could create better software.
Delivery Leads: Our Next Evolution
Since our company’s inception, one of our peculiarities (and perhaps a point of pride) has been the lack of project or account managers who sit between the client and the product team. Instead, our designers and developers interface directly with our clients, truly becoming “their team.” One key criterion in our hiring process is that our makers must be willing and able to be true consultants—not only doing the work of design or code, but also working directly with stakeholders to solve problems, create innovative solutions, and generate buy-in.
Traditionally, we’ve designated one maker, typically a developer, as the Project Lead. Our Project Leads have been responsible for running point on communication, keeping an eye on budget burn and backlog, and steering the ship in the right direction. They would do all this while also working as full-time developers on the project.
For some smaller projects with a single, highly engaged client stakeholder, the model I described above works okay. For more complex projects, it doesn’t. Additional stakeholders, integrations with other platforms or IoT devices, or working with a development team inside our client’s organization can often pose complexities.
Managing a software project under those circumstances can be close to a full-time job, and our clients are often very busy people whose time is allocated to other efforts within their organization. They don’t always have the bandwidth to stay deeply engaged with their Atomic team on a daily basis and be highly responsive to communication. When you compound this situation with the other responsibilities our senior makers face (mentoring, supporting older projects, company leadership, etc.), it can create stress for project teams and missed opportunities for our clients.
When we observed these factors, we decided to take action. Before officially creating this role within our company, we spent more than a year prototyping the role within teams and exploring what it could look like, what the responsibilities would be, and what type of person would be the ideal Delivery Lead.
In trying to explain the Delivery Lead role, it can be helpful to talk about what the role is not.
A Delivery Lead is not a product manager (but we’ll help you out).
In software, a great product manager is a subject matter expert who deeply understands his or her industry and target demographic. The product manager is also a visionary who can pinpoint not only where the industry is right now, but also where to innovate and take it to the next level. Product Managers gain this understanding through experiential knowledge (i.e., they did the job once) as well as deep, ongoing research into the field and target users.
My client Jim is a great example of a product manager. He’s a veteran educator with more than 40 years’ experience in the classroom and in teacher professional development. Jim leads a team of specialists at the Van Andel Education Institute who have developed innovative frameworks for science and engineering education.
Atomic makers are smart, curious people who are great at quickly getting up-to-speed and developing a working knowledge of our clients’ domains. Learning about so many industries and finding the connections between them is one of my favorite parts of being a software consultant.
It’s also a key benefit for our clients, because working across different industries allows Atomic consultants to bring best practices and creative solutions from one industry vertical to another, applying cross-discipline insights in new and exciting ways. We make it our mission to understand the habits, motivations, and goals of our clients’ target users, employing human-centered design tools like personas, journey maps, and contextual research along the way. However, no Atom can get up-to-speed enough to replace an engaged, experienced subject matter expert like Jim.
It is entirely possible, though, to shift a subset of the less-important product management responsibilities from people like Jim to our Delivery Leads. Delivery Leads work closely with our clients to outline the basic vision, goals, and requirements for each feature. Then we work with the team to meet those goals, checking in with the clients as necessary. We work to understand clients’ high-order priorities, and then we groom the backlog and juggle the team’s day-to-day operations to meet those priorities. This frees up our busy clients to focus on high-value areas where their deep subject matter expertise is needed, while allowing our teams to act quickly and optimize for maximum throughput.
On a day-to-day level, Delivery Leads can act on the client’s behalf to make “micro decisions” about the product. Should we add a little more polish to this feature, or should we call it done and move on because we need to meet our deadline? Should we invest lots of time pursuing an edge case that happens in very few situations, or should we save that for later, because it would be a costly, low-return effort and we have a more important feature to work on right now?
In more complex situations involving competing goals or difficult tradeoffs, the Delivery Lead can come up with a set of possible solutions and present the pros and cons of each for our clients, taking some of the legwork out of the process. When Delivery Leads work with the team to make these judgements and escalate the issues to our clients when necessary, our clients’ inboxes are less chaotic, and our teams run more efficiently.
A Delivery Lead isn’t a designer or a developer (but we were at one point).
This is a direct departure from our previous model, where project leadership was tacked on to a designer’s or developer’s role. Delivery Lead is a new discipline and position within our company—a craft that requires its own professional development and deserves a spot as a key player on our roster. We also hope that even when Delivery Leads are responsible for multiple projects, the context-switching burden will be lower than that of switching between design/development activities and Delivery Lead activities.
As we transition to this new model, especially in our smaller office in Ann Arbor, some situations will still call for makers to act in a hybrid role (i.e., an allocation that looks like 50 percent Delivery Lead, 50 percent Designer or Developer). However, our long-term goal is that hybrid assignments will become fewer and far between, or even be eliminated entirely.
Though the Delivery Lead’s role is not dominated by design or development work, each Atom in the new role has several years’ experience as a designer or developer. They bring that experiential technical knowledge to the role and apply it every day. Delivery Leads may not do detailed interaction design, like choosing colors and creating icons, but we engage with the team’s designer and the client to outline and document the workflows and architecture of the application.
Delivery Leads may not write code, but we will work with the developers on their team to make sound technical choices about tools, architecture, and implementation strategies, and set the product up for success down the line. We help work out the high-level vision, continuously refine that vision, and keep the team marching towards it.
A Delivery Lead is not a project manager (but we do that, too).
Delivery Leads definitely engage in typical project management activities and practices. We’ll be tracking and reporting progress and spend, and we’ll be the point people for all communications and logistics related to the project team. It’s our job to manage the backlog, jump on e-mails as soon as they come in, and keep the team running smoothly. But, as we’ve seen above, the responsibilities and participation go beyond managing communication channels and tracking and reporting on project progress.
A Delivery Lead is a maker.
Though we may not produce code or designs, Delivery Leads contribute to the productivity of our teams and have a huge role in defining and shaping products, in collaboration with our clients and our designers and developers. Sometimes, the artifacts we create will be tangible, such as architecture, workflows, spreadsheets, plans, prioritized backlog, annotated user stories, and documentation of decisions. Just as often, our work will be ethereal and intangible–conversations carefully crafted, meetings well-facilitated, logistics conquered, consensuses reached, difficult decisions worked out. The result is happy project teams, software delivered on time and budget, with no surprises, and the greatest possible value achieved for the resources that were spent.
We’re just getting the Delivery Lead practice up and running at Atomic Object. I’m sure we’ll have more experiences to share and lessons learned along the way. Stay tuned.