Since starting at Frogslayer in 2019, I’ve worked on both the client and non-client-facing sides of projects. I started my career as a software developer and transitioned to the role of delivery lead in early 2022.
To better serve our clients and contribute to our team, all delivery leads here have a strong background as software developers.
While these positions do have their differences, throughout my time in both roles, I’ve found quite a few similarities between developers and delivery leads.
Both are valuable and essential to a productive team, and I’ve enjoyed my time in both positions. In this blog, we’ll define and discuss the differences and overlaps between the delivery lead and software developer roles.
Differences Between Software Developers and Delivery Leads
Working with Code vs. Working with People
When working with code, there usually are specific and understood ways to implement a piece of functionality. Most of the time, when you don’t know something, you can look up documentation, search Google for someone doing something similar, or ask a colleague. These resources can help you through many of the issues you might encounter.
As a delivery lead, however, you work with processes and people. While the processes can be Googled or found in the documentation, there’s no manual explaining why the product owner (PO) or client wasn’t thrilled at the last sprint review.
However, there is a way to figure it out, though—you can talk to them.
For example, a product owner may seem unexcited about some recently completed work. Without a conversation, it’s easy to make assumptions. Like everyone else working on the project, the PO has things going on outside of work. The lack of enthusiasm might come from something as random as returning from a dentist’s appointment after finding out they have a cavity; you won’t know this, though, unless you talk to them.
When working with code, you can investigate an issue with the help of logs, debugging, docs, etc. When working with people, it often takes a conversation.
Accountability or Responsibility
Accountability and responsibility are often used interchangeably but actually have different meanings and understandings. Being responsible for something means you’re committed to getting a specific task done. Being accountable means you’re the one questioned when a task isn’t done or done right.
Let’s use a product backlog item as an example: a technical lead is accountable for finishing a work item in a sprint. He assigns that item to a junior developer, who then becomes responsible for getting that work done. Although the junior is responsible, the tech lead must still oversee its completion and answer any questions or potential problems with the outcome, making him accountable.
As a developer working on a project day-to-day, you have different work items or tasks you’re responsible for completing. As you enter the technical lead role, you become accountable for groups of items or the whole sprint. You’re likely still getting in the code occasionally and need to understand how the product works to define your approach to getting the work done. Tech lead or not, all developers contribute directly to a team’s velocity.
While delivery leads might not contribute directly to velocity with code, they’re responsible for many things that allow developers to do so, such as gathering requirements, defining items, scheduling and running meetings, etc. In my experience, initially, it wasn’t easy to accept that I was accountable for the work being done but not directly responsible for it.
The bottom line is that accountability and responsibility are key distinctions between developers and delivery leads. Developers are responsible for completing work, while delivery leads are accountable for delivering that work.
Dopamine Hits
As a developer, the feeling of implementing a new feature or finally resolving a bug gives a nice dopamine rush that lets you immediately know things are going well. It’s a great feeling that can have a bit (or a lot) of lead-up, with varying degrees of wanting to smash a keyboard involved, but in the end, it always feels great to get some piece of functionality working as intended.
As a delivery lead, you may feel similar when a sprint review goes well, when you get some good feedback in a retro or from the PO, or when the big release goes out on time. However, sometimes, those things can feel more like a sigh of relief than excitement.
The way those “rewards” come back to the delivery lead is also different; it’s more of a delayed response rather than the instant gratification that comes from compiling and immediately seeing the results of your work. That sprint review was a couple of weeks in the making; the good feedback could’ve been from a few sprints of minor process improvements, and the big release could’ve been months of work to help get the team everything they needed.
Both roles are challenging and have both small and big wins but are generally rewarding in their own way.
Overlaps & Similarities Between Software Developers & Delivery Leads
Debugging “Issues”
While these roles are unique, they do overlap in certain areas. One similarity I’ve found between them is the approach to resolving or debugging issues.
As a developer, it’s easy to get caught up in focusing on specific things to investigate when trying to fix a bug. Sometimes, this ends up being worth it, and there really was an issue deep within a service that hadn’t been touched in years. Other times, it’s good to remind yourself to take a step back and ask if you really need to be scrounging through documentation to fix an endpoint that isn’t working. Or you might simply have a typo in your code
On the project management side, let’s say, for example, there’s a situation where you need the team to investigate how long reworking a core part of the app would take so the client can switch up their workflows based on the person they are speaking with on the phone. That core functionality change could be deemed unnecessary by looking into the business goal the client has in mind rather than just accepting their initial request.
For both delivery leads and developers, diving too deep into the technical weeds can happen more often than not. Next time there’s a bug in the code, you’re spinning your wheels trying to lock down requirements, or the PO is asking for things they don’t need, take a step back and ask yourself a few basic questions
- What am I currently doing?
- How does this relate to the root issue/goal?
- What is the root issue/goal?
- Is that really the root issue/goal?
Prioritization and Risk Assessment
Prioritization and risk assessment are fundamental aspects of all jobs. They come into play at certain levels for all team members.
If you are a developer, you might be deciding whether to refactor a piece of code or complete a feature first. Or, if you are a delivery lead, you may have to prioritize tickets in the backlog. For instance, in a collaboration between a developer and a delivery lead, they may need to determine whether fixing a bug the client reported should be done before releasing the product to production. All these scenarios require assessing risks and prioritizing tasks.
The main takeaway I’ve gathered from being in both roles is that prioritization and risk assessment should be back-and-forth. There shouldn’t be one person who is the be-all and end-all on a topic. That’s not to say someone shouldn’t get the final say or make the decision, but challenging each other brings out productive conversations and the best results.
Something that may seem small to a delivery lead, like a minor bug, might have sweeping ramifications if left unchecked. Or some technical debt that the development team thinks should be done now might have a better spot in the next sprint after the client gets the new shiny feature they’ve been asking for. Of course, either of those could go either way, but the main thing is that everyone discusses and understands the items to make informed decisions.
Part of the Team
This last one seems obvious but is definitely worth discussing. As a delivery lead and a software developer, you’re part of one team.
Sometimes, people have different feelings when they see ‘lead’ in someone’s title, but as a delivery lead, you’re leading just that—the delivery of work to our partners. Sure, there will be times when you need to assign work to people or take on that leadership role a bit more, but overall, you’re all on the same team working towards the same goal.
This teamwork mindset feeds into morale and effectiveness when everyone feels like they’re working on the same thing, and the delivery lead doesn’t only appear to scold when things go wrong or bask in accomplishments.
If you’re a delivery lead with domain knowledge for the project your team is working on, sit in and help work through problems. You’re also an available resource for the team. The other way around is also true. Maybe you’re a developer looking to get into leadership. Step up where available and ask to share some responsibilities with the delivery lead, like running reviews or retros or helping with business reviews.
The main point I’m making here is even though you might have different titles, don’t explicitly divide the team based on that. You all have the same goal and should work together as a team to achieve that goal. Everyone has the capability to help out, even if they’re not an expert in the subject. Sometimes, a fresh set of eyes is all someone needs to get the right train of thought going.
Final Thoughts
In the last few weeks, I’ve transitioned back to working as an Associate Software Developer, and reflecting on my time in both positions has been enlightening.
While both roles have unique challenges and rewards, they share a common goal: building high-quality software for clients while minimizing risks and never over-promising or under-delivering.
-
Austin Elsik
