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.
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.
I wrote a post back in July about recording client calls and why I thought it would be worthwhile to implement across the agency. We've since gotten better about this and seen a positive impact on projects.
For whatever reason, we didn't consider recording new business calls at the time, but as of late December, we decided to instate the same practice using Grain. It hasn't been long, but it's already proving to be a worthwhile change.
We started recording calls when our Director of Business Development, Dan, was out on paternity leave. We were having conversations that we thought would be helpful for him to review when he returned. In doing this, we saw benefits in making this a standard practice:
Training opportunity. There are quirks to every new business call. Having never met the client (in most cases), you never know what to expect. Recording calls is a helpful way to reflect on and learn from these conversations, whether they go our way or not. For example, the team references a call recording as a model for how to lead, or the call lead reviews the recording to see how they could improve the dialogue. Last week, I led a chat with a prospective client who appeared to be on vacation and seemed impatient with me inquiring about their business. They were happy with the call by the end, but I left thinking it would be a great case study to review in the future. Luckily, we got it recorded.
Team onboarding. It's always important to take notes on calls, but notes only capture what the note-taker thought was worth writing down, which changes from person to person. When getting the team involved in working on proposals and scoping new projects, recording calls make it easy for them to go back and hear first-hand how the project began. I recently jumped in to help put together an approach for a project for a client who I hadn't met yet. I reviewed the initial call recording and saw the client mentioned challenges with the communication style of a former agency. When it came time to present our approach, I leaned into being upfront and open with them. After the call, they sent us an email to tell us we were frontrunners, noting our "transparency and authenticity."
Future reference. It can take weeks, sometimes months, or even years, to land a new deal. Having all calls with a prospective client recorded for reference can help eliminate gaps along the way and avoid us asking the same question twice. We're very close to signing a new project with a client we've been talking to since August 2022. Unfortunately, we don't have recordings of all the calls since then; however, since the scope has changed several times, I could see the benefit of having recorded calls as a reference.
For anyone thinking about recording new business calls, here are a few considerations to keep in mind:
For more on leading new business calls, I wrote a comprehensive guide (relating new business to speed dating) in a previous newsletter. You can read it here.
With a new year on the horizon, running planning sessions with our retainer clients is a top priority. Whether or not the client's contract is coming to a close in December, it is an opportunity for both teams to zoom out, align on objectives, and discuss opportunities to work together more effectively. It also helps us project how much a client will spend with us in the coming year.
We created a template to guide this year's sessions. The Account Lead will be working with the project team to prepare. The deck covers the following areas:
As we start getting these sessions on the calendar, there are a few open items I'll be discussing with our Director of Client Services, Kate, this week.
One of our maxims at Barrel is All Feedback is Information. For us, feedback is an easy way to get input from co-workers about how they experience us so we can identify what's working/not working and how we can improve. Without it, we're missing an opportunity to learn and grow through real input vs. our assumptions, which may or may not paint a brighter picture than reality.
We talk about feedback with the team often and do our best to facilitate feedback conversations as needed. More recently, though, we've been thinking about other ways to normalize giving and receiving regular feedback instead of waiting on designated times of the year (such as performance reviews) or difficult situations.
Last week, we launched an experiment using Lattice. Leveraging Lattice's feedback feature, we requested feedback (anonymous for now) for our Team Leads and select team members from folks they worked closely with in the past few months. We left responses open-ended to let folks focus on what's important to them. So far, we've appreciated the team's candid and thorough responses.
After all the feedback is collected, managers will package and share the feedback. Documentation will likely happen in Lattice to keep everything centralized.
Looking ahead, we believe regular feedback will be integral to performance management at Barrel. We'll still have one or two planned performance reviews per year, but conversations can be happening all the time. Peer feedback will be based on more recent events, not generalized for months at a time.
Long term, our vision is that everyone feels comfortable discussing feedback among co-workers, and individually, every team member knows where they stand and has development areas to tackle.
Read related posts on feedback here.
In April, we began re-imagining how we communicate and collaborate with our clients. Inspired by Domino's pizza tracker, we narrowed the scope of what we share with clients, focusing only on what's important. These efforts led to us moving all clients into a "Project/Client Tracker," built with Google sheets. Yes, Google sheets!
For fixed-fee projects, clients have:
For retainers, clients have:
While both trackers have been well-received by clients, we recently noticed a blind spot with our retainer clients — initiatives don't have client-facing schedules. We do monthly planning with clients to determine priorities, but there is no system for outlining the timeline later.
I chatted with Kate, Director of Client Services, about this last week and learned that Account Leads have been creating versions on their own for some accounts but not all. The good news is that task-level schedules exist in some places; the bad news is they are not everywhere or consistent.
Luckily, this is a pretty straightforward solve. I'm looking forward to hashing it out with Kate this week, then rolling it out with the team.
The fun thing about writing is looking back at where ideas began to understand the thinking and whether or not the original intent panned out.
In May, I wrote about better connecting the dots between Business Development and Client Services through more collaboration early in the process (read here). It has been amazing to see the progress since then, most recently inviting Dan, our Director of Business Development, to a daily standup that used to include only the Team Leads involved in implementation.
Bringing Dan into this touchpoint, along with many other changes in how we collaborate, has prompted some great conversations about how we scope projects and set ourselves up for success in implementation.
I'm excited about the continued discussions last week because I could see the vision clicking for the Team Leads. I thought it would be worth committing these ideas to writing to reference later and sort through them myself.
Over the years, we've learned one of the most effective ways to evolve our process is through the SOWs we create during Business Development. Why? It is the first time we look at the client's needs, figure out how much effort it will take to meet them, and then commit to a timeline and budget.
This fact underscores the importance for:
Close Business Development and Client Services team collaboration coupled with the seemingly subtle process changes outlined below will be a good step toward achieving this vision. We've come a long way already.
Our Business Development team has been running requirements workshops with clients for several months. In the workshop, they dig into the client's website needs to help formulate a proposal, using a spreadsheet as a guide. More recently, we've gotten our Strategy team involved in fleshing out the details of our requirements and even leading the call with the client.
In recent deals, we've seen a trend with clients looking for more details on the cost and effort for all aspects of our proposal, prompting us to think more about what other conversations we can have during the "requirements gathering" workshop.
As a first step, we've evolved our Requirements spreadsheet to capture the deliverables and milestones of our process. We can then estimate our time against these steps and get a better view of whether or not we can hit the client's desired timeline and feature set. We've seen time and time again how simple shifts in the process (adding or removing deliverables, extra revisions) can impact the timeline and budget.
The next iteration of our spreadsheet is mapping out common project types. The goal here is to have a base approach for different scenarios that we can begin with, cutting down the time it takes to get to a proposal.
Some examples of project types include:
Each scenario will include a rough schedule, process steps, requirements estimates, and a staffing plan. The key here is getting all Team Leads' input captured, so there is no need to reinvent the wheel after the project gets signed.
We are not saying that every project will be the same or that they'll fit into these buckets exactly. However, we already tend to categorize leads into buckets and often try using the last similar instance as a starting point. While this works to a degree, it is a reactive way of working and makes every shift feel like an edge case.
With scenario-based scoping, the scope of work is the next area for standardization, taking base requirements for each project type and mapping it into an SOW. We recently updated our SOW to better outline our process with relevant details within each phase. Having this in place will make the process that much easier.
The goals here are:
This year, we overhauled how we use tools as a team and with clients. These changes involved rolling out a Project Tracker (created in Google Sheets), highlighting the most critical information for clients: project launch date, a project schedule, and a change log. For those interested, we use Basecamp for client comms. Another shift was using Asana exclusively for team task management.
Building off the idea that the SOW is a guide for the implementation team, the Project Tracker will be another touchpoint to connect the dots to the various approaches outlined in scenario-based SOWs. We're imagining the Project Trackers could directly reference aspects of the requirements spreadsheet and SOW, so there's less upfront work to get it ready, speeding up the time it takes to get a project off the ground.
With tight scoping during the requirements gathering workshop, there is an opportunity to tie these tasks into Asana. This connection could cut down the time it takes a Project Manager to get an Asana board up and running for the team. I'm also curious to explore whether or not a CSV template could further improve this process.
Requirements! Quite a hot topic lately. With the requirements workshop in place, we know a good deal about a project before it begins. The missing piece is how that translates to the implementation team.
Looking ahead, the Strategy team will be taking the lead here. Strategists will not only be helping lead the upfront workshops with clients but also be responsible for creating a JIRA board at the project start. The board will include tickets for everything we know at that point.
Throughout the project, these tickets will act as a "spec" for designers and developers. The only way this will be a success is if they're used in every discussion and updated when/if things change.
When designs get signed off, we'll be able to move more quickly into development since the tickets will already be up-to-date. When it comes time for QA and testing, we'll have requirements centralized for reference.
We've had some recent discussions around QA and how to make sure we're testing all use cases of a given feature. What excites me about this process is the clarity of where changes like this can happen, such as the requirements spreadsheet, which then impacts how we structure JIRA tickets.
There are aspects of our process I'm not covering here and many others to continue exploring. For instance, we've made strides in getting Client Services to run client orientation but are working on other ways to improve that handoff.
I chose to focus on the above areas because I believe delivering on them can improve delivery for our clients, increase efficiency, and as a result, project profitability.
I hope that these changes will also:
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:
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:
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:
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:
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.
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.
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:
A few of the open questions we need to dig into more are:
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.
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
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:
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.
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:
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
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.
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:
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.
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.
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.
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.