I’ve been working on our project teams at Atomic as a Delivery Lead for quite a few years now. Before that, I served our teams as a software designer. Recently, I realized that many of the working methods I use as a Delivery Lead are rooted in the Design Thinking practices I learned as a designer.
Today, I am going to share a few of those practices with you. If you are someone who leads a team and/or reports information out to stakeholders, this information is for you!
1. Don’t underestimate the power of a good visual.
It shouldn’t be surprising to hear that designers are big fans of visual communication.
However, in today’s more remote setting, it can be easy to get swept up in mostly written communication. Everyone is on Slack, emailing, or using project management tools like Basecamp or Asana. We might hop on a Zoom or Teams call to verbally chat, but where are the visuals?
Don’t let visual communication fall to the wayside! A good visual often makes information easier for folks to consume and comprehend.
Your visuals don’t need to be fancy or complex. In fact, the more simple you can keep them while still communicating your message, the better.
For example, I had a customer who did not care about the nitty-gritty details of our development backlog. I could see their eyes glaze over when I’d open up Jira. However, they did want to make sure that their own product and design thoughtwork was happening far enough ahead of the development team to keep the team fed with actionable work to do.
To solve for this, our reports included a simple “health of backlog” indicator. We represented this with a green, yellow, or red color. Green meant we had over three sprints of actionable work ready to go in the backlog. Yellow indicated we had 2–3. Red meant we had one or less. This approach gave the right level of information, in an easy-to-understand snapshot.
2. Seek to understand the why.
As a designer, asking, “Why do you do [x]?” was second nature. My goal was always to better understand my user’s behaviors and goals to make a killer product catered to them. It isn’t any different as a Delivery Lead; your “users” are stakeholders and your project is the product.
I find that, often enough, when a customer asks for more data, a change in reporting, or a change in meeting cadence, there is a greater need beneath the surface of that request. As consultants, we have many tools in our toolbelt, but our customer might not always know this.
I once had a customer ask for a list of all stories completed in a sprint to be included in a sprint report. This is not a particularly strange request. In fact, for some customers, this may be a default section I would include in my reports. However, for this particular customer, it did strike me as odd. They were not one to get incredibly involved in the story-level detail of our work.
Instead of immediately changing my reporting, I decided to have a conversation with my customer to better understand why they wanted this information. It turned out what they were really looking for was more of a roadmap of predicted completion of epics, or larger chunks of functionality. This was an easy thing to accommodate in the report, since this was already readily available information as well.
So, the next time your customer makes a request, take a step back and seek to understand the why behind their need.
3. Always be iterating.
Designers iterate a lot. Look at any designer’s Figma file, and you’re sure to find ten different options they tried out for one simple interaction. Sure, they might only show one or two to the team, but the iteration is there. I guarantee it.
Iteration is for more than just tangibles like design and software applications. Iteration is also for process and team practices. It is quite easy to get stuck in a rut of, “Well, this is always how I have done it, and it’s always worked out.” However, I urge you to shake yourself out of it.
Iterate on how you run meetings, the format of your sprint reports, or how you communicate with your team. Even iterating on when I conduct various aspects of my work has benefited me in the past. Get iterating!
For one project, I noticed the team didn’t seem as engaged during sprint retrospectives as they once were. We had been using the same format for the entirety of the project, so I decided to shake things up a bit. Instead of doing our usual, “What went well?/what didn’t go well?/what should we change?” approach, I tried out a fun looking Miro template called Retrospective in the Island of Golocons. The team was excited to see a new format and we had some very productive conversations. Since then, I try to use a slightly different format for every sprint retrospective.
4. Collaborate for better results.
Designers like to collaborate. Not only will they “yes and…” until the sun goes down, but they also seek feedback. It makes sense, since they have been trained in how to analyze work and give tactful feedback. Because of this, I find myself often looking to collaborate, even in a role that might appear to be less collaborative from the outside.
Sure, as a Delivery Lead, it can be tempting to hunker down and do quite a bit of work solo. For example, the physical act of writing a user story may be a task for one, but getting to the contents of that user story can certainly be collaborative. Recently, I’ve paired with my tech lead to better understand technical constraints and where pieces of data will originate from by — you guessed it — using visuals! Our approach was quite simple; we drew color-coded boxes around items in our wireframes to indicate where data would originate from. This made it super easy for me to crank through writing user stories when the time came.
I also absolutely love when my design lead asks to bounce ideas off of me and the technical team. This is fantastic for a number of reasons. For starters, anything that prevents design from getting blocked is worth it in my book. It also demonstrates to the rest of the team that it’s okay to ask for some guidance when you’re feeling stuck. And most importantly, the design always seems to get better when we’re able to collaborate a bit.
Simply put, we often dream up more interesting and effective ways to solve problems when we collaborate.
Delivery Leads, put your Design Thinking cap on.
Design thinking is not only for software designers. Sprinkling in a little more collaboration, a smidge more iteration, a bit of “why seeking,” and more visualization of information is something that any human can benefit from. I recommend you give it a try!