Notes
This is a place for thinking out loud, reflecting, and sharing ideas. Notes are a window into my process, thoughts, inspiration, and experiments. Explore visual gallery.
Notes
Last quarter, I wrote an essay about our new process for running debriefs across the agency each quarter (read it here).
At a high level, each team meets to discuss notable accomplishments, lessons learned, and feedback (for teammates, leadership, and manager). From there, each Team Leads synthesizes the notes into the following:
- Growth Areas: The top 3 areas that your team has shown growth over the last quarter
- Lessons Learned: The top 3 lessons learned last quarter
- Feedback We Should Consider: The top 3 themes from your team’s feedback
- Focus for Next Quarter: What are 3-5 focus areas for your team’s growth next quarter?
With Q3 coming to a close, each team went through this process in late September. On Tuesday, the Barrel leadership team met to review key takeaways and focus areas for Q4.
Taking into account the feedback from last quarter's session, we made a few changes to the format this time around:
- More guidance for how Team Leads should synthesize their meeting notes
- A plan for Team Lead presentations, beginning with each sharing the sentiment from their team's debrief meeting
- Designated time for the whole group to discuss shared themes across all teams
Overall, it was a productive session in that we made time to pause, zoom out from the day-to-day and reflect as a group. The challenge, though, was not having enough time to dig into the themes and align on focus areas for the next quarter. The group shared the same sentiment, rating the meeting with 7s and 8s across the board. In the future, I think the space to align will be the most valuable use of our time together.
I'm inspired by Amazon's culture of writing memos to frame and run meetings. In theory, it seems like an effective way to save time and promote thinking.
"The reason writing a good 4 page memo is harder than “writing” a 20 page powerpoint is because the narrative structure of a good memo forces better thought and better understanding of what’s more important than what, and how things are related. Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas." (Colin Bryar and Bill Carr, Working Backwards)
Rather than extend our quarterly session meeting time, I like the idea of introducing writing and reading. An updated process might look this:
- Team Leads write an in-depth synthesis of their notes with any necessary context typically added via presentation voiceover (perhaps a one or two-page limit)
- Everyone comes prepared, having read each other's notes and decided on what they see as the top focus areas for the coming quarter
- We use the allotted meeting time to answer any questions and a deep discussion on focus areas, breaking out any immediate to-do list items for the team
This post originally appeared in Edition No. 109 of my newsletter. Subscribe here.
A few topics have been a constant source of discussion over the past several years at Barrel — QA is one of them. The past few months have been no exception.
Last week, I met with our Team Leads to discuss QA, specifically to begin answering: Which team should own and maintain our QA standards?
Currently, our teams share QA with project managers facilitating most of the process. Designers and developers work with project managers and part-time contractors to review the work and highlight any issues with the design or functionality.
When I joined Barrel in 2013, we had an entire team dedicated to QA. We've since transitioned away from this model for numerous reasons. When challenges with QA come up today, a natural thought is that building a team around it will solve all of our problems. While we've learned (the hard way) that hiring people to fix issues rarely works, I am not sure that creating a QA team is the right vision to march toward, at least with who we are as an agency today.
QA is an opportunity to do a final check to ensure our work is up to spec with what we've scoped and designed. Before beginning QA, our aim should be to do everything in our power to get the work right. In other words, it doesn't make sense for anyone to spend time checking if the work is up to spec if we know it is not.
I believe this has been the source of many recent challenges. For one reason or another, typically the timeline, there are projects where QA begins QA on a website that we rushed to build. Maybe the website is working correctly but doesn't look great, or — it looks great but is missing functionality. Either way, these situations often result in:
- Hundreds of JIRA tickets
- Strained team members
- Concerned clients
Even when we get the site launched on time and spec, it can be difficult for the project team to celebrate, given what it took to get there. There can also be a backlog of tickets marked "post-launch" that still need to get resolved.
Send It Back
A few years back, we adopted a "send it back" policy where team members would hold on QAing the work if it didn't appear ready. While this has helped prevent wasted time, it can have unintended consequences like project delays due to shifting milestones.
The projects with the most enjoyable and efficient QA process have been ones where QA started with a website in a near-launchable state. In that way, ownership of QA standards will not entirely prevent the above issues if we haven't done everything in our power to get the work done right beforehand.
In my session with the Team Leads, I communicated my perspective on where I see our challenges today. Our Director of Client Services, Kate, then shared her experience working with teams where QA sat with the tech team. As we discussed this as a group, a new vision started taking shape.
A New Future
We left the discussion with a taste of what a future where QA lives with our Software Engineering team could look like at Barrel. At a high level:
- Designers would have scheduled time to sit with the lead developer on the project to review annotations and requirements. Together, their job would be to ensure all functionality is understood and accounted for before beginning the build process.
- Our QA resources would function almost like assistants to developers, working alongside them to make sure their work is up to spec.
- Project managers would ensure that QA begins, no different than ensuring developers have what they need to start their sprints.
- We'd introduce a new phase of QA called Creative Review, where designers, client services, and other relevant parties review the work for the first time.
- During Creative Review, we'd expect there are fewer than ~15 issues. For Creative Review to begin, the Software Engineering team would agree on a standard for the work. Perhaps a checklist or other way of confirming standards.
A few of the open questions we need to dig into more are:
- When do clients get involved?
- How much time does this add to the development process?
- How do we uphold the standards for Creative Review?
I'm eager to explore this more with the Team Leads. What I'm most excited about is this approach offers a new way to look at an age-old challenge. It also evolves our process to lean on doing our best work first, not checking to see if we did later.
I'd been lying if I said that talking about QA has been exhausting in the past. It feels good to feel energized to dig in more this time around.
This post originally appeared in Edition No. 107 of my newsletter. Subscribe here.
I was chatting with our Team Leads last week in our morning standup when our Design Director, Christine, mentioned finishing up designs for an exciting project launching soon. She talked about our plan to send designs to the client the day before the presentation for review. Hearing this reminded me of two posts I wrote early last year about creating space to think and pre-sending deliverables.
Before going remote, we used to tell ourselves that the best and only way to present early strategic and design work was in person or on a call. I have distinct memories of going to lengths to do this, even flying to San Francisco for the day.
During COVID, presenting in person was no longer an option, so everything became a Zoom call. Meeting fatigue was suddenly a hot topic among industry professionals. It seemed like every other LinkedIn post included some commentary on the subject. At Barrel, we started looking at our schedules as a team and asking:
We learned that while there was value in being on a call to frame and present our work, we were being too precious. As a result, we were unintentionally only raising the stakes of the presentation and prompting the client to react vs. give thoughtful feedback.
It was March 2021 when I wrote the post about pre-sending our work before the meeting. I circulated it to Christine and other team members to get input. Soon, we began experimenting. Last week, I was pleasantly surprised to hear it was happening consistently across the agency. I asked Christine and Kate, Director of Client Services, to share some of the benefits of taking this approach:
- Reduces surprises: The client has more time to review the work and express any issues before the presentation. We can choose to address them ahead of time or use the call to talk it through.
- Invites thoughtful feedback discussions and inspires action: When clients see work for the first time on a call, they often react to what they see, or if they are unhappy, wait to follow up after the call. Instead of using our time with the client to present, we can jump right into their feedback and align on actionable next steps. This approach helps eliminate project delays and cut down the timeline.
- Promotes efficiency: Sometimes, we receive clear feedback before the presentation and decide that we can shorten our meeting or cancel it altogether. In these cases, we might even be able to get ahead on our timeline.
- Eliminates working down to the wire: Sending work ahead of time creates a buffer between "pencils down" and presentation, giving the team more time to prepare for presenting the work. This buffer is particularly helpful for new or junior members of the team who are learning the ropes. It also reduces any pressure leading up to the presentation.
The change in process has made us better about capturing our thinking when sending over work for client consumption. While we do this mostly in writing, we have experimented with video recording, too. Looking ahead, I think there is plenty of untapped potential with video and audio for presentations, and worth continued exploration.
This post originally appeared in Edition No. 105 of my newsletter. Subscribe here.
With the US Open coming to a close this past weekend, I thought I would share an exciting recent Barrel website launch for a new apparel brand honoring the legacy of Arthur Ashe.
Arthur Ashe was a pro tennis player with an incredible career and an impeccable sense of style. Ashe won three Grand Slam singles titles, was the first black player selected to the US Davis Cup team and is the only black man to win the singles title at Wimbledon, the US Open, and the Australian Open. Throughout his career, Ashe was also an activist and civil rights champion. Many know him today by the tennis stadium in Queens at USTA Billie Jean King National Tennis Center, Arthur Ashe Stadium, where tennis matches in this year's US Open took place.
The Arthur Ashe brand launch comes from the founder of clothing brand Rowing Blazers, Jack Carlson, with whom we have collaborated for several years, redesigning websites for Rowing Blazers, Gyles & George, and Warm & Wonderful. Carlson partnered with Jeanne Moutoussamy-Ashe, the Arthur Ashe estate, and Kith alum Karl-Raphael Blanchard to bring the new brand to life.
In an interview with Women's Wear Daily, Carlson talks about his connection to Ashe and the brand's origin:
“You have Fred Perry, a British tennis lifestyle brand named after Fred Perry. And Lacoste, a French brand dedicated to the legacy of René Lacoste. But there hasn’t been an American equivalent. Who better to represent the United States than Arthur Ashe? [He] has been a hero of mine for a long time. His icy cool demeanor, effortless style, scholarly approach to sport, his will to win and determination to stand up for social justice all resonate with me deeply. The opportunity to work to create this brand has been a dream come true.”
I didn't know much about Arthur Ashe before we learned about the project. All it took was a quick Google search to understand how important Ashe is to the story of tennis, later emphasized by Carlson's passion for Ashe's career during our project kickoff.
In preparation for the project, I read Levels of the Game by John McPhee, a short book documenting a tennis match between Arthur Ashe and Clark Graebner in 1968. McPhee uses the tennis match as a basis for detailing the early days of Ashe's career (he began playing at age six!) and his unique technique (like using a wooden racket long after aluminum entered the scene). As someone who grew up coloring outside the lines, I found Ashe's story of drive, originality, and passion for the game inspiring.
Overall, I am proud of our work on the new website and honored to play a small role in bringing Ashe's legacy to the forefront. I also had a lot of fun jumping back into a Creative Director role, working with our Senior Designer, Isaac, to develop a design system that acts like a gallery wall for the apparel and archival imagery.
Explore the Arthur Ashe legacy and collection at arthurashe.com
This post originally appeared in Edition No. 105 of my newsletter. Subscribe here.
We had a follow-up call last week with a client about how to move forward after presenting an audit of their website a week earlier. This meeting is a new step in our process to give clients time to digest our recommendations and decide how they would like to proceed. Previously, weeks might pass after presenting the audit without knowing if and when the client might want to implement our recommendations.
Initially, we kept the meeting agenda flexible to give ourselves room to discover how to best use the time with clients. After a third rep in the books last week, a new process is starting to emerge.
Upon completing our next website audit, we will document all recommendations in a Google Sheet. Following our presentation, we'll share this with the client and mark the recommendations we consider high value and priority. We'll ask the client to review this along with our presentation document and make any edits. One question we still need to answer is whether or not we include pricing and estimates at this stage.
We'll then use the follow-up meeting to gather feedback and align on the scope of implementation so we can follow up with a proposal. At the start of last week's call, we received some helpful feedback about our analytics audit that we'll be considering for next time. We spent the rest of the time discussing the recommendations they'd like us to implement. Without an organized list, though, the conversation wasn't as productive as it could have been. In the future, we'll open up the Google Sheet with suggested recommendations and review the client's edits, making any necessary changes as we go.
Kudos to our Director of Client Services, Kate, for pivoting last week and proactively putting together a Google Sheet to organize our recommendations. Not only has it helped with developing a proposal, but our client found it to be valuable in managing where their internal developer's involvement ends and our's begins.
Our website audits have come a long way in a short amount of time. At this point, small tweaks like this one are what will make all of the difference.
This post originally appeared in Edition No. 104 of my newsletter. Subscribe here.
In March, I wrote this post about how we could better align our standalone website audit process with the audits done for our website redesign projects. Since then, our Strategy team has taken over website audits and become more involved in the early stages of website redesigns. As a result, we've evolved the process quite a bit on both sides.
Last week, we invited our Design Director, Christine, to our weekly Strategy team meeting to dig into the first key milestone of our website redesign projects: the Website Strategy presentation. This milestone acts as a guide for the project, capturing everything from our suggested sitemap to features and integrations. The goal of our discussion was to examine the current website audit process on redesigns and revisit the Website Strategy presentation template.
The topic ended up being a bigger discussion than we could fit in one hour, but there were a few takeaways I'm anxious to pick up again when we meet next week:
- Show your work! We currently do a lot of research at the start of projects that clients don't see. We should share the insights of this work (even if in the appendix) with the client to give them a more comprehensive understanding of how we arrived at our suggested approach. If we're unsure whether the insights are worth sharing, there are three questions worth asking: What value is this adding? Why isn't it worth sharing? What would we lose by not doing it at all?
- Start with the template. As we look to improve our website audit process for redesign projects, an effective way to evoke change is by looking at the output of our work: the end deliverable. Rather than asking the team to work together or "come up with insights," we can design the template to focus them on the right areas. For instance, a slide that requires the team to fill in specific metrics will ensure the correct KPIs are reviewed and inspire a conversation during team review.
- Think about repeatability and consistency. Earlier Website Strategy (formally Website Approach) presentations often required the team to spend more time structuring the deck or writing the perfect language than doing the actual work. As we evolve the Website Strategy presentation template, our aim is to create a format that is repeatable and easy for clients to follow with enough flexibility to capture the unique needs of the project at hand.
I'm looking forward to continuing this discussion next week. The deeper we go, the more I wonder if we can get to a place where all website audits are completed the same way, whether we're redesigning a website or making optimizations. The only difference would be how we communicate and act on the insights.
Related: Integrating URL Crawls Pre-SOW
This post originally appeared in Edition No. 104 of my newsletter. Subscribe here.
When we do a website redesign project, we use tools like Screaming Frog to do a URL crawl of the current website. This step surfaces all existing website pages, including any that may not be visible from the navigation or footer.
While this step helps ensure our designs account for all content, it can often lead to new discussions around templates and pages after a project has already begun.
If we're lucky, we'll create a Change Order for the new learnings and move on. However, here are some other outcomes that might happen as a result:
- No change in scope (we think it will have no impact or do it as a courtesy), timeline challenges later in the project
- Request for Change Order, client upset or confused
- No change in approach, content issues later in the project
To help alleviate this, we're currently training our Business Development team to run a URL crawl during the scoping process with a prospect. We'll use this information to make more informed decisions about what pages to show during the design process and how many templates we'll need to build to support those pages.
It's often the small things that make the most impact. I have a feeling that this shift could be just like that.
This post originally appeared in Edition No. 102 of my newsletter. Subscribe here.
I'm excited about recent developments in capturing website requirements throughout the design and build process. Requirements include how the front-end delivers the desired user experience and how that functionality gets managed in the back-end.
These days, we're doing a much better job making decisions about apps and integrations pre-SOW. However, there's still a level of detail that only comes once the project gets off the ground.
Historically, we've waited for a specific point in the process to capture all requirements and prepare tickets for development (in JIRA). This approach can lead to gaps in information, delays in the schedule, or additional time needed from certain team members.
We haven't locked in the new process yet, but I'm excited about where we're heading. Rather than a designated point in the project timeline, we'll start capturing requirements from the project kickoff. We'll capture everything we know upfront, and then, as we go, we'll add to and refine these requirements.
In every internal and client check-in, the team will reference these requirements and ensure they are up-to-date with recent feedback. The end goal is that the website requirements are ready when the designs are signed off. No heroic effort is needed to get them off to development.
We're also talking about how requirements can be as valuable to a client as designs. In that way, we're discussing how we might be able to present requirements alongside designs and require sign-off from the client.
A couple of pieces we still need to iron out are where the requirements live and who owns them. Right now, we're thinking about managing them in Asana, then as they're complete, pushing them to JIRA. Ownership-wise, we expect that our Project Managers and Strategists can own requirements with input from our Software Engineers and Designers.
This post originally appeared in Edition No. 101 of my newsletter. Subscribe here.
We all know how important it is to do some research before the first call with a prospective client, but that doesn't mean we always remember to do it.
With our Director of Business Development, Dan, out on paternity leave a couple of weeks ago, I found myself on more prospect calls than usual. There was one in particular where I hadn't made the time to prep until the morning of the proposal. Without much time to sit down and read, I decided to look up a podcast while out for a morning walk with my dog, Gizmo.
With a 30-some minute podcast on 1.25x speed, I was amazed at how much I learned in a short amount of time. Even better, it came directly from the company's founders.
Since then, I've been excited about using podcasts as an easy way to learn more about our potential future clients. We don't always have access to the CEO or founders, especially at the start, so podcasts are a priceless tool to dig in early and level up the types of questions and approach we bring to the table.
This post originally appeared in Edition No. 101 of my newsletter. Subscribe here.
On a monthly-or-so basis, the Barrel partners and I watch videos from a leadership course called Admired Leadership. Our Team Leads also watch these together as a group. One of the recent videos we watched was called Confront Poor Performance with a Request for Information. It really stuck with me.
The idea is that instead of giving an employee feedback, the manager creates a request for information that requires the employee to address the feedback. For example, rather than a manager repeatedly telling a salesperson to do more outreach, they ask them to review their call log daily. The bet is that the mere act of doing will improve the employee's performance and create results.
I appreciate the inward focus of this approach (for the manager) and how effective it can be at helping an employee grow. It's also a great way to identify gaps within a company's processes and systems.
In many ways, our process for reviewing client accounts each week has been an invaluable "request for information" to keep everything on track. The act of Account Leads having to report on status each week and the Barrel Partners checking in with each other has improved performance across the board.
It's been fun looking at where this can apply and experimenting with my direct reports and their teams.
This post originally appeared in Edition No. 101 of my newsletter. Subscribe here.
I had a couple of client calls last week that had me feeling somewhat uneasy beforehand. Not because we did anything wrong, not because the client was unhappy, but because I had no idea what to expect.
Before the calls, I gathered as much context as possible to remove any uneasiness. Confidence comes from knowing. While I didn't know where the conversation might go, I found confidence in the facts and my relationship with the client, but most of all, my willingness to guide the conversation toward a resolution, whatever form that might take.
Without getting into detail, both clients shared that their business was going through a shaky period. In both scenarios, we agreed to scale down hours for the rest of the year and revisit our collaboration in January. Thankfully, one contract had an end date, but the other was on-going, so our projections didn't suffer as much as they could have.
On Friday, I looked back on the week and thought about how similar calls may have stressed me out in the past. This time, it felt nice to find calm. One helpful tool has been a mental checklist for how I show up in client conversations, no matter the situation.
I've never formally listed this checklist, but I thought it would be a good exercise. Below is a brief breakdown.
1) Listen with curiosity: Rather than reacting to the client, I try to respond with questions that surface more context. I aim to understand where the client is coming from and uncover what other pressures they are managing. There's always more below the surface, and often, that information is the missing puzzle pieces. Seeing the situation from the client's point of view can change everything.
2) Find the feedback: One of our Barrel maxims is "All feedback is information." In that way, there's always feedback ripe for the taking. When I chat with clients, I ask questions to get insight into how they view our collaboration. If our goal is continuous improvement, all feedback is invaluable. Feedback may also be the key to turning around a challenging situation.
3) Be honest, not defensive: I can remember times in the past where a client expressed dissatisfaction with how we handled a project, and I thought to myself, "I'd be unhappy, too." Rather than try to defend what we did, I've found that recognizing the situation for what it is has been much more productive. The client feels heard, and we can start looking ahead, not dwell in the past.
4) Be willing to accept any outcome: Given my role on projects, I rarely chat with the same client on a daily basis. When I meet with them, there's always a chance that I'll learn something new, and the conversation will take a new form. While I always prepare for my calls and know where I hope to guide them, I've learned to come to them with an open mind vs. push any specific agenda. The outcome may not be in our favor, and that's okay. I appreciate surfacing it with the client rather than coming out of nowhere and potentially ending on bad terms.
5) Focus on what they want: One of the calls this week went one hour over the allotted time. The other lasted 15 minutes. The latter client knew what they were looking for from us, while the former used our time to discover that path. In either case, I see it as my job to center the conversation on what the client wants. When I deal with a challenge as a customer, I've learned how powerful it is to lead with what I want. When their vision is unclear, I do my best to help them find clarity so we can help them be successful. Every time, my goal is to confirm any next steps are in the right direction.
This post originally appeared in Edition No. 100 of my newsletter. Subscribe here.
A couple of weeks ago, I heard through the grapevine that a client had a horrible call with a partner we referred. After hearing about the experience from two team members separately, I decided to reach out to the partner to get their take, especially since I had brought the partner on board. I sent them this email:
Hi [partner],
We connected your team with [client] recently. We heard from them that the call didn't go well. They seemed to be upset with how your team handled the discussion.
We don't have much more info, so I'm reaching out to you for any thoughts you have on the call and any insight for future referrals.
Thanks,
Lucas
Without getting into detail, the partner apologized, figured out who led the call with our client, and reviewed a recording of the client meeting. I had no idea they recorded all their calls. Here's a snippet from their response:
"Let me firstly apologize for the experience that your client had. It seems that [client] reached out directly on our website, and as a result, your client was routed to one of our junior members of the Account Executive team. They are newer and used to working with small businesses.
I reviewed the call. It seems like there was some misalignment between what your client was looking for and what we were pitching. I can see why they were frustrated."
The partner ended up re-assigning the Account Executive and reaching out to our client to apologize and make it right. I was impressed.
Now and again, we record calls, but by no means is it an agency practice. Since this experience, I can see many of the benefits that recording calls may provide. Here are a few that come to mind:
- Revisiting past project decisions when there are questions about how we ended up where we are
- Reviewing a call with the team if it doesn't go as planned to see what we could have done better
- Getting further context into a situation when a client reaches out with feedback
Implementing this across the team is a simple practice we can put in place. Before that happens, my main focus is making sure there's team alignment on the intent and creating a system for accessing calls as needed.
Next time I have to call my credit card company, I'll smile when I hear "This call is being recorded for quality assurance."
This post originally appeared in Edition No. 095 of my newsletter. Subscribe here.
Several years ago now, we committed to 360° performance reviews (employees reviewing each other in addition to their manager). For a while, reviews happened every quarter. This cadence became difficult for both the team and management to run efficiently. Many team members would ask for an extension, which was tough within three months, or they would get it done, but their responses lacked substance. The process also required a lot of time from managers.
Now, we conduct performance reviews semi-annually. The team provides solid feedback, and the process is straightforward. But like many things, you solve one problem, then you surface another.
Despite a robust performance review process, we have had under-performing employees given Performance Improvement Plans (PIP) and employees who ask their manager how their performing. This makes me think there's an opportunity to revisit our semi-annual performance review process, and maybe that means saying goodbye.
Every day, team members experience one another, and naturally, they have feedback for each other. When they do, there are several ways the feedback may get handled:
- They brush it off and stay quiet.
- They seek advice from their friends and family.
- They share the feedback with their co-worker's manager.
- They have one-on-one with their co-worker.
- They talk to the co-worker's manager who prompts a group conversation.
Whichever approach the employee takes, there's no direct tie to the other employee's performance review unless it's around that time of year or the manager takes note. This is one of the reasons I believe in promoting the manager feedback channel because, at a minimum, the manager is in the loop.
Kate, Director of Client Services, and I recently discussed a framework for addressing feedback for her team following her Upward Feedback session. Given the sheer number of people the Client Services team interacts with daily to manage clients and project teams, it is not uncommon for Kate to receive feedback from her team's co-workers or Barrel leadership.
Like any manager, Kate may not have been involved in the situation where the feedback was derived. Rather than play messenger and deliver the feedback for them, we agreed that she'd start setting up a chat between herself and the parties involved. She'd facilitate the conversation, take notes, and follow up with written notes afterward to confirm alignment.
There are two key benefits to this process:
- The manager takes ownership of the feedback and the team's performance.
- The feedback is documented so the manager and employee can reference it later.
The question remains, what about performance reviews?
In a perfect world where this is happening across the agency, performance reviews and PIPs might no longer be necessary. We wouldn't need specified times in the year to gather and address feedback because feedback would be happening daily. We wouldn't need a process to document and give feedback to an underperforming employee because feedback would be addressed and documented daily.
There is a lot to consider with a change like this, but the possibilities are exciting. I love the idea that no one ever gets a performance improvement plan because, in essence, we're all on one from the start, looking to get better every day. A shift like this could normalize feedback and further promote a performance culture.
Related Posts:
This post originally appeared in Edition No. 095 of my newsletter. Subscribe here.
When my Pop-Pop worked at Wendy's for the last decade or so of his life, he would receive tons of customer comment cards each week. Customers loved seeing him during their visit and wanted management to know.
My Pop-Pop was easy to love, but I can only imagine that those comment cards impacted how his manager viewed him as an employee, giving him feedback if there was any and taking care of him in more ways than one. The comment cards provided insight into Pop-Pop's impact on customers that his manager may not see otherwise.
I was thinking about Pop-Pop's comment cards a couple of weeks ago while reimagining our project debrief process. We're not serving hamburgers and fries, but I have a feeling that integrating client feedback would help us take our service to the next level.
Our project debrief process invites the team to share their perspective on the project. If there is notable client feedback during the project (via calls, emails, NPS, or other channels), it will often make its way into the discussion, but there's no guarantee. The feedback we receive is often like a Yelp review: the client is either ecstatic about their experience or so unhappy that they feel compelled to let us know. There's rarely a middle ground.
If we want to improve how we work and serve our clients, client feedback is just as important, if not more, than how our team thinks the project went. In that way, a project debrief should consider the perspective of everyone involved, including clients.
I imagine a system where clients, like Wendy's customers, have a specific channel to share feedback throughout every project they work on with us. Each milestone could end with a prompt follow-up where we ask clients to rate our meetings and share if they feel like we hit the mark. As the feedback comes in, we can review it and decide on any next actions.
By the end of the project, we'll have improved our collaboration and grown in the process. When it comes time for the project debrief, we can take out all of the "cards" to remind ourselves how the project actually went, discussing what we can do to repeat the best parts and improve upon the challenges.
Related Post: BL&T Edition No. 035: Discovering Passion Through Pop-Pop's Story
This post originally appeared in Edition No. 095 of my newsletter. Subscribe here.
I was chatting with Kate, our Director of Client Services, last week and had an idea about our SOWs (scopes of work). What changes if we look at them like an SOP (standard operating procedure) for the project?
The SOW is a source of truth for the team on a given project. It is a document the team (assumes they) can rely on to understand everything the client has hired us to do. Maybe this seems obvious, but trust me, a lot can fall through the cracks! In that way, the SOW is an inflection point for us to enact change in how we function, collaborate, and deliver projects - and we can use it to our advantage!
In looking at SOWs as SOPs, we force ourselves to map out how we see the project getting done and align with the client on that process. Yes, the client is buying the outcome of our work, but every project is collaborative. They want someone they'll enjoy working with — they're also buying us and our process.
While this mindset is in draft mode for me, there's a lot we're already doing to get as granular as possible in our SOWS, so I'm confident we're on the right track. For now, here are my initial thoughts on some primary categories to include in our SOWS that will help us think about them more like SOPs:
- Overview: What we're doing (the project) and why
- Process: How we'll do it (and client/internal responsibilities)
- Deliverables: The artifacts the client can expect to receive
- Project: The details of their project and what makes it unique (features, functionality, etc)
- Pricing: How much it costs
- Timeline: When we will deliver key deliverables
This post originally appeared in Edition No. 091 of my newsletter. Subscribe here.