Go Between Posts

Winter '24 Recap

Truman Shuck — Thu, 17 Apr 2025 24:00:00 GMT

Winter in a Nutshell

Completed our platform intelligence project at Beyond Finance and documented it in a case study
Reconnected with past colleagues and friends during business development efforts
Created our first LinkedIn carousel ad and grew to 76 followers
Wrestled with the ever-present feast/famine cycle of consulting
Planned website updates and a fun Musicbox experiment for spring

Crossing the Finish Line at Beyond Finance

Winter saw us wrapping up our platform intelligence project at Beyond Finance. They were facing the classic scaling challenge: as their business grew, system quality issues became more costly, but they weren't sure where to begin addressing them.

We developed FeatureMap, a standalone Rails gem that maps product features directly to code, creating a shared language between business objectives and technical systems. This approach aligns with our belief in the importance of effective company culture - creating shared language and understanding that enables better collaboration. By implementing it as a gem rather than a service, we ensured no data left their environment while delivering a self-contained solution with built-in linting and validation.

One of our favorite moments came when their QA team used their new feature understanding to run targeted integration tests, significantly reducing testing cycles. As their SVP of Technology noted, our work helped them improve "technical planning and project decomposition, raising the quality of deliverables and making systems more maintainable."

We're particularly proud that Beyond open-sourced the library we wrote, and we're curious if other organizations might benefit from similar approaches to bringing clarity to complex systems. Throughout this project, we discovered that finding clarity within complexity isn't just about better tools - it's about creating a shared language for teams to understand their systems. You can read more in our case study or check out our new Platform Intelligence service page.

Finding clarity within complexity isn't just about better tools - it's about creating a shared language for teams to understand their systems.

The Business Development Shuffle

With the Beyond Finance project successfully completed and documented, we shifted into business development mode - that familiar dance of reaching out, following up, and planting seeds for future work.

We reconnected with past colleagues and friends, which reminded us how much we enjoy these conversations regardless of their business potential. It's unfortunate that sometimes a work-related reason is needed to reconnect, but these discussions quickly transcend their initial purpose. With Harrison and Truman's networks primarily in Chicago, we settled for virtual catch-ups, while Dan had the luxury of actual in-person coffee meetings. We continue to navigate the challenge of maintaining connections outside our immediate spheres - finding the right balance between accepting limitations and working to improve remains an ongoing puzzle.

The shift from client work to business development highlighted how different these skill sets truly are. Fortunately, our audience-building cycle had already sharpened our writing muscles, which proved invaluable for creating outreach content and crafting messages that resonated with our network. Much like we previously discussed in our post about building an audience, we found that consistency and authenticity were far more effective than chasing viral tactics.

On the marketing front, we experimented with LinkedIn advertising, creating our first carousel ad with surprisingly decent visuals. Our LinkedIn following grew to a whopping 76 people – not exactly "influencer" territory, but we'll take it! In a classic business development irony, the LinkedIn ads were primarily clicked on by sales people rather than potential clients, yielding essentially zero contact form submissions. Yet we heard from several folks that our consistent LinkedIn presence was what kept us top-of-mind for potential conversations. This experience taught us that marketing works in mysterious ways - sometimes your consistent presence matters more than your carefully crafted campaigns.

Marketing works in mysterious ways - sometimes your consistent presence matters more than your carefully crafted campaigns.

Challenges and Patterns

The feast/famine cycle continued to be our most persistent challenge as a consulting business. We are incredibly grateful when we land projects that allow all three of us to work together, but the transition periods between these anchor clients remain tricky to navigate. This winter highlighted how quickly priorities can shift from "build great things for clients" to "find the next client who needs great things built."

We also struggled with balancing business development and our other Go Between initiatives. Our carefully structured cycle approach took a back seat as we focused primarily on biz dev while maintaining our publishing schedule. It turns out that "just add one more priority" isn't a sustainable strategy, even for a team that prides itself on productivity. The constant context switching between client work, business development, and content creation tested our ability to stay focused and effective.

These patterns aren't unique to us, but they're particularly pronounced in a deliberately small consultancy. We continue to develop strategies to navigate these challenges while maintaining the quality and thoughtfulness that defines our work.

Favorite Posts This Winter

Despite the business development hustle, we still made time for our publishing cycle. Three posts in particular stand out from the later part of this season:

Pitching the Refactor - We tackled the challenge of communicating the value of system maintenance work. By reframing the conversation away from "technical debt" and toward business outcomes and future product velocity, this post offered practical language for technology leaders navigating stakeholder conversations.
New Codebase Onboarding - We shared our methodical approach to mastering unfamiliar codebases, a skill we've refined through years of consulting. This guide transforms the overwhelming process into actionable steps that help product leaders contribute faster while building deeper system understanding.
Scalable Web Scrapers - We explored various web scraping solutions from Diffbot to Apify, ultimately documenting how we built a cost-effective system using Crawlee.dev that costs just cents per execution. This practical guide quickly became one of our most referenced technical posts this quarter.

These posts reflect our ongoing commitment to sharing both technical knowledge and broader insights about building sustainable technology and fostering effective communication.

Spring Forward

Looking ahead to brighter days (literally and figuratively), we're planning to:

Refresh our website with updated case studies and service offerings
Experiment with turning Musicbox into a server-rendered Rails app just for fun
Find new ways to share what we've learned about platform intelligence and feature mapping

One thing we've learned from these seasonal recaps is that public commitment helps us follow through. So check back in three months to see if we actually did any of this!

Thanks for following along on our journey. We'd love to hear what you've been up to this winter – drop us a comment below.

Trust and Alignment in Sales Driven Software Companies

Dan Lavin — Thu, 20 Mar 2025 24:00:00 GMT

There is a natural tension that exists when building b2b software products.

Sales teams need predictable timelines to close deals and set customer expectations. Engineering teams need time and space to build maintainable products that scale with the business. Revenue teams push for faster delivery so they can meet this quarter's numbers. Product teams push back, concerned about long-term technical debt.

The push and pull is constant, but necessary.

But, is this a problem to be solved or a tension to be managed?

The best companies I’ve worked for don't eliminate this tension—they harness it. They create systems where both sales and engineering understand each other's constraints and work together to make smart tradeoffs.

This post offers practical approaches for both sides. If you're in sales or customer success, you'll find ways to get more reliable commitments from your product team. If you're in engineering or product, you'll discover how to protect what matters while supporting the business.

The best companies I've worked for don't eliminate this tension—they harness it. They create systems where both sales and engineering understand each other's constraints and work together to make smart tradeoffs.

Two Sides of Customer Value

Both sides of this tension are ultimately fighting for customer value, just in different ways.

For sales and revenue leaders, customer value means delivering on promises right now. Meeting this quarter's commitments. Closing the deal that's on the table. Keeping the customers you already have happy. When dates slip or features get delayed, it's not just an inconvenience—it directly impacts relationships and revenue.

For engineering and product teams, customer value means building something that lasts. Creating a coherent product that can evolve and scale. Avoiding technical debt that will slow down future delivery. When forced to take shortcuts or bolt on one-off customizations, they see the long-term impact on the product's foundation.

Neither perspective is wrong. They're complementary parts of the same goal: creating sustainable customer value over time.

Breaking Down Misconceptions

There's a common belief that engineers don't understand business priorities. That they're too focused on elegant solutions at the expense of practical outcomes. Too concerned with what's right in front of them.

Great engineers are systems thinkers. They're not just thinking about the current feature—they're thinking about how it fits into the entire product. They're protecting the product as a business asset.

I see it differently. Great engineers are systems thinkers. They're not just thinking about the current feature—they're thinking about how it fits into the entire product. How it might need to scale. How it interacts with existing functionality. How to build it so it won't break when other things change. In other words, they're protecting the product as a business asset. They're thinking about the customer experience six months from now, not just this week's deployment.

Similarly, great sales teams aren't just pushing for features to hit their numbers. They're responding to real customer pain points. They're trying to keep customers from leaving for competitors. They're working to maintain trust in relationships they've spent months or years building.

When engineers push back on timeline commitments, it's rarely stubbornness. It's usually because they see risks or complexity that aren't visible to non-technical team members. When sales pushes for faster delivery, it's rarely impatience. It's usually because they see business opportunities or threats that engineering might not be aware of.

The True Costs of Misalignment

When product tension isn't managed well, both sides pay a price.

For sales teams, missed deadlines damage credibility with customers. Repeated delays erode trust. Customers start to discount timeline commitments, making it harder to close new deals or expand existing relationships.

For engineering teams, constantly shifting priorities and emergency requests create a cycle of technical debt. Features get implemented in ways that solve immediate needs but make future work harder. The codebase becomes more fragmented and harder to maintain with each rushed delivery, leading to more time spent fixing bugs than shipping features.

For the business as a whole, the cost is competitive disadvantage. Companies that can't reliably deliver on promised timelines while maintaining product quality will eventually lose to those that can.

Create a Shared Framework for Decision-Making

The most effective teams I've worked with developed a shared language and framework for navigating this tension. Here's what that looks like in practice:

Different Types of Commitments

Not all deadlines are created equal. Create clarity by distinguishing between:

Hard commitments: Dates the business absolutely must hit (contractual obligations, regulatory requirements, major customer renewal dates)
Target dates: Goals the team is aiming for, with some flexibility built in
Forecasts: Best estimates based on current information, explicitly subject to change

Confidence Levels

Attach confidence levels to timeline estimates:

“We're 90% confident we can deliver by this date”
“We're 50% confident we can deliver by this date, and 90% confident by this later date”

This creates more nuanced conversations than simple yes/no commitments.

Clear Prioritization Criteria

Establish a shared criteria for truly urgent requests:

Revenue impact (with specific thresholds)
Number of customers affected
Strategic importance to long-term goals
Technical feasibility and impact on other work

When sales, engineering, and product all understand how decisions get made, there's a lot less friction when making tradeoffs and deciding what to prioritize.

Practical Steps for Sales Leaders

If you're on the revenue side of this equation, here are concrete steps you can take to improve alignment:

Involve Engineering Earlier

Don’t commit to a date without at least talking to someone on the engineering team. I know what it’s like to have your back up against the wall in a meeting, as the customer tries to pin you down for a date, but nothing puts an engineer on guard like being told they’re on the hook for something they didn’t agree to. A good way to prevent this is to include engineering leads in pre-sales conversations for big deals or complex feature requests. Doing this creates shared ownership of the commitment from the beginning of the process.

Don't commit to a date without at least talking to someone on the engineering team. Nothing puts an engineer on guard like being told they're on the hook for something they didn't agree to.

Frame Needs as Problems, Not Solutions

Instead of telling the engineering team exactly what to build, focus on the customer problem that need to be solved. "Customer X needs to reduce manual data entry by 50%" gives the technical team more flexibility than "Customer X needs these seven specific form fields that auto-populate."

Build in Buffer Time

When communicating timelines to customers, add buffer beyond what engineering estimates. The more complex the feature, the more buffer you need. A good rule of thumb: add 25-50% to any estimate for significant work.

Learn to Ask Better Questions

Rather than simply asking "when will it be done?", try:

“What are the biggest unknowns in this work?”
“What dependencies could impact the timeline?”
“If we had to deliver something by [date], what subset of this could we realistically complete?”

Be Transparent About Business Impact

Explain the real business consequences of timeline decisions. For example, ”If we miss this date, we risk losing a $200K annual contract" gives engineering context they may not otherwise have and helps them make more informed tradeoffs.

Practical Steps for Product and Engineering Leaders

If you're on the technical side, here's how you can bridge the gap:

Create Transparency Around Prioritization

Make your prioritization process visible and understandable to sales teams. They may not agree with every decision, but understanding the rationale reduces friction.

Communicate Constraints in Business Terms

Instead of explaining technical limitations in engineering jargon, translate them to business impact: "Taking that approach would double our maintenance costs for the next year and slow down our ability to deliver the other features on our roadmap."

Provide Different Confidence Levels

Rather than committing to a single date, offer multiple scenarios with different confidence levels: "We're 50% confident we can deliver by March 1st, 80% confident by March 15th, and 95% confident by April 1st."

Break Work Into Smaller Deliverables

Look for ways to deliver incremental value rather than all-or-nothing releases. "We can deliver the core functionality by January 15th, and these additional capabilities by February 1st" creates more flexibility.

Establish Regular Touch Points With Sales

Don't wait for escalations. Set up regular rhythms to discuss upcoming customer needs, review current commitments, and align on priorities. In my experience, bi-weekly or monthly tend to work best.

Create a process that builds trust and alignment

Ultimately, trust between teams is built through consistent behavior over time. Here are processes that support this:

Joint Problem-Solving

For complex customer requests or timeline challenges, bring sales and engineering together to problem-solve rather than having one side dictate to the other. Look for creative solutions that address both immediate customer needs and long-term product health.

Shared Visibility

Create dashboards or reports that show both sales pipeline and development progress in the same place. This helps both teams see how their work connects.

Commitment Tracking

Keep a simple record of committed dates versus actual delivery dates. Use this not for blame, but for learning: "We consistently underestimate work involving third-party integrations. Let's add more buffer for those going forward."

Blameless Postmortems

Engineering teams run blameless postmortem all the time, why not try applying it to your sales process? When deadlines are missed, analyze why without finger-pointing. Was the estimation process flawed? Did scope change? Were there unexpected technical challenges? Use these insights to improve future commitments.

Celebrate Joint Wins

Recognize and celebrate when the team successfully navigates this tension—delivering on sales commitments while maintaining product quality. This reinforces that both perspectives are valued.

The Alignment Advantage

Companies with a strong alignment between sales, product, and engineering have a significant competitive advantage. They can make and keep customer commitments more reliably. They build more coherent products with less technical debt. They retain both customers and engineers at higher rates.

I've seen this from both sides. As an engineer and product leader, I've felt the pressure of sales commitments that seemed impossible to meet. I've also seen the business impact when engineering couldn't deliver what customers were promised.

When sales and engineering trust each other, they make better decisions together. The goal isn't about perfect alignment—it's about harnessing productive tension to drive better outcomes for everyone.

Here's what I've learned: the gap isn't about technology or process. It's about trust and communication. When sales and engineering trust each other, they make better decisions together.

The goal isn't about perfect alignment—it's about harnessing productive tension to drive better outcomes for everyone.

Start small. Pick one or two practices from this post to implement. Create a shared vocabulary for different types of commitments. Establish regular cross-team touch points. Build trust through consistent behavior over time.

The most successful companies don't eliminate the tension between sales and engineering—they channel it to create something better than either side could build alone.

Scalable Web Scrapers

Harrison Strowd — Thu, 13 Mar 2025 24:00:00 GMT

We recently began working on a project focused on collecting publicly available data from a wide range of websites. These sites do not have publicly documented APIs, so we opted to crawl each site and scrape the relevant information from pages containing our target data.

To set ourselves up for long-term success and ease of maintenance, we thoroughly reviewed the available tools and services in the web crawling and scraping space. Below, we’ve summarized our analysis and shared insights into the approach we selected and our experience with these tools. We hope it proves helpful for others considering similar projects.

Context

Before diving into our analysis, it’s important to understand the context of our specific project. The following key characteristics guided our evaluation of each tool/service:

Number of sites to scrape: 10s to 100s
Desired scraping frequency (i.e., how often does the data change?): Weekly to monthly
Acceptable price range: Free or up to ~$50 per month
Target data format: JSON or other structured formats
Crawling requirements: Crawl all pages/links within an area of each target site
Site complexity (e.g., dynamic JS content, AJAX requests, etc.): Not likely
Expected scraping obstacles (e.g., CAPTCHAs, IP blocking, etc.): Not likely
Programming languages: Ruby, JavaScript, or hosted service with an HTTP API

Teams with different skills, larger budgets, or alternative goals for crawling/scraping might arrive at a very different set of conclusions when performing a similar analysis.

We thoroughly reviewed available tools in the web crawling space to set ourselves up for long-term success and ease of maintenance.

Evaluation Criteria

We leveraged a number of public comparisons of web scraping tools (source, source, source, source, and source) and identified 34 tools and services to evaluate. We based our evaluation on the following nine criteria:

Price: How expensive is the tool to operate on a monthly basis?
Tool/Service Type: Is this an open-source library we need to set up, maintain, and host ourselves? Is it a web platform that runs on its own? Or is it an installed application that runs on an individual’s machine?
Crawling Support: Does the tool support navigating an entire website and identifying pages of interest?
Scraping Support: Does the tool support extracting content from pages of interest?
JavaScript Execution: Does the tool allow JavaScript to run (e.g., enabling AJAX calls, opening modals, etc.)?
Interface/Programming Language: What interfaces are available for setting up and interacting with the tool? For open-source libraries, what programming languages are supported?
Scheduled Execution: Does the tool allow scraping to be scheduled and executed automatically on a regular basis?
IP Proxy Support: Does the tool allow proxying IP addresses to avoid rate limiting and crawler blocking?
Anti-Blocking Features: Does the tool offer anti-blocking features like CAPTCHA handling and fingerprint management?

Our complete evaluation and findings for each tool/service can be found in this spreadsheet.

We only gathered enough information on each tool/service to rule it in or out of further consideration. Therefore, you’ll find several empty cells in our results where this information wasn’t crucial for our decision-making.

We identified 34 tools and services to evaluate based on price, tool type, crawling support, JavaScript execution, and anti-blocking features.

Evaluation Results

After completing this survey of available tools/services, we selected three for hands-on experimentation. Here’s what we found:

Diffbot was powerful but expensive, Apify was too costly at scale, and Browse AI couldn't support full site crawling — none met our specific requirements.

Diffbot: Diffbot is a powerful tool, ideal for scraping data from unpredictable pages. You can drop any URL into the tool and get a structured dataset representing the page’s contents. However, when we tested their site crawling functionality, we encountered a blocker: the feature is only available with their "Plus Plan," which costs a hefty $899 per month. While this tool could be great for unpredictable pages, it didn’t fit our needs, as we had a predictable set of sites to crawl with structured data.
Apify: Apify lets you execute "actors," which are prebuilt or custom scripts for scraping specific websites. We couldn’t find an existing actor that suited our needs, so we developed a custom one. Using Apify’s actor templates made it relatively easy, but the performance was slow. Scraping 100 pages took around 10 minutes, making the solution costly—$0.286 for just the first 100 pages. This didn’t meet our scalability or cost requirements.
Browse AI{targ
et="_blank"}: Browse AI allows non-technical users to create web scraping robots using a point-and-click interface. Initially, it seemed like a good fit. However, when we tried to scale it by crawling all related pages on the site, we found that Browse AI doesn’t support full site crawling. Their workaround requires users to manually supply a list of URLs, which didn’t suit our needs.

Selected Approach

Ultimately, we chose Crawlee.dev, a Node.js library developed by Apify, as our solution. It’s the foundation for many actors on their platform, and it aligned with our team's technical expertise.

We initially tried using Playwright and Chrome for crawling in a headless browser, but the setup was complex, and performance was slow. We switched to Cheerio, a lightweight HTML parsing client, which provided a significant performance boost. Although this does not allow JavaScript execution or interaction with page elements, it has not prevented us from scraping any target data from the initial set of target sites we've deployed crawlers for.

We now run our Crawlee-based crawlers daily on Render using cron jobs, paying just a few cents per execution — an incredibly easy and cost-effective solution.

We also opted to run our crawlers on Render using cron jobs. Since we already had a Dockerfile set up for our application, the deployment took only minutes. We now run the crawlers daily, paying just a few cents per execution. The process was incredibly easy and cost-effective.

We’re very pleased with the results and believe this solution will scale to meet our needs. One potential challenge remains: how often will the structure of our target sites change in ways that require us to adjust our crawlers? Time will tell.

Have you built web crawlers or site scrapers in the past? What tools and techniques did you use? Any lessons learned that could help us? We’d love to hear your thoughts below. Stay tuned for more updates as we continue to develop this solution. Thanks for following along!

New Codebase Onboarding

Harrison Strowd — Thu, 27 Feb 2025 24:00:00 GMT

Jumping into a new codebase can be daunting. Whether you're joining a new team or tackling an unfamiliar project, getting up to speed efficiently is crucial. As a consultant, I've gotten practice joining well-established organizations and have developed some guidelines that help accelerate the learning curve on their systems. While I tend to progress through these steps in the order presented, feel free to adapt the approach based on your needs.

Jumping into a new codebase can be daunting. Getting up to speed efficiently is crucial.

Use the README

The README is generally the best place to start. It provides an overview of the application and essential context. Even if you don't immediately act on the information, it lays a solid foundation for understanding the system.

Here's how to make the most of it:

Read the README in its entirety and follow the setup steps it outlines.
Fix unclear, outdated, or incorrect information. This is a great way to contribute right away and familiarize yourself with the software development lifecycle (code reviews, approvals, merging, etc.).
Do some early "boy-scouting". Updating the README benefits future developers and showcases your attention to detail and commitment to continuous improvement.

Build a Mental Model

Understanding the system as a whole will provide context for your work. Seek answers to key questions such as:

Who are the end-users?
What internal systems and third-party services are used?
What are the roles and responsibilities of each component?
What data stores exist for runtime and reporting purposes?

If high-level architecture documentation exists, review it. If not, consider creating the following diagrams to solidify your understanding:

System Diagram: Identify end-users and applications (internal and external) with their roles and responsibilities.
Component Diagram: Document the features/components within the application and their dependencies.
Workflow Diagram: Capture the primary user journey, highlighting key actions and decision points.
Data Model Diagram: Create an Entity-Relationship Diagram (ERD) to visualize core data models and their relationships.

While these diagrams will benefit the team as a whole, the real value lies in the deep understanding you gain by creating them.

Not sure where to start in crafting these diagrams? Reach out and we can provide some examples from our personal/internal projects or guidance for your specific case.

While these diagrams will benefit the team as a whole, the real value lies in the deep understanding you gain by creating them.

Learn to Test the Application

Hands-on experience is invaluable when familiarizing yourself with a new codebase. Start testing the application by:

Walking through the end-user journey if the application has a frontend.
Sending test API requests to simulate workflows.
Exercising the system's features that you'll be responsible for (e.g., triggering background jobs, running integration tests).
Shadowing engineers or QA team members to gain insights into testing processes.
Over-testing your changes early on to catch potential bugs in your local environment.

This investment of time will pay off as you begin making functional changes with confidence.

This investment of time will pay off as you begin making functional changes with confidence.

Extend Engineering Utilities

Building and improving engineering utilities will benefit both you and your teammates while accelerating your onboarding. Depending on existing team tools, consider:

Creating a Postman or Paw collection of test API requests.
Extending or organizing existing test request collections.
Filling in gaps in unit or integration test coverage.
Improving reporting dashboards for the areas you'll be working in.
Adding or improving documentation (e.g., glossary, getting started guide, etc.).

These initiatives can be self-directed, giving you hands-on experience while providing immediate value to your team.

Find an Area to Go Deep

Once you have a solid grasp of the system, it's time to specialize. Work with your manager or teammates to identify a moderately complex feature or area with changes or improvements to be made.

Choose something substantial enough to involve multiple tasks but manageable within a week or so.
Dive deep into this feature, implementing changes and collaborating regularly for feedback.
Aim to become the "go-to" person for this area, taking on technical ownership beyond simply completing tasks.

Developing expertise in a specific area allows you to contribute in more impactful ways beyond incremental code changes. As your knowledge grows, you'll also be in a better position to provide insight into the application's architecture and influence the team's technical direction.

Developing expertise in a specific area allows you to contribute in more impactful ways beyond incremental code changes.

What else?

By following these steps, you'll gain a comprehensive understanding of the codebase, contribute meaningful improvements, and set yourself up for long-term success within your team.

Do you have other strategies you follow when getting up to speed on a new codebase? If so, we'd love to hear about them. Drop us a note below, and thanks for reading!

Pitching the Refactor

Truman Shuck — Thu, 06 Feb 2025 24:00:00 GMT

I am a literalist at heart. I don't mean that I dislike or avoid metaphor, but when it comes to methods, modules, and projects I tend to stick to "ah, does exactly what it says on the tin" territory. This works pretty well with code written for initiatives that are self-evidently valuable. Ah, the def send_email! method in module RetargetingCampaign which retargets folks who have dropped out of the funnel to give them another opportunity to give us money. Makes sense!

Things get a little trickier with engineering-led initiatives: Upgrade Rails, Refactor User Services, Clean up Auth. All of these become necessary to do at some point when aspects of the system start to cause a disproportionate number of issues. Edge cases are harder to spot in disorganized code, so risk increases. Legacy features need to be untangled before new ones are introduced, so velocity decreases. Engineers don't enjoy working with bad tools, so finding and keeping folks around becomes more difficult.

"Good" code is not inherently valuable, but work that makes code better so that it can better serve people is.

This is not a post about the technical debt metaphor, or a discussion of the distinction between "good," "bad," or "fine to leave alone for now" indebtedness. Eventually some extra attention has to be given to the care and feeding of a system. This is a post about the importance of language. It's about communicating the need to pause work on the thing that the non-technical leadership knows is good for the business — for the arcane and incomprehensible work of keeping a technical system well organized ("I'm sorry, did you say that we need to stop for a week to upgrade the 'gem'... 'nokogiri?' because of an issue with 'native extensions' for our 'ubuntu image???'") which is, of course, also good for the business.

Explaining Why

Technical debt is, itself, a metaphor constructed to help non-technical folks understand the responsibilities inherent in maintaining a system. But beyond the vague idea that most debts have to be paid eventually, this metaphor is not specific enough to be motivating. Prefixing a project as "Technical Debt: add test coverage" does very little to communicate the underlying value of the work. "This is a debt," the director of product says, "but we should defer payment while we smooth out the bumps that are causing drop-off in the funnel."

This is not an incorrect opinion, but a potentially under-informed one. "Good" code is not inherently valuable, but work that makes code better so that it can better serve people is. Adding test coverage is itself a worthless activity. "Reduce the likelihood of errors in the sign-up funnel" provides a clear indication of why the work is important to do, now.

When we can re-frame cleanup, refactoring, or other "tech debt" activities in terms of the value that they provide, we clearly communicate why they are worth doing in the first place. This process also serves to reinforce to ourselves that they are worth doing in the first place, too. And "value" does not always have to directly reference the end-user: "Untangle the Pit of Despair (User Model) which causes 25% of new hires to quit in a fit of madness" is also a useful, if hyperbolically verbose, project.

When we can re-frame cleanup, refactoring, or other "tech debt" activities in terms of the value that they provide, we clearly communicate why they are worth doing in the first place.

Aid Future Investment

Growth begets complication, and as a project grows there's always some specific decision that makes life especially difficult for continued development. It's choosing to hand-roll the Slack integration because it's just one simple message instead of investing in learning and configuring the whole library.

Sometimes it's better to do what's quick and easy, now. But later, when half of the internal tools are based on Slack bots, that home-grown integration becomes a tangled thicket to work within. Every additional feature requires more attention, testing, review. Every additional feature itself adds to the complication.

Communicating is difficult, and doing it well requires a fair amount of empathy: understanding what the other person knows, where their priorities lie, how they'll interpret the one-line epic title.

When maintenance is tied directly into recognized future value, it's even easier to communicate its importance. Yes, we can add a new internal Slack robot that helps our customer success team find answers to frequently asked questions — but we're going to include work to replace our custom integration with the off-the-shelf version. Yes, this will delay CSBot's roll-out a bit, but it will greatly speed up the next three chat features we saw on the roadmap.

Communicating is difficult, and doing it well requires a fair amount of empathy: understanding what the other person knows, where their priorities lie, how they'll interpret the one-line epic title that represents weeks of effort for the company. And look, I still don't really understand what EBITDA means, or how to weigh the ingredients in the "marketing mix," when the business folks describe what's important to them.

So taking time to frame necessary technical maintenance in a way that expresses its value — in addition to clarifying that value for myself — is one small way to help my coworkers. And to avoid a long conversation about how important it is, actually, to upgrade Rails because dependency management is starting to become a nightmare . And don't get me started about those native gem extensions.

Do you have strategies that help communicating with other folks at your company? Do they involve typing in all caps? We'd love to hear about them, below.

Thanks for your time and attention.

Slack Development Lessons - Part 2

Harrison Strowd — Thu, 30 Jan 2025 24:00:00 GMT

During our most recent product building cycle, we experimented with developing a Slack app for Marginal. As engineers who primarily work on Ruby on Rails applications, this gave us an opportunity to dive into an entirely new tech stack. The joy of discovery and learning something new was really refreshing. However, this exercise was not without its fair share of challenges and hurdles to overcome.

In part one of this series, we shared a few of these lessons. Here we'll cover the remaining items that we found most surprising or challenging about developing Slack applications.

Slack App Interactivity

Marginal helps teams host a weekly discussion about an article they read, a podcast they listened to, or a video they watched. Each participant records items they'd like to discuss with the team and the application presents these in a round-robin manner during the meeting, giving each individual an opportunity to direct the discussion.

The process of scheduling discussions, collecting participants' thoughts, and conducting the meeting are all highly interactive. Each new discussion requires information about the article, podcast, or video to be collected and for the team to be notified and reminded about the discussion. During the meeting each participant reviews the ideas they captured and selects one to present to the team. The application then displays this idea to all participants, along with a button to move on to the next presenter.

The set of user experiences (UXs) supported within a Slack app is quite constrained. A message can be sent to a channel/individual, the app can expose slash commands or shortcuts for users to invoke, and in some cases a modal can be launched for a single user. As a result, many applications maintain very simple interactions with their users (e.g. presenting static information, posting a message with 1-2 buttons that support a limited set of responses, etc). We were initially concerned that the highly interactive experience we envisioned for Marginal would be difficult to implement, if possible at all. However, this turned out to be an unfounded fear.

The set of user experiences supported within a Slack app is quite constrained, yet we discovered that implementing highly interactive experiences was surprisingly feasible.

Phoning Home (Just Like E.T.)

When an app posts a message containing interactive components (e.g. buttons, text input fields, dropdown lists, etc), modifying these elements immediately triggers a request to the application's backend service. The payload received by the application in these instances includes a response_url attribute (docs). By sending a POST request to this URL, the application can quickly and easily update the layout for the originating message (e.g. replacing the input field with a success message, showing then next set of form elements for the user to fill out, etc).

This allows the application to focus on detecting the action that was taken and the feedback that should be provided to the user about the results of this action. Notably this avoids the need for a lot of boilerplate logic related to looking up the ID and channel of the originating message, retrieving/generating/refreshing the authentication token for this request, or other similar operations that would be necessary without this nicely packaged URL.

For an application like Marginal that relies on numerous interactions, Slack's response mechanisms add up to significant savings in the overall complexity of the application.

A similar set of utilities are also provided for updating modals quickly and easily upon submission (docs). These mechanisms make it easy to efficiently support the back-and-forth interactions between users and applications that result in a delightful user experience. For an application like Marginal that relies on a large number of these types of interactions, this simplicity adds up to a significant savings in the overall complexity of the application.

Slack Messages ≠ Forms

While the ability to rerender messages and modals was surprisingly easy, there were other aspects of the UI for Slack apps that were more challenging than initially expected. Coming from a web development background, we unknowingly brought a set of assumptions about how state would be managed throughout the workflow of this application. Namely that backend service requests would be submitted upon completion of a form or modal.

Based on this assumption, we initially designed the discussion setup message in the same way we would if we were displaying it on a web page:

Experimenting with this form, we discovered that each interaction with a dropdown field is delivered to the app individually. This makes the "Submit" button completely unnecessary, and as a result we ended up dropping it entirely. Instead each dropdown field operates as an isolated mini-form. They are submitted to the backend service individually and upon success are replaced with a message informing the user that this value was collected.

However, collection of these values is just the first in a series of actions the user takes to configure the discussion series for their team. As a result, when both dropdowns are successfully submitted, the message needs to be entirely replaced with the next step in this workflow. The lack of a single submit operation for the entire form made this condition more challenging to detect.

Instead, we have to identify the current version of the message being displayed (i.e. what step in the flow is the user on) and explicitly check each field to verify that a complete and valid set of inputs have been provided. There is very little client side validation that can be done in these forms, so all of these input validation checks must be performed within the backend service. Only once all inputs are validly populated will the next form in the workflow be presented.

Developing for Slack requires a paradigm shift in how we think about UI state management—each interaction is submitted individually, creating both challenges and opportunities.

While the additional logic required for this very simple, two input form was minimal, this complexity grows exponentially as the information being collected and the length of the workflow grows. This is compounded further in applications that support many such workflows, as would be the case for Marginal.

Death By 1,000 Edge Cases

On top of this, the submission of each field to the app's backend service individually has implications on UX edge cases like the following:

Partial Form Completion: It's possible for the form to be abandoned after some but not all inputs have been submitted. For forms that represent a required step for the application, the user will eventually need to be prompted to restart or continue this process. To support this, the partially complete state of the form either needs to be stored and the user needs to be prompted to provide only the remaining information or if the form is discarded, the original message collecting this information would need to be updated to reflect that this form has now expired. Maintaining values from a partially complete form can be difficult, particularly in cases when the remaining fields are required attributes on the associated application model or DB table.
Concurrent Request Handling: Messages posted in a channel are visible to all users in that channel and can be interacted with simultaneously. This makes it possible for an application to receive concurrent operations related to the exact same message. We did not go to this level of detail in the development and testing of this prototype but it would be a necessary consideration for the production-ready version of this application.
Related Input Constraints: Forms containing interdependent input constraints require extra planning/consideration. For example when collecting a pair of date and time inputs that must represent a time in the future, the backend application is responsible for presenting only dates/times that are in the future depending on the value that was selected in the other input field. You could choose to present these inputs in succession, showing the time input field to the user only after a value is provided for the date input field. However, for applications collecting a number of input values, this results in a lengthy sequence of inputs presented consecutively, which can frustrate users.

Overall this feels like a paradigm shift in the way we will need to think about receiving and processing events from the UI for a Slack app. It will take some getting used to and may require some new utilities and patterns to manage effectively, but it also has the potential to unlock new UX capabilities that would not have been feasible for a web application.

Block Kit Constraints

Slack apps use a framework called Block Kit to define their various user interfaces, including messages, modals, and App Home tabs. This framework provides a sufficient — but still somewhat limited — set of components for structuring and formatting the content to be displayed. Coming from a browser-based UI environment where a combination of JavaScript, HTML, and CSS can produce nearly any UI/UX under the sun, this was naturally going to feel a bit constraining.

The biggest limitation we encountered was in the layout and placement of elements within Block Kit UIs. The layout is primarily defined by an array of block elements, each of which is rendered vertically, one after the other. The Section block is one of the only elements that can be composed of other blocks and renders them side by side. Even still, it limits the contents of the left side of the section to text/markdown content and the right side of the section to a single element chosen from a handful of supported types (e.g. an image, an input, or a button).

Once we got comfortable working within these constraints and polished up our markdown skills, we found we could produce all the user experiences needed for this prototype, including interactive public messages, threaded messages, modal forms, and messages visible to a single user.

With great power comes a lot of JSON

Block Kit UIs are defined as an array of JSON objects. With each element requiring a number of attributes and many containing nested elements, the payload describing even a relatively small UI gets quite large.

Despite Block Kit's constraints and verbose JSON payloads, we found we could produce all the user experiences needed—a testament to what's possible within Slack's ecosystem.

For example, the following is a fairly simple modal UI we implemented as part of this prototype:

Rendering this modal required the following Block Kit payload to be generated:

{
  "type": "modal",
  "title": {
    "type": "plain_text",
    "text": "Create New Discussion"
  },
  "blocks": [
    {
      "type": "section",
      "text": {
        "type": "plain_text",
        "text": "Add an article, podcast, or video for an upcoming discussions.",
        "emoji": true
      }
    },
    {
      "type": "divider"
    },
    {
      "type": "input",
      "label": {
        "type": "plain_text",
        "text": "Title",
        "emoji": true
      },
      "element": {
        "type": "plain_text_input",
        "multiline": false,
        "placeholder": {
          "type": "plain_text",
          "text": "Full title of content",
          "emoji": true
        }
      }
    },
    <=== 76 LINES REMOVED ===>
    {
      "type": "input",
      "label": {
        "type": "plain_text",
        "text": "Duration",
        "emoji": true
      },
      "element": {
        "type": "plain_text_input",
        "multiline": false,
        "placeholder": {
          "type": "plain_text",
          "text": "Number of minutes",
          "emoji": true
        }
      }
    }
  ],
  "close": {
    "type": "plain_text",
    "text": "Cancel"
  },
  "submit": {
    "type": "plain_text",
    "text": "Save"
  },
  "callback_id": "discussion_create",
  "private_metadata": { "source_channel_id": "C0573NGLYBU" }
}

As a result, we ended up with large JSON payloads scattered throughout the business logic that powered this prototype. In a production-ready implementation we would need to find a cleaner way to support the serialization of these payloads, extracting them more clearly from the logic that manages the internal workings of the application.

Overall developing this prototype was a really fun exercise. We learned a lot in the process and hope that thoughts and tips we've shared here and in the previous post prove helpful.

Are you working on a Slack app or considering it? If so, we'd love to hear more about the project you have in mind or questions/issues you've encountered working in the Slack ecosystem. Drop us a note in the comments below and thanks for reading.

Fall '24 Recap

Dan Lavin — Thu, 23 Jan 2025 24:00:00 GMT

Intro

We try share a brief recap at the start of each season. These updates help folks follow our journey at Go Between, but they're also for us. We often get so wrapped up with work and life that we forget to pause and reflect. These recaps help us remember what we've accomplished.

This recap covers Fall 2024 – a big season for Go Between!

Sometimes you grow by choice, sometimes by necessity. This fall we did both.

"I ain't reading all that"

Truman became a dad!
We started working with a new client on a really fun and exciting project.
We officially started working in cycles–completing our first rounds of product and audience building.
We finally finished the RSS feed that our "massive" audience has been demanding.

Go on...

Let's start with the biggest news: In October, Truman and his partner Carrie welcomed their first child into the world. Welcome to the Go Between family baby Eleanor! Harrison and I are both excited for Truman to finally understand what it means to be tired!

While we definitely felt Truman's absence during the early stages, it pushed Harrison and me into new territory.

Around that same time, we started a new consulting engagement. We've been helping a financial services company better understand their growing platform by creating internal tools that help product and engineering leaders to do things like: surface key insights, quickly identify areas of the codebase that require attention, track the impact of releases, and assess the overall health of the system. While we definitely felt Truman's absence during the early stages, it pushed Harrison and me into new territory. We found ourselves tackling challenges we might have normally bounced off him first and growing in unexpected ways.

We also officially started "working in cycles" which is a strategy we discussed during our last Summit to add more structure to our non-consulting time. We kicked off fall with a product cycle, re-imagining Marginal as a Slack application. We spent ~6 weeks doing product discovery, exploring the Slack API, and building a proof of concept to validate our technical assumptions. We wrapped up by writing a product pitch for building the first version of our Marginal Slack app.

Then we shifted to audience building: writing blogs and posting on LinkedIn. Highlights included the final post in our consulting lessons series and a recap of what we learned about building Slack applications. We also shipped an RSS feed. A few people had asked for this months ago, so it felt good to deliver.

We officially started "working in cycles" which is a strategy we discussed during our last Summit to add more structure to our non-consulting time.

All in all, a pretty great fall season!

Sunk Cost

Truman Shuck — Thu, 16 Jan 2025 24:00:00 GMT

You keep hitting ↑ in your terminal because you're looking for a command that was just there. It's been thirty seconds. You can't find it. It's been two minutes. It feels like two hours. You experience sunk cost in the sunken feeling in your chest, the sinking of your fingers as they come to rest back on the home row.

Doing something because it's been done before. Doing something because not doing it anymore would feel like failure. Doing something because otherwise all of the other somethings you've done would have been a waste. There are many articles on how the sunk cost fallacy applies to software architecture and to product teams:

It's okay if you over-invested in those JSONB columns, but you could start making relational tables again after their performance tanks.
It was fun to learn that bleeding-edge JavaScript framework, but you could better support your business if you wrote the next thing in the boring technology where at least request routing is a solved problem.
It is neat how much you can program into those little blocks in Notion, but another hour of tweaking your home-brewed task management system is better spent moving everything to Linear and then never thinking about it again.

This article is not about the big mistakes. It's about the small ones that I find myself continuing to make today and what I try to do instead.

Doing something because it's been done before. Doing something because not doing it anymore would feel like failure. Doing something because otherwise all of the other somethings you've done would have been a waste.

I wasn't kidding about the up arrow

There are many jokes, and some truths, about the virtues of laziness in software engineers. Automating the simple instead of trudging through the tedious is a hallmark of software development, and what feels more tedious than looking up the correct flags for a complicated command you know you just executed the other day? When you're trying to un-stage the latest commit on your git branch, or hoping to remember all of the subcommands required to generate that aws token. You know it starts with git reset and where does that HEAD~ something go? It's definitely aws oh of course security token service get-session-token something?

It might be in terminal scrollback, and it might be found with enough invocations of the "up" arrow. Often as not it's in another shell, or it's been pushed out of recent history. Often it's gone; back to --help for tar -x...z..? f? ....

Instead, add a shell alias, alias grs="git reset --soft HEAD~1", so you can git reset in two commands instead (wait what did I call that one? cat ~/.zprofile, oh yeah.) Better yet, grep it out: fc -l | grep git reset. Best, reverse search shell history with ctrl+r on the fly. Whatever you do, stop hitting ↑. Well, maybe just once. And just once more. I swear it's right here somewhere.

Refactoring: An Unknit Sweater

Sometimes I do think that you have to grab your seam ripper in order to pull everything apart and start fresh. But in the middle of implementing an otherwise small story is often not the time. "Ah," I've thought to myself, "it's this feature which is finally exposing what's felt so awkward about this module." I grab some coffee. "So if we could extract all of this stuff, and rename a couple of these files," as caffeine propels me, "and that would imply a change to this structure..." and slowly a whole sweater has unraveled in my lap.

Save it for the backlog! No, that's where cleanup tasks go to molder. Bring it up in a retro, or your recurring technical check-in meeting.

So I implement a small feature in five lines instead of fifty, which is great. But it's on top of a pull request that has five hundred lines of refactoring, which is asking a lot of my code reviewers. At least the tests pass, except I had to refactor a few of those too since they were a little too tightly coupled to the previous implementation.

Save it for the backlog! No, that's where cleanup tasks go to molder. Bring it up in a retro, or your recurring technical check-in meeting. Get some folks on board or at least let them know you're planning on doing a bit of cleanup soon. But first just implement the small feature so that your users can get a bit more value out of your work and you in turn can continue to afford your coffee.

Git Rebase Heck

Implementing something novel can be a long and meandering road. I'm a proponent of the "Make it work, Make it Nice [Right, Beautiful], Make it, eh, reasonably fast — or at least don't do anything too dumb" workflow. When executed in the context of a single pull request, this means going over the same source files a handful of times of the course of a bunch of commits. It also means that folks will usually have merged at least one or two unrelated changes into those same source files while you were on your winding journey.

It's nice to freshen up a feature branch before opening a pull request, and I usually prefer to do so with a rebase from the main branch. If one of those well-trodden source files has a conflict, I often find myself resolving it three or four times in a succession of subtly different flavors. "I'm so close to getting back to HEAD," I think, as I try to remember which branch is upstream and which version of a given change I want to include. git rebase --continue becomes another mantra.

I've fallen victim to this fallacy plenty of times in my career, and these won't be my last sunken costs. But it's nice to recognize at least a couple of the places where I no longer have to spend time if I don't want to.

Sometimes it is better to grab the thread ripper. Grab your commit shas out of git log and cherry-pick them onto the top of latest main:

git checkout ORIGINAL_BRANCH

# keeps my original messy branch
# and keeps the commits I'm gonna
# cherry-pick in the reflog.
# They would probably stay there
# anyway but better safe than sorry.
git checkout -b ORIGINAL_BRANCH-BACKUP

# delete my local copy of the messy branch
git branch -D ORIGINAL_BRANCH

# go find up-to-date main
git checkout main
git pull origin main

# then re-create the original branch
# from the updated main
git checkout -b ORIGINAL_BRANCH

# and cherry-pick back in the work I want
# repeating for all commits
git cherry-pick <commit sha>

# finally we have to force push
# because we changed history
git push origin ORIGINAL_BRANCH --force

I've fallen victim to this fallacy plenty of times in my career, and these won't be my last sunken costs. But it's nice to recognize at least a couple of the places where I no longer have to spend time if I don't want to. Do you have tips on avoiding other time-sinks? Maybe you just like the meditative action of continuing to press ↑ until you find what you're looking for. We'd love to hear either way, below.

Thanks for your time and attention.

Winter '25 Now Update

Go Between — Thu, 09 Jan 2025 24:00:00 GMT

Ever wonder what the folks behind the curtain at Go Between are up to? You may only think of us as the singular juggernaut of exceptional software-adjacent content writers that we've become — or if you've worked directly with us, perhaps as three pretty darn good engineers.

We write mostly about how we approach, consider, and execute the work of software product building, but we'd like to give ourselves a little more dimension. We're taking a cue from Derek Sivers and publishing a "Now" page. Take a look to find out what Dan, Harrison, and Truman have been up to as we start the winter season.

https://gobetweenlab.com/now

You are also a fully dimensional human behind the chittering of your keyboard and chattering of your video calls. Do you have a now page? What have you been up to lately? We'd love to hear about it, below.

Software in the Winter

Truman Shuck — Thu, 02 Jan 2025 24:00:00 GMT

There are as many personal metaphors about writing software as there are people who write software. To say that programming lends itself to metaphor isn't quite right; software demands metaphor. I type with my hands, but everything I create is intangible and imaginary. The only way to talk about it, or to reason about it, is in a language-by-proxy. Otherwise it doesn't really exist. So writing software is a recipe, or a blueprint, or a polymorphic mammal that quacks or barks.

This one has to do with gardening, although I'm really no great gardener; my partner is generally the one to maintain our planters of parsley and cilantro, and I still get confused between the two. So this will be as maladaptive as any metaphor.

Software demands metaphor. I type with my hands, but everything I create is intangible and imaginary. The only way to talk about it, or to reason about it, is in a language-by-proxy.

It's not about cultivating code, or about pruning technical debt. It's not features as flowers. It's concerned with the later seasons: as the autumn passes and winter arrives. What it means to harvest, to care for the soil, and to spend time in reflection while the ground is hard and little grows. What it means to reap knowledge of a domain, to maintain clear and coherent systems, and to use that understanding to continue growing ever more useful products.

How we allow the ground to lie fallow, how we plan to grow again in the spring.

The "ideal" trajectory of a business, in the world that we find ourselves in, is to grow constantly and continuously. This has certain implications for the products that we build. And if we could just keep adding features and their prerequisite lines of code without issue, constantly and continuously, I wouldn't have much to write about. I don't think that that's possible.

We start writing anything — a project, a feature, a variable name — when we have the least knowledge of how it will be used, and how it should be structured, and how it will be built upon. We're not prescient so we rely on conventions, assumptions, and intuition. This shaky ground does not firm up until we're at the very end of our process. We look back and say "well the name of this variable, and the structure of that service class, and composition of those jobs, aren't quite right."

This has certain implications for the systems that support the products that we build. We can hopefully refactor our intra-feature work before we open a pull request. We might set aside regular time to address technical debt and be able to go a little deeper. It is not often that we have the opportunity to address systemic issues that arise in the organization, the structure, the fundamental decisions that underlie our work.

We start writing anything when we have the least knowledge of how it will be used, how it should be structured, and how it will be built upon. This shaky ground does not firm up until we're at the very end of our process.

The harvest requires that we interrupt a natural process. We kill part of a plant. We take its fruits. We bake a pie. Here is the least actionable advice I might ever write: every year, starting when the frost first sets in, pause new work for about a month. Reflect. Identify assumptions that have grown to be untrue; find fundamental metaphors that no longer make sense. Think especially about where past decisions have limited the way that your system could evolve in the future. Reap what you've learned. Sit with your new knowledge. Unearth for your hidden myopia.

What if this system were evented instead of callback-driven? What if we extracted this package as a separate running service? Could we make this whole thing asynchronous? What would happen if we folded this back into our monolith? What if we could server-render instead of host a single-page app? Is this actually still polymorphic or has it diverged? What if we could get rid of all of this locking? What if this were message-based instead of API-based? Could we build this to better suit ourselves instead of paying for a generic solution? Could we pay for this instead of maintaining it?

Rewrite your product from scratch. Okay, maybe don't: this probably introduces as many new bugs as it resolves. But rewrite a large subsystem. At least finish up that half-started migration to the new pattern in your service objects. We miss the opportunity for meaningful reflection and meaningful change when we run from sprint to sprint without making room for other rhythms in our work. We can be grateful for the pause and reflection automatically given by nature to our raised-bed gardening. We have to do the rest ourselves.

Every year, starting when the frost first sets in, pause new work for about a month. Reflect. Identify assumptions that have grown to be untrue; find fundamental metaphors that no longer make sense.

Have you found ways to set aside time to reflect on the software you or your team have created? Have you done the big-bang rewrite and it's gone perfectly, or not so perfectly? We'd love to hear about it; drop us a line below.

Thanks for your time and attention.

Slack Development Lessons - Part 1

Harrison Strowd — Thu, 19 Dec 2024 24:00:00 GMT

For the past six weeks, we've been dedicating our “20% time” to prototyping a Slack application that brings the functionality of Marginal directly to teams in Slack. After sketching out our vision for how users might interact with Marginal within Slack, we dove into technical discovery and pieced together a prototype. The goal? To uncover and mitigate potential risks while we explored what's possible with Slack's development tools.

This hands-on process taught us several valuable lessons that will shape the future development of a full-fledged version of this application. In this post, we'll cover three key takeaways from our experience, but there's also more to come in a subsequent post. So keep an eye out for Part 2, where we'll share additional lessons from this exercise.

1. Breaking Habits Is Hard (But Sometimes Necessary)

After spending decades refining good engineering habits, abandoning them—even temporarily—can feel counterintuitive. Practices like:

Prototyping requires loosening the reins on perfectionism. And that's okay.

Self-reviewing code before committing
Refactoring for clarity and simplicity
Writing meaningful documentation
Including quality test coverage

…are second nature to engineers aiming to deliver high-quality, maintainable work. These habits are invaluable when building production-ready applications impacting thousands or even millions of users. However, when prototyping, these practices can slow you down. The goal of a prototype isn't to ship polished, scalable code but to quickly experiment, learn, and reduce risks.

While I knew these habits were unnecessary for this prototyping exercise, I still ended up falling back into them for the first half of the six week cycle we alloted for this work. With 3 weeks burned, I had only established the Marginal data model in the new backend service. While well-documented, covered by tests, and ready for production (if it existed), progress was slow. At this point I finally cut ties with these habits and started hacking through the remainder of the technical discovery work. Over the course of the next week, I experimented with all the Slack integrations we identified as unknown or high risk, including interactive messages, ephemeral posts, modals, and message threads.

This experience highlights the significant productivity cost (5-10x) of developing features robustly versus quickly hacking them together.

This experience highlights the significant productivity cost (5-10x) of developing features robustly versus quickly hacking them together. While this is certainly a high price to pay, in most cases it is a valuable investment in avoiding bugs, minimizing technical debt, and future engineers (i.e. your future self) from headaches while building on top of this work.

Lesson learned: Prototyping requires loosening the reins on perfectionism. And that's okay.

2. Limited Ruby Framework Support

Coming from the Rails community, we hoped to find a robust gem or Rails-like framework for building Slack apps in Ruby. Instead, we found a fairly sparse set of development tools available, with the Slack Ruby Bot Server standing out as the best option.

This server does a good job simplifying the Slack app setup operations (e.g., OAuth, event subscriptions) and handles core integrations like slash commands and interactive messages. There are also sample apps that provide helpful insights into using the framework for specific cases, such as consuming Slack events or integrating paid subscriptions with Stripe.

Ruby's Slack ecosystem is functional but far from plug-and-play. Be prepared for extra groundwork.

We greatly appreciated having the Slack Ruby Bot Server as a starting point to work from but for engineers coming from a Rails development environment, you may find some aspects of this framework more challenging than expected. In particular, we discovered:

The Ruby Slack Bot Server lacks prescriptive structure for organizing business logic. Without careful planning, complexity can spiral into chaos.
Key features, like modal submissions, are unsupported out of the box.
For teams with an existing Rails application, maintaining a standalone Slack backend service adds unnecessary overhead.

One potential workaround is mounting the Ruby Slack Bot Server within a Rails app, as outlined in this article. This approach might allow us to leverage Rails' strengths while integrating Slack's functionality. It's something we'll explore further.

Lesson learned: Ruby's Slack ecosystem is functional but far from plug-and-play. Be prepared for extra groundwork.

3. Slack Is Not The Web

After years of building web applications, we've internalized many assumptions that don't carry over to Slack. For example:

Audience scope: Web apps are built around the idea that each each page or request is served to an individual user. Slack apps, on the other hand, interact with an entire workspace, meaning actions and visibility aren't limited to a single person.
Error handling: On the web, a quick page refresh fixes many issues. In Slack, an error during an interactive event might mean you completely lose the opportunity to notify the user or update a message.
Workflow constraints: For instance, modals can only be triggered in response to specific events (e.g., button clicks or slash commands), and inviting a user or app into a channel isn't a supported event.

In many cases these quirks require some rethinking of workflows and user experiences.

Slack's environment introduces unique challenges that demand creative solutions.

For example, our initial plan was to pop a modal when the Marginal App is added to a channel, allowing the user to quickly and easily provide all the information necessary to configure a series of Marginal discussions for this team. However, since there are multiple events that can result in an app being added into a channel, Slack does not allow modals to be triggered from this event. Instead, we had to post a message into the channel that prompts the user to provide the necessary information there.

Initially, this channel setup message included two dropdown input fields and a submit button. However, Slack's interactive messages don't operate like a web form where all information is collected in the client's browser and then submitted to the server in a single event. Instead, each interaction with a single element is delivered individually. We dropped the submit button altogether and implemented server-side logic to detect if all required inputs were complete.

This makes some cases far more challenging to distinguish and handle. For example, when a user interacts with one of the two dropdowns we presented, is this an indication that they didn't see or don't want to make a selection for the other dropdown? Or are they simply working their way through the series of inputs and just haven't reached that one yet?

These are just a few examples of how our web development paradigms had to shift to meet Slack’s requirements.

Lesson learned: Slack's environment introduces unique challenges that demand creative solutions.

Parting Thoughts and Next Steps

Prototyping our Slack app taught us invaluable lessons about adapting workflows, navigating Ruby's limited Slack ecosystem, and working within Slack's unique constraints. These insights will guide us in building the full-featured app and hopefully save us and others from headaches along the way.

Stay tuned for Part 2, where we'll dive into more lessons and takeaways from our Slack app development journey. In the meantime, have you worked on developing a Slack app? Are there other pitfalls we haven't encountered... yet? If so, we'd love to hear from you! Let us know your thoughts in the comments below.

Marginal for Slack

Dan Lavin — Thu, 12 Dec 2024 24:00:00 GMT

Overview

Go Between is a small team of software engineers and product designers. At our core, we're builders, not marketers. This is why we originally built Marginal. We thought it would be cool to build something that encouraged remote teams to form better relationships with their coworkers through weekly discussions, so that's what we did. We knew finding customers would be hard, but sometimes you have to experience the pain yourself in order to truly understand it. And so, despite having what we believed to be a strong value proposition, increasing awareness and onboarding new customers proved extremely difficult. Shocking, right?

At our core, we're builders, not marketers. This is why we originally built Marginal. We thought it would be cool to build something that encouraged remote teams to form better relationships with their coworkers through weekly discussions.

However, before laying Marginal to rest in the product graveyard, we've decided to explore what Marginal might look like as a Slack application. Slack is intriguing for two primary reasons. First, it comes with built-in distribution via the Slack Marketplace. As we've mentioned countless times, we're not marketers, and getting your product out there takes a lot of time and energy that we don't have. So our hope is that we can use the Slack Marketplace to get a few more eyeballs on Marginal. Secondly, Slack provides a more seamless onboarding experience than the web-based version we have today. Instead of forcing users to do things like create a new account, learn a new interface, or remember to visit yet another website, we can meet potential customers where they are with a simple slash command.

We don't plan on reducing consulting hours to support this project, so our appetite will be time-boxed to a single 6-week product cycle, with each of us contributing around 3-5 hours per week.

System Design

Before we get into the features we plan to support, let's quickly review the technical design for this application. Since we'll only have a few hours each week to work on this, we need a system that lets us move fast while also taking advantage of the functionality already developed in the Marginal web app. To balance these competing objectives, we'll use the Slack Ruby toolkit to stand up a new backend service, connecting to a database shared with the Marignal web app. The Slack Ruby toolkit will significantly speed up our development, avoiding the need for us to setup a lot of foundational Slack integration boilerplate. While using a shared underlying database maintains consistency in the content presented through either interface.

We need a system that lets us move fast while also taking advantage of the functionality already developed in the Marginal web app. To balance these competing objectives, we'll use the Slack Ruby toolkit to stand up a new backend service, connecting to a database shared with the Marginal web app.

Onboarding

Users can add Marginal to Slack from the Slack Marketplace or by clicking a link on the Marginal website. Doing so will trigger a Slack authorization form that users must "Allow" in order to use the application. Clicking cancel will direct the user to the Marginal homepage for now.

When users click "Allow," Marginal will receive a verification code and use that to request an access token from Slack, which is stored in the Marginal database. The user is presented an OAuth completion message and a set of onboarding instructions in Slack.

Creating Sessions

Sessions represent the series of discussions between you and your team. It's a foundational object that manages things like the recurring day and time for the team's weekly discussions, the people participating in upcoming discussions, and topics being discussed.

A new Session is automatically created when the Marginal bot is added to a Slack channel. To support this, we’ll use Slack’s member_joined_channel event to perform the following actions:

Create a new Session in the shared Marginal database.
Add Session participants by retrieving Slack members from the channel and creating session participant records for each user in the Marginal database.
Post a “welcome” message to the channel with a prompt to schedule the first discussion.

Tightly coupling a Session to a Slack channel helps keep your weekly conversations organized and in a central place.

Scheduling Sessions

Users can select a day of the week and a time from the new session prompt. Once selected, we'll record the Session details in the database and prompt users in Slack to select a topic for their first discussion.

Tightly coupling a Session to a Slack channel helps keep your weekly conversations organized and in a central place.

Picking Session Topics

Session topics represent the thing you and your team will discuss each week. When onboarding for the first time, users will have an option to select a topic from Marginal's existing library, or they can create a custom topic.

If users choose to create a custom topic, they will be presented with a modal asking for the following details:

Once completed, this information will be recorded in the database and your team will be ready for its first discussion. If a custom topic is selected, someone will need to create a new topic for the following week. This will be supported through a Slack command (e.g. /marginal add new discussion topic) that users can type to open the custom topic modal.

If users don't want to do this each week, they can select a topic from Marginal's library, which contains a curated selection of weekly topics.

Adding Discussion Topics

Now that we have a Session, with a series of recurring discussions and some interesting topics to talk about, users need to start preparing. More specifically, they'll need to review the topic for the next discussion and add things they'd like to talk about with their coworkers.

Users can add comments and questions to a discussion using a slash command—something like /marginal add discussion topic. As users add "talking points" to the next discussion, the Marginal bot will respond with an ephemeral message confirming that it was captured. If users wish to edit these talking points, they can do so using the web app.

Facilitating Discussions

The Marginal Slack bot will post a message in the channel announcing the start of a discussion. Additionally, Marginal will post a second message in the thread of the original announcement prompting someone to start a huddle or share a video link—since Slack doesn't provide an API for triggering huddles. As a reminder, everyone in the channel can add topics and join discussions.

Marginal will randomly select someone to kick off the discussion by sending an ephemeral message to the presenter with a list of their available topics. When a user selects a topic to present, the Marginal Bot will post a message to the discussion thread for everyone to see. While this is happening, non-presenting users will see a message letting them know the presenter is still choosing a topic. Once the presenter has finished discussing their topic, they can mark it complete, and the process should repeat for the next user in the discussion.

Out of Scope

Programmatically launching Huddles: Automatically starting a huddle in the channel when a new discussion is about to begin would provide a pretty seamless experience. However, Slack does not have a Huddles API to support that.
Automatic discussion topic prompts: If users create a custom discussion topic, they'll need to manually keep adding new ones each week. Automatically prompting users to add a new topic would be nice, but it's out of scope for this cycle.
Discussion Reminders: To start, we only plan on notifying users the exact moment a discussion is scheduled to start. However, in future iterations, it would be nice to include some reminders much earlier.
Public launch: Eventually, we'd like to launch the Marginal Slack app publicly. This would include things like making it available in the Slack marketplace (not just for us) and marketing the app on sites like Product Hunt. However, that's more than we can bite off in 6 weeks, so it will have to wait for another cycle.
Website updates: Somewhat related, we'll eventually want to update the Marginal website with new content detailing how the Slack version works. However, that is out of scope for this cycle.

Risks and Rabbit Holes

Given the limited amount of time we've budgeted to work on this, it's important to highlight some of the risks and potential rabbit holes that we discovered during the discovery phase. Doing so helps keep us focused on the core functionality outlined in this pitch.

By leveraging Slack's built-in distribution and seamless user experience, we aim to overcome some of the biggest challenges we faced with Marginal's web-based version.

Incorporating the Marginal web app data models into the Slack events service was a pretty tedious process and painful part of the discovery process. We had to fight between two different paradigms (Rails vs. the Slack Ruby Bot Server paradigm), and coordinating those two frameworks was challenging. Thankfully, most of this has been de-risked in discovery by using Rails' built-in configuration options to disable any functionality that we don't need. However, this is something to keep an eye on as we continue building out the Marginal Slack application.
Understanding Slack patterns and API interactions. The Slack documentation is great, but there is a pretty steep learning curve with tons of functionality. We'll need to make sure we don't get too caught up in the flood of information.
Based on some of the discovery we've done for this already, it looks like the Slack Ruby Bot Server framework we're using does not support handling modal submission events. Assuming we still want to use this framework, we may need to add support for this by contributing back to the open source project.
Accidentally breaking the Marginal web experience. Obviously we will try not to do that, but it's technically possible.

Appendix

Helpful Slack resources and documentation for this project can be found below:

Block Kit Builder (for testing/prototyping Block Kit UIs)
Block Action Reference Docs
Modals Documentation
Slash Commands Documentation
Web API Reference Docs
Events Reference Docs
Ephemeral (i.e. private to one user) Message Docs
Message Threads Docs
Slack Ruby Bot Server Internal API Request Handling Source. This is helpful when trying to figure out how a request/callback referenced in the Slack app docs translates into a component within the Slack Ruby Bot Server being invoked.
Slack Ruby Client Web API Supported Operations Source. This is helpful when trying to figure out how to call a specific Slack Web API endpoint through the Ruby client.

Closing Thoughts

Reimagining Marginal as a Slack application represents an exciting opportunity for our team to breathe new life into a product we believe in. By leveraging Slack's built-in distribution and seamless user experience, we aim to overcome some of the biggest challenges we faced with Marginal's web-based version. Throughout this pitch, we've outlined the core features, system design, and our approach to executing this project within a tight time frame.

As we move forward, we'll share updates on our progress, lessons learned, and any unexpected twists along the way. If you have any questions, feedback, or ideas to share, we’d love to hear from you. Feel free to reach out or drop a comment. Building in the open is core to our values, and we welcome your input as we take Marginal into its next chapter. Stay tuned!

Building an Audience

Truman Shuck — Thu, 05 Dec 2024 24:00:00 GMT

It's easy: you just start really, really small

Dan, Harrison, and I have been operating Go Between for a few years but only made our small business LinkedIn Official™ within the last six months or so. We delayed because we'd found success and steady work through our direct networks and didn't feel the need to do so — and because it took us about that long to get a logo and brand colors together. I'm grateful to say that we're continuing to find steady work, but we have found a few reasons to let folks in the wider world know that we exist.

You grow your audience by 900% in 70 days by starting a page on LinkedIn with four followers and consistently posting what you find interesting and useful every week.

So let's not draw out this click-bait title too long. You grow your audience by 900% in 70 days by starting a page on LinkedIn with four followers: yourself and two business partners, plus your brand designer Sean Brice. You write about what you find interesting and useful and you post it every week for about eight weeks. You find your company page at 36 followers and think "Sweet! Oh, but if we'd gotten to 40 folks I could have subtitled this post 'How to 10x your follower count in 2.3̅ months.'"

Just so you know, we do exist

Here are the 2⅓ reasons that motivated us to finally publish our career change: to see our name in OLED lights is a small vanity but a real component; to make our business development process clearer, and to make future product launches easier, are the two greater components.

Justin Jackson has developed an exceptionally thorough metaphor that relates business to surfing. It describes what it means to work fundamentals, to evaluate the water, and to "make it happen." It's a great article and you should read it. We took an even simpler concept back to our own conversations — are we even in the water yet? We'd dipped our toes in: sporadic client conversations, a brief google ads campaign for Marginal. But we weren't doing anything that would let us catch a wave in the future.

We enjoy working with our word-of-mouth clients, joining teams and working projects from ideation to delivery. We'd also like to find folks who are looking for high leverage expertise where we can deliver a ton of value in a small amount of time (and total cost!) We'd like you to know that we have a depth of experience providing advice and leading engineering teams through architectural discussions, systems design, and other big decisions. We know how to teach business and product folks how to communicate in ways that turn complex problems into actionable projects with clear outcomes. We still do make really good part-time teammates. We'd like you to know that we do have a contact form and that it's right here.

We'd dipped our toes in with sporadic client conversations and brief campaigns, but we weren't doing anything that would let us catch a wave in the future.

We'd also like to let you know, later on, when we have a product that we think you'd enjoy (maybe try out Marginal with your team in the meantime). You cannot know these things without us telling you. You will not know these things if you do not know or care at all about us in the first place.

The Art of Posting

I am not naturally inclined to "Just Post." My time on link aggregator sites is spent scrolling gifs of cats, and my time on forums is spent reading peoples' opinions about their favorite curated collections of gifs of cats. On the internet, in my leisure, I consume much more than I create. But I do think that it's helpful to have opinions and to considerately share them, and so I try to post anyway.

Nothing that we say about barely-executing code, or the right kind of laziness, or what happened at our Summit in Saugatuck is especially novel or groundbreaking. We write our recycled thoughts out anyway and try to be helpful to at least — or maybe just — one person: our words might be their first exposure to an old idea; our sentence formulation might tickle their brain in a way that others haven't.

Write about topics that you care about because they'll read better. Include parts of yourself in your prose because it will resonate more.

I'll end on a bit of actionable advice. Write about topics that you care about because they'll read better. Include parts of yourself in your prose because it will resonate more. You might use an AI or language model like a rubber duck, but shouldn't as a ghostwriter. A post per week for three months is better than ten posts in two weeks followed by silence because people will forget about you. Find a place where people might care about what you think and post regularly even though no one will pay attention at first. They'll start to, later. Writing is hard but it gets easier with practice. And so we post on, words against the current, born out ceaselessly into the aether of the internet.

Thanks for your time and attention.

Advice

Truman Shuck — Thu, 21 Nov 2024 24:00:00 GMT

Number one, how dare you

Opinions and advice are close cousins. Sharing an opinion is like saying "hey, here's what I think." Giving advice is like saying "hey, here's what you should think." I feel more comfortable with the former, because I'm reticent to take up too much space and maybe because I have my own streak of pigheaded independent obstinance. This is why I'm writing within the Opinion Zone™ rather than the Advice Quadrant (trademark this one at your leisure.)

Advice has to be desired in order to be valuable.

Advice has to be desired in order to be valuable. Maybe one day, when I'm a little more grizzled — and when young professionals are considerably relatively younger — I'll find that I can get away with the old "Hey kid, can I tell you something?" But I will probably just wait to be asked because my voice is not naturally gravely and I do not intend to pick up smoking just to deepen it. Advice is dangerous even when it's requested, and so I'll still have to lead with caveats, anyway.

Advice can not be given in a sentence

Others have spoken of the difficulty in giving advice: it's hard to remove bias; it's hard to pull the important bits out of a life full of context; it's impossible to avoid the phrase "it depends." This has an implication for someone trying to learn something: never take advice. Or maybe take a lot of advice but don't take any of it too seriously. Maybe just listen to the stuff that feels universal. Maybe just wear sunscreen.

The act of asking for advice implies an expertise gap between the giver and receiver. The bridge over that gap is not what the giver would do in the receiver's shoes today; it's what they'd do if they were ten years younger.

I think that another strategy, though annoying because it takes longer, is to treat advice like a whole conversation. My partner and I asked an experienced woodworking uncle for thoughts on building a privacy wall for a deck that we constructed laboriously over the course of a summer. He recalled some of the flourished trim work of our craftsman home and suggested designs with fancy internal joinery to match. We gave it a shot and our unskilled hands produced rickety fruits. Of course his advice hid his years of practice; our simple acceptance of his ideas hid our understanding of our capability.

The act of asking for advice implies an expertise gap between the giver and receiver. The bridge over that gap is not what the giver would do in the receiver's shoes today; it's what they'd do if they were ten years younger and had only a bit of a better idea about what to do next. It's the receiver's responsibility to know themselves enough to be able to say "well that sounds great, but here's where I'm actually at." We ended up with straight wooden slats in our wall, but we varied their spacing in a way that's informed by our home's ornamentation without overtaxing our fledgling skill.

Once bitten, scarred

Our actions are informed by the stories that we tell ourselves about our prior experiences. I am a good cook; I avoid conflict; I am kind; I am not ambitious. I carry narratives around in my head that help me, sometimes, to make choices about I should do next. This is advice that my past self gives to my present, but the experience gap from of my past can be as wide and unhelpful as any. Age brings wisdom and reticence. I will not put my hand on a hot stove twice, but should I shy away from a new venture because I've risked in the past and lost?

My internal narrative is so implicitly experienced that it's difficult to recognize what it really is: an external source whose advice comes from a context and set of abilities that may no longer match my own.

Maybe! But my circumstances are different now than they were then, and so maybe not. My internal narrative is so implicitly experienced that it's difficult to recognize what it really is: an external source whose advice comes from a context and set of abilities that may no longer match my own. It's important to interrogate advice from myself as thoroughly as from others.

Figuring out what to do next can be exhausting, which is why it's so tempting to delegate the task to someone who appears to have already made the correct decision. Or to follow our gut and do what we've done in the past. Neither of these yield the best outcome, which starts by asking for long-form help and following the request up with an even longer conversation. It's important to ask for advice. I that it's also important to be of service to other folks, and to share how I conceive of the experiences I've been given. I'll stay ready for someone in the far future to say, "Hey old guy, can you tell me something?"

Thanks for your time and attention.

Culture and Code: The Hidden Parallels

Harrison Strowd — Thu, 14 Nov 2024 24:00:00 GMT

In a recent post, we explored the nuances of company culture and its significance within an organization. Since then, we've realized that this concept has many uncanny similarities to system design, which, for software companies, is equally fundamental to their success. Whether you're working with people or code, there are striking parallels worth considering.

A well-designed system enables relatively junior engineers to work efficiently, while a strong culture brings out the best in people—both are silent multipliers of team effectiveness.

They always exist, whether you acknowledge them or not. Every organization has a culture, just like every system has an architecture. This is true regardless of whether they're crafted proactively or left to develop in an ad hoc manner. However, the difference between these two approaches couldn’t be more dramatic. Stepping into a well-organized, highly motivated team energizes and brings out the best in people, while joining a "train wreck" of a team can sap the joy and motivation from even the most upbeat individual. The same is true for engineers: a poorly designed system can trip up even the most proficient, while a simple, well-thought-out system enables relatively junior engineers to work efficiently and ship high-value, bug-free features.
They're an investment in the future success of the organization. Refining a system's design or a company's culture takes time and effort, with the benefits often emerging only in the long term. This is a classic example of delayed gratification. The value of investing in architecture or culture becomes evident as the system or organization grows. A well-designed system continues to operate smoothly as the user base expands, just as a company with a strong culture maintains its efficiency as new members join the team. In both cases, success often looks like the absence of problems, which can make the payoff easy to overlook.
They naturally degrade over time, requiring consistent maintenance. In a fast-moving company, it’s easy to neglect these areas, only to realize later that small cracks have grown into bigger problems. When your team is working well together or when technical issues rarely arise, complacency can set in. But as your business grows, the limitations of your current culture or architecture will start to show. Waiting to act until these issues become obvious means you’re already behind. Regular attention and incremental improvements are essential to prevent small breakdowns from turning into large-scale failures.

Success in both architecture and culture often looks like the absence of problems, which can make their value easy to overlook until small cracks grow into bigger issues.

They're the responsibility of the entire organization, not just leadership. Both system architecture and company culture are shaped more by the daily actions of individual team members than by leadership decisions alone. Announcing new corporate values doesn’t change a company’s culture unless those values are adopted and practiced by the team. Similarly, top-down technical design decisions can only go so far. Achieving overarching design goals requires each engineer to contribute thoughtfully and consistently. In this way, everyone plays a role in shaping the organization’s or system’s trajectory.
For teams that invest in them, they become highly valuable assets. Company culture and system design can either accelerate growth or become stumbling blocks that hold the business back. When properly managed, these intangible assets drive progress and innovation. When neglected, they create constant friction and delays. For instance, the time it takes to onboard a new employee or engineer—and their overall effectiveness—depends heavily on the quality of the culture or system they join. Highly motivated individuals can lose their drive in a complacent team, while even a mediocre employee can thrive in a committed and supportive environment. Similarly, a clean, well-architected system empowers engineers to deliver features efficiently and with fewer bugs, whereas a cluttered, tightly coupled system slows development and increases the likelihood of errors.

Company culture and system design can either accelerate growth or become stumbling blocks—when properly managed, these intangible assets drive progress; when neglected, they create constant friction.

As you can see, the parallels between company culture and system design are hard to ignore. Both are living entities within an organization, requiring thoughtful attention, continuous improvement, and contributions from all levels of the team. Manage them well, and they’ll serve as strong foundations for growth and success. Neglect them, and you'll find yourself constantly firefighting and playing catch-up.

Company Culture: All Hype or Actually Worthwhile

Harrison Strowd — Thu, 07 Nov 2024 24:00:00 GMT

Company culture is often overlooked, misunderstood, and rarely managed proactively. This article clears up the confusion and offers actionable tips to improve your team’s culture—whether you’re in management, leadership, or an individual contributor.

What is company culture?

Every company has a collective mindset and shared ways of interacting that form its culture. This exists at every level—within teams, throughout departments, and across the entire organization. Culture is constantly evolving as teams shift, attitudes evolve, and habits change. Sometimes this change occurs in an instant (e.g. when Elon Musk acquires a company) or in other cases it can change more gradually over a period of months or years (e.g. Apple's transition from tech underdog to tech giant).

Every company has a collective mindset and shared ways of interacting that form its culture. This exists at every level—within teams, throughout departments, and across the entire organization.

What determines a company's culture?

One of the biggest factors impacting a company's culture is its size. The culture of a small startup tends to be an extension its founding team members. As a team of three engineers who have worked together for over eight years, the culture of our company is a natural blend of our personalities.

The following are a few of the defining characteristics of our team's culture:

We are dedicated to our craft and focus on executing with quality, no matter what we are working on (e.g. code, design, documentation, etc).
We prioritize relationships first, both within our own team and throughout our interactions with clients.
We don't to take ourselves too seriously, maintaining a fun and relaxed environment within the team.

We didn't have to sit down for a brainstorming session to decide on these principles. They automatically took shape as we started working together. As the size of a team grows, it becomes more important to consider and identify the ideal attitudes and methods of interaction for the team.

Is it good or bad?

The truth is that there is no objective standard for good or bad culture. Rather, it's about fit. As an individual, do you look forward to your daily interactions with coworkers or do you dread them? For an organization, do the attitudes of your teams contribute to the overall success of the business, or detract from it? It will never be "perfect" which means there are always opportunities for improvement. Rather than trying to measure and analyze it, spend time refining it to be a better fit for the individuals on the team and the organization as a whole.

There is no objective standard for good or bad culture. Rather, it's about fit. As an individual, do you look forward to your daily interactions with coworkers or do you dread them?

What can you do to change/improve it?

There's no need to wait for the leadership team to decide on a mission statement and set of core values. While having buy in from the top can be helpful when making changes to an organization's culture, it is not necessary and does not have to be the starting point. The culture of a team is determined by the attitudes of and interactions between all individuals, not the words written on the walls or the mission statement on the company website. No matter where you sit within an organization, you have the ability to influence the culture within your specific team.

The culture of a team is determined by the attitudes of and interactions between all individuals, not the words written on the walls or the mission statement on the company website.

To start with a radical suggestion, talk to your teammates. Find or create space to have open and honest discussions about what is working well and what the team can do better. While this can take the form of a recurring retro meeting, we've found great value in more informal discussions centered around topics that interest any one team member.

We use Marginal, a tool we developed to help small teams to run structured discussions spanning any topic of interest to the team. Each week, a different team member shares a link to a podcast, video, or article they are interested in. After listening, watching, or reading, we prepare questions and meet as a team to discuss it. These meetings have not only built stronger personal relationships within our team but have ended up stimulating a number of great conversations around how we can work together more effectively and the direction we want to take our business in.

Like moving a large boulder, it takes significant effort at first, and you may see little movement. But over time, momentum builds, and progress becomes faster. Rather than exhausting yourself trying to "fix" your teams culture over night, identify a few concrete changes you want to make in the way people think about their work and/or interact with one another and invest in making these changes in ways that are maintainable over the long-haul. As you start to see these investments pay off, you'll be motivated to make further improvements and you'll have the organizational capital to do so.

But why?

If this sounds like a lot of effort spent on something that will take a long time to complete and is not guaranteed to succeed, it is. So it's a reasonable question to ask if it's even worth doing. Having worked at a wide range of organizations, some whose culture was a good fit for my personality and some whose culture was more at odds with my personality, I can confidently say that the benefits are widespread and significant.

In particular, the following are just a few of the areas that an individual or a team can benefit from improved culture:

Collaboration: Teams that get into a shared rhythm find it easier to collaborate and as a result do so more frequently. The creativity and enjoyment that comes out of this collaboration makes each individual and the team as a whole more productive.
Effectiveness: The sense of accountability that comes out of deeper bonds with your coworkers encourages each team members to push harder toward the objective set before the team.
Satisfaction: We spend too much time in the workplace to allow it to be a constant source of stress and frustration. When you work alongside people you appreciate and in ways that well suited to your personality, your work will energize you and bring great satisfaction to your life.

This is far from a complete list, but hopefully even these few factors demonstrate how valuable a culture that is tailored to meet the needs of the team can be.

Like moving a large boulder, it takes significant effort at first, and you may see little movement. But over time, momentum builds, and progress becomes faster.

In Summary

In conclusion, cultivating a positive and effective company culture takes time, effort, and collaboration, but the rewards are significant—from improved teamwork to greater job satisfaction. Whether you’re a leader or an individual contributor, you have the ability to influence your team's culture in meaningful ways. We'd love to hear your thoughts on this topic—what resonates with you, what you’ve found helpful in your own experience, or any challenges you're facing with your team's culture.

Feeding Our Hungry Followers

Harrison Strowd — Wed, 30 Oct 2024 24:00:00 GMT

We're excited to announce a new way for you to stay up to date with our latest content—through our brand-new RSS feed (link). While we've been focusing on LinkedIn to share our articles on software engineering and product development, we realized we were missing a key opportunity to engage with our most committed followers. Thanks to an insightful nudge from Mike Zornek, we've added an RSS feed to our site to make sure you never miss a post.

Admittedly, I hadn't given RSS much thought before. I'm someone who usually consumes news and professional content via podcasts. But once I explored RSS further, I was pleasantly surprised by how convenient and efficient it is to stay up to date with my favorite content. In particular, I'd recommend checking out Fiery Feeds or Inoreader if you're looking for a good feed reader to setup on your phone and/or computer. And be sure to subscribe to our feed here.

RSS is a powerful tool for anyone regularly publishing content and if our experience is any indication, getting a feed up and run can be quite easy to do.

What is RSS?

Before we dive into the details of how we set up our RSS feed, let's take a step back and look at what RSS actually is and why it's worth considering.

RSS, or Really Simple Syndication, is a standardized format for delivering content such as articles, podcasts, and videos. Built on XML, it allows users to subscribe to a feed, automatically pulling updates into an RSS reader without having to visit the website or subscribe to a newsletter. While it's been around for over 25 years, its popularity has risen and fallen a few times, showing signs of resurgence over the past few years.

RSS is a powerful tool for anyone regularly publishing content and if our experience is any indication, getting a feed up and run can be quite easy to do.

Setting up an RSS Feed

Our site is built using Eleventy, a JavaScript-based static site generator. The Eleventy community has developed a number of plugins that can be added to a site via NPM packages, enabling various types functionality and features. The Eleventy RSS plugin provides support for configuring and publishing an RSS feed for the content available on a site. Each time an update is deployed to the site a new version of the feed is generated and made available at the specified path (e.g. /feed.xml).

At the time, our site was running a rather old version of Eleventy, version 2.0.1 to be exact. To use the latest version of this plugin we would need to upgrade to version 3.0.0. So, we braced ourselves for the usual headaches that come with major version upgrades, but to our surprise, the process went off without a hitch. After following the step-by-step upgrade instructions and resolving a few deprecation warnings, the site was back up and running in under 45 minutes! It was one of those rare moments in development where everything just... worked.

While RSS has been around for over 25 years, it gives subscribers full control over when they choose to pull and read our posts—a privacy-respecting approach to content distribution.

With the upgrade completed we were able to use the latest version of the Eleventy RSS plugin and leverage all of its bells and whistles in configuring our RSS feed. Initially we tried using the out-of-the-box RSS feed template, which required just a few lines of code in our site configuration file to get set up. While this provided a reasonable starting point for our feed, it was lacking in a few key areas. Since we have three separate authors publishing content on our site, we wanted to assign the author for each individual item in the feed based on the author of the corresponding post. We also wanted more control of the number of posts included in the feed and their ordering. To accomplish this, we configured a custom template for the feed using the Nunjucks templating language to generate an RSS compatible XML file. This gave us the best of both worlds. We are still able to use the helpful utilities and feed generation process provided by the RSS plugin but now we have full control over the content generated within the RSS feed file.

Overall with a few hours of work, we were able to establish a valuable new channel for distributing the articles we publish each week.

There are Always Tradeoffs

As with most any technology, RSS is a tool that has both pros and cons. It's far from perfect, but can be very valuable when used in the right circumstances. As we considered leveraging it to publish posts on this site, the following are some of the tradeoffs that stood out to us.

Simple Setup: It's easy to get setup and requires almost no overhead to maintain.
Promotes Privacy: It provides nearly complete privacy for subscribers, allowing them to sign up without providing any information.
End-User Control: It gives subscribers full control over their subscription and when they choose to pull and read our posts.
Limited Tracking: It offers limited, if any, means of tracking our subscribers to understand who they are, why they subscribing, or when they unsubscribe.
No Subscriber Portability: It provides limited means of engaging with subscribers outside of the feed or migrating them over to other marketing channels.
Misuse of Content: It makes it relatively easy for someone to scrape or repurpose your content without proper attribution.

For us, the ability to easily share content while respecting subscriber privacy far outweighed the drawbacks, but it's essential to evaluate these tradeoffs on a case-by-case basis, in light of on your goals and audience. If you’re a developer or run your own blog, portfolio, or content-heavy site, adding an RSS feed can be a quick win. It’s a low-effort way to engage your audience and extend your content’s reach. We encourage you to consider it and give it a try!

For us, the ability to easily share content while respecting subscriber privacy far outweighed the drawbacks—it's a low-effort way to engage your audience and extend your content's reach.

Thanks so much for reading. If you have additional thoughts we'd love to hear from you. How do you stay on top of the latest news and content in your field? Have you used RSS before, or do you rely on other tools? Drop us a comment below or reach out at hello@gobetweenlab.com.

Marginal Improvements

Dan Lavin — Thu, 24 Oct 2024 24:00:00 GMT

Time to build something new. But what?

In last week’s post we talked about working in cycles, alternating between audience building and product work every six weeks. Now it's time to shift focus to our first product cycle.

Finding clarity in constraints

The first order of business when preparing for a product cycle is figuring out what to build—something we tend to struggle with, historically speaking.

Bringing a new product to life is hard enough on its own, but it's even harder when our time is limited by consulting hours, personal hobbies, and family time. Not to mention, we recently started working on a new client project and Truman is on paternity leave for the entire cycle.

Now, these constraints aren't necessarily new. In fact, they're actually quite common. However, that doesn't change the fact that these constraints cause us to put a lot of pressure on ourselves to come up with ideas that feel "worth" our precious time and attention. The result often leads to a lot of wasted time and decision paralysis when trying to come up with new product ideas.

But constraints aren’t all bad. In fact, they’re often an incredibly useful tool when it comes to matters of focus and prioritization. In this case, our constraints helped us reach consensus quickly and forced us to scale back our ambition—focusing on discovery and exploration rather than immediate execution.

Our constraints helped us reach consensus quickly and forced us to scale back our ambition—focusing on discovery and exploration rather than immediate execution.

What’s old is new again

If you've been following along, you might have heard us mention Marginal—a free tool we built to help teams build better relationships with their coworkers through weekly discussions.

We've learned a lot building Marginal over the past few years. The biggest realization? Despite a strong value proposition, onboarding new teams is too complicated. Getting them to adopt the product takes too much time and effort.

But when we lean into our current constraints, a different picture forms. Instead of building something new from scratch, why not leverage what we've already built? This thinking led us to a simple idea: build Marginal inside Slack.

Why Slack

First, it solves the friction problem by meeting teams where they already work. Right now, using Marginal means creating new accounts, learning a new interface, and remembering to visit another website. With Slack, a lot of these things are just a slash command away.

It solves the friction problem by meeting teams where they already work. Right now, using Marginal means creating new accounts, learning a new interface, and remembering to visit another website.

But beyond that, we're genuinely excited about the idea of building a Slack app. It’s a new platform for us to learn. It’s a chance for Marginal to evolve into something more compelling. Not to mention, Slack’s marketplace provides an established distribution channel that could make it easier for teams to discover and start using Marginal.

Six weeks isn’t that much time

It's unrealistic to think Harrison and I can build a fully featured Slack-based version of Marginal in 6 weeks. Remember that whole bit about constraints? But that doesn't mean we can't still do a bunch of valuable product work that continues moving us toward our ultimate goal of building a profitable SaaS product. Here's a rough outline of what we're hoping to accomplish over the next 6 weeks:

Technical Discovery: We'll be exploring Slack's API capabilities to understand what's possible. This knowledge will not only inform our product decisions but likely spark some interesting technical blog posts for our next audience-building cycle.
Shaping the Future: Taking inspiration from Basecamp's Shape Up framework, we'll craft a pitch document that outlines what we can reasonably accomplish in a future product cycle once we have our full team back together.
Proof of Concept: If time permits, we'll build just enough of a prototype to validate our technical assumptions and test our ideas in our own Slack workspace. This could be something as simple as the ability to add discussion topics from Slack.

Intentionally small

We're intentionally keeping our goals modest for this cycle. Success doesn't mean launching a product—it means gaining clarity on what we could build and how we might build it. We're treating this as a foundation-laying cycle that will inform future work when we have our full team's attention.

Success doesn't mean launching a product—it means gaining clarity on what we could build and how we might build it. We're treating this as a foundation-laying cycle that will inform future work.

And yes, we'll be sharing what we learn along the way. While our focus is shifting away from content creation for the next six weeks, we've built up enough of a backlog to keep our weekly publishing cadence going. Expect to hear more about our technical discoveries, our product shaping process, and the challenges of building with constraints.

In the spirit of working in the open, we're excited to bring you along on this journey. Have thoughts about bringing Marginal to Slack? We'd love to hear them in the comments below.

Working in Cycles

Truman Shuck — Thu, 17 Oct 2024 24:00:00 GMT

The FitnessGram Pacer test is a multistage aerobic capacity test that progressively gets more difficult as it continues.

If someone told you that they're exhausted from running 421.94988 one hundred meter sprints, back to back, you might say that that's oddly specific and that it sounds like a marathon. You would be correct both literally and figuratively. This is not the first (or best) joke at the expense of Scrum's iteration structure, and it might be said that it willfully misrepresents how Scrum interprets the spirit of agile development. But most teams still take its "periods of work that last one month or less" to mean "one week sprints, forever" and most companies still have to run marathons and yet pause every block or so to wonder if they're heading the right way.

Most teams still take "periods of work that last one month or less" to mean "one week sprints, forever" and pause every block to wonder if they're heading the right way.

The complexity of a system only increases as it grows. This is true of communications, decision making, reporting structures, products, and technical architecture. Strategies that work well in small systems do poorly in larger ones and so must grow in complexity, too — a quick conversation between three founders becomes an hour long stakeholder discussion with laboriously prepared slides. This is also why adopting complex strategies from much larger systems tends to fail: they're not recognized as the best-alternative burden that they are and end up costing more than a small team can afford; I'm looking at you, microservices, five-stage interviews, and every other FAANG trend adopted by ~40 person orgs.

Have you ever initialized the first concept of a user in a new repository? Created the UX for a two-step sign-up process on a new product? Written the marketing campaign for a new tool that focuses on doing one thing really well? Have you ever worked to extend a system that has four connected products, two reporting tools, email and sms communications features, onboarding funnel drop-off retargeting, and three layers of stakeholders to work with? Delivering substantive value also becomes more difficult as a system grows.

Not every project requires six weeks to work from one end to the other, but more and more will as an organization grows.

Composition & Decomposition

The work to create the first integration into an email provider, and the work to add push notifications to a system that has multichannel communication preferences, compliance and privacy concerns, and a couple of observability dashboards to update, are both fun and interesting challenges. Both of these projects should be decomposed into small, knowable, workable tasks for execution. They should be time-bound to prevent over-investment. Whoever is tasked with the work should be trusted to make decisions and have the space to apply their creative expertise. They both benefit from discovery and focus.

They should not be composed in the same way. The former might fit entirely into one person's head and could be done within a one week sprint. The latter won't, and it probably doesn't really start to deliver value until it's mostly finished. This is not to say that the latter feature should be held separate, unmerged and increasing in technical risk, until it's finished. But it is to say that it's unhelpful to artificially pause every week or two in order to give folks the opportunity to change their mind on the value of a feature that's already been considered valuable enough for investment in discovery, planning, and the start of execution.

A fledgling organization maybe — maybe — needs the ability to change its mind every two weeks maybe. An established product requires the following:

that context stick around in someone's head long enough to be set down among the varied complex concerns of a larger system
that ongoing work won't leave a mess because it's been paused mid-flight
that systemic changes to address related, mounting technical debt have time to be considered

Not every project requires six weeks to work from one end to the other, but more and more will as an organization grows.

The Castles in our Heads

On a team of five, in a young product, when most technical decisions are pretty easy, folks maintain enough day-to-day working context that their mental models might remain unperturbed by the organic growth of their company. Work can flow freely from one sprint to another, or even continuously in a kanban stream. But just as the delivery of value in a complex system is itself more complicated, a rigorous discovery and planning process becomes the necessity of a larger system. It's no mean feat to shape a project that will end up taking one or three folks' full attention for six weeks.

Just as the delivery of value in a complex system is itself more complicated, a rigorous discovery and planning process becomes the necessity of a larger system.

Dan, Harrison, and I have recently decided that we should start working in six week cycles for the time we spend directly on Go Between. You would be correct to say that this decision flies directly in the face of my earlier point about the trouble of adopting big tools for small jobs. For us, though, the cost of shaping work for ourselves is always worth it: as a focus for our part-time product hours; in the generation of planning artifacts that we can share with you fine folks; for the sense of accomplishment in setting and achieving a specific goal.

Late '24 is a busy time for Go Between: holidays, a new consulting client, and impending paternity leave will divide our focus a bit more than usual. We're nearing the end of our current audience building cycle and we'd like to get back to building, but we don't have a clear pitch for what, exactly, that should look like. Rather than risk flailing about through the end of the year without a clear goal, we're planning to spend the next six-ish weeks shaping work for our future selves to execute. More on that later — in the meantime, wish us luck. We've got a bucket to fill.

Thanks for your time and attention.

Marginal

Truman Shuck — Thu, 10 Oct 2024 24:00:00 GMT

Because we wanted it to exist

Having recently failed to fundamentally transform human connection via Musicbox, our newly-formed product/consulting company Go Between was looking for a product to build. This specific framing, to build, was natural for three software product engineers and would provide plenty of opportunities for learning over the course of the following two years. It would definitively not result in a product whose recurring monthly revenue would allow us to shift more of our time away from consulting — which remains our ultimate goal.

Regardless we needed something to make, so we turned to the internet where folks have lots of thoughts on how to vet prospective product ideas. Some advise you to work backward from a market; others to focus on pain and problems; many offer long questionnaires. It's a lot, and anyway Derek Sivers has some thoughts on advice:

Imagine you've got a big question like, “Should I quit my job and start my own company?” You go ask the advice of some successful people you respect. Because they can't know everything about you and your unique situation, they'll give advice that's really just a reflection of their own current situation.

"Beware of Advice" from the book "Hell Yeah or No"

As a remote company with product goals that require skills outside of our experience — marketing, positioning, sales — we figured that we had some learning to do. And as a remote company which values human connection, we figured that we should continue with practices that brought us together as people. It was Dan's idea to start a recurring book club and to maybe build a product around it. We wanted to select books that would teach us about entrepreneurship, and to style discussions in a way that would connect our personal and professional lives.

The feeling of connection was the most obvious product of this series of discussions. Getting to know the folks that I was working with felt good; it helped us understand our respective personalities in a way that made working together easier and more productive.

First: on scratch paper

Our initial experiment involved running a book club for Derek Sivers' "Your Music and People" in a Google doc. We also picked an initial product name, remotebook.club, because we are apparently literalists at heart. We split the book into a handful of sections and agreed to meet weekly — noting topics asynchronously in the document to be discussed in our hour-long conversations. Throughout the discussions, at the end of the document, we kept a list of feature ideas and other product related thoughts.

The feeling of connection was the most obvious product of this series of discussions. In responding to Derek Sivers' work, we shared a range of opinions on the subject matter — but also anecdotes from our lives that would not otherwise have come up. Getting to know the folks that I was working with felt good; it helped us understand our respective personalities in a way that made working together easier and more productive. The material sparked product ideas and thoughts about how our company should work. The discussions were fun and invigorating and we thought we could build a great product if we could figure out a way to share this feeling with other people.

We read several other books together in our early discovery phase: Rob Fitzpatrick's "The Mom Test" and Paul Jarvis' "Company Of One" to test the learning angle, but also "When Things Fall Apart" by Pema Chödrön and "Satisfied" by Jeff Manion because we thought that they might spark interesting conversations. Both angles worked and we cobbled together a basic feature set and user experience:

We'd hand-select and divide a number of books into series' of discussions
Our tool would let folks set up a team, pick a book, and start a discussion series†
We'd encourage folks to read each section and prepare discussion topics ahead of time in the tool
Once per week, folks would meet to discuss each participant's topics in turn

† Not quite right away, since people would still have to acquire the book; we'd revisit this thought later

There were a handful of other features that we'd discover and drop as we iterated toward something we could share with other folks. We also picked a better name, Marginal, and got started building.

Next: on Rails

Go Between's collective experience covers a lot of different technologies, but it's Ruby on Rails that we always come back to. Our last product, Musicbox.fm, was a Rails API with a React frontend. With Marginal we wanted to keep things even simpler with Rails' server-side rendering. So we, as a fresh young developer following the first steps of a "build a blog in 5 minutes" Rails guide might, started with rails new marginal --database=postgresql.

Our first handful of pull requests establish familiar tools: tailwindcss, rspec, sidekiq, rubocop. And although our engineering principals include the value of discovery and planning artifacts, our feature work on Marginal was instead a loose, organic process that drew from a well-shared understanding of what we were trying to do with the product.

A product, for us, usually takes shape from the perspective of the person using it. We established a user model and fleshed out the sign-up/sign-in process. We established a relationship to a team and, since Marginal is really only useful with other folks, figured out how to invite other people through email (actionmailer, Postmark). It took about two months of part-time effort to get our first version of the end-to-end experience deployed to Render where we could start using it for our own continued book clubs.

And After: Iterating

September 22nd, 2020 saw the first commit to Marginal's codebase, and over the course of 281 pull requests we've had 654 more commits since. Some of these are in support of purely technical changes. Software engineering is fun — mostly — and in our internal projects we specifically enjoy prudently experimenting with new technologies. As with most of the internet over the last ten years, our frontend experience had primarily involved single page applications. With Marginal, we turned to Rails' views and their associated tools: ViewComponent, and with the release of Rails 7, import maps and Hotwire. So some of our work involved adopting these technologies, using them poorly, figuring them out, and then using them a little less poorly.

The bulk of the changes to Marginal came from sharpening our understanding of what we wanted the product to be over the course of using it — first by ourselves, and later with a handful of the teams that we consulted with. Two of the books that we read helped speed this process along immensely, although one would lead to partial demise of the product itself. The first was April Dunford's "Obviously Awesome," a guide to product positioning, through which we clarified Marginal's place between learning tool (to retain content) and connection tool (to get to know the folks you work with). We landed on the latter, which saw us remove features related to capturing notes and reflecting on the subject matter, and to build features to facilitate the live discussion itself.

Software engineering is fun — mostly — and in our internal projects we specifically enjoy prudently experimenting with new technologies.

It would be Donald Miller's "Marketing Made Simple" that would eventually cause us to step back and fundamentally re-evaluate Marginal itself. We read this particular book over the summer of 2022 ahead of one of our in-person company summits where we then worked through its exercises in order to create a marketing plan. We'd had some success with running book clubs with the teams that we were embedded in through our consulting work and were trying to figure out how to communicate Marginal's value to the internet at large. It was the end of the StoryBrand BrandScript exercise that clarified a problem that we'd been passively noticing for a while.

The BrandScript is a couple of paragraphs of fill-in-the-blank text that help describe the person who really needs the product, why, and how it addresses their problem. At the end is a simple bulleted list: here's how it works, 1, 2, 3.

Here's how Marginal works: someone corrals their team into reading together; over the course of a couple of weeks each person has to be reminded to get the book and read the first section; busy calendars eventually align and a few weeks later everyone has an energizing first discussion. It's a great feeling that takes about a month of time and a lot of dedicated reminding by a very motivated spokesperson to achieve. It felt very hard to market.

It's a great feeling that takes about a month of time and a lot of dedicated reminding by a very motivated spokesperson to achieve. It felt very hard to market.

Marginal Is Dead, Long Live Marginal

We work on Marginal in the time leftover from our consulting work as Go Between. I can only be grateful for the flexibility and relatively low stress that this decision has lead to in my life — but every decision has trade-offs and this one is that it's hard to build, copywrite for, market, and launch a product, especially one that requires a lot of explaining, on a small budget for time.

We ultimately decided not to drop Marginal entirely, but instead to change its focus. Instead of a tool to facilitate discussions about sections of a book that each team member has to acquire, we assembled topic-based collections of articles, podcasts, and video essays that are available on the internet. This allows a team to find something worth discussing, consume the material, and to experience the value of that shared discussion, all within a week or so. We set about updating our marketing copy, and addressing some feature work that would make these sessions based around short-form media more user-friendly.

We also decided to release the product for free, as-is, and removed the bulk of the Stripe subscription and payment processing integration that we'd added early on. Even with Marginal's new focus, it's still a tool that requires a fair amount of effort from the folks who use it. We think that that effort is worthwhile — we still regularly host sessions through Marginal for ourselves — but we'd like to invest our small amount of product-building time in something that is more immediately, explainably, valuable to folks.

Marginal is about four years old, and we're probably not going to generate meaningful revenue from it. That's okay.

Afterward

Marginal is about four years old, and we're probably not going to generate meaningful revenue from it. That's okay. One of my favorite Marginal book-club books, "Range" by David Epstein, would say that the process of building and sort-of-launching this product is another in a line of inherently valuable experiences from which we'll draw future inspiration in some way that I cannot predict today.

It's been five months since our last commit to its Rails repository, and we've found that it's partly true what they say: good ideas never die. But they won't just fade away, either.

Go Between itself is refocusing, again, on what we want to do with our time. During our company summit in Saugatuck, we realized that we would be better off working in six weeks cycles in order to better focus our audience and product building efforts. With a product cycle on the horizon, we've been contemplating Marginal once again. It's been five months since our last commit to its Rails repository, and we've found that it's party true what they say: good ideas never die. But they won't just fade away, either.

Thanks for your time and attention.

Lessons in Consulting - Part 3

Harrison Strowd — Thu, 03 Oct 2024 24:00:00 GMT

If you can manage to get things up and running, as outlined in Part 1, and can avoid or work around the challenges acknowledged in Part 2, there are a number of great upsides that await you:

Choose Your Own Career Path

In most full-time employment roles your growth opportunities are limited by the needs of your role and of the organization. As a senior software engineer, your company is more likely to support you in developing further technical skills than in learning entry level marketing skills. Similarly, if your organization exclusively uses Ruby and has no plans to change this, you may get pushback if you ask the company to send you to a conference for an unrelated language. While some companies are more willing to support employees in building a diverse set of professional experiences, at some point the needs of the business have the potential to conflict with your personal interests and you will reach an impasse.

Growth opportunities for consultants are not bound by the needs of their current clients. This flexibility allows you to stay on the leading edge, learning new skills and positioning yourself to consistently offer high-value services.

Growth opportunities for consultants are not bound by the needs of their current clients. In fact a consulting business often benefits from individuals cultivating a more diverse range of skills. This broadens the set services that can be offered, providing a wider net for attracting new clients. Additionally, as technologies move through their natural lifecycle, this flexibility allows you to stay on the leading edge of this curve, learning new skills and positioning yourself to consistently offer high-value services to a wider range of clients. Those limited to a single technology may find themselves stuck maintaining outdated systems that are becoming obsolete.

Consultants can bring value to client organizations in a wide range of manners. Some choose to keep their skills focused very narrowly, building deep expertise on a very limited set of topics. Others offer a much wider range of services, bridging gaps and improving the operational efficiency of a client by bringing a broad set of experiences and skills to the table. Neither of these approaches is objectively better or worse than the other, but rather are a good fit or bad fit for a particular team. The important thing is to choose a strategy that works well for your interests and objectives.

The Joy of Swinging a Hammer

For those of us who are lucky enough to find a job that fits perfectly with our interests and passions, there are few things worse than being promoted into a managerial position that involves a lot of paper pushing and leaves no time to tackle the tasks that bring deep joy and satisfaction. For me, building software systems, and particularly the technical design and coding activities involved in this, are what I love to do. In reality, work ends up feeling a lot like a game that consists of a series of puzzles or challenges, where the medium for this game just happens to be a programming language or system design components.

Consulting creates a virtuous cycle where your joy and expertise grow as you work through increasingly challenging problems, creating a win-win situation for both you and your clients.

Consulting not only offers an alternative career path, avoiding the "management trap" by continuing to build and use expertise in your field of choice, but it also incentives clients to task you with their most challenging activities. This forms a virtuous cycle where your joy and expertise grow as you work through the increasingly challenging problems brought your way, creating a win-win situation for both you and your clients.

Building Deep Relationships

There are few better ways to build a high trust relationship than repeatedly delivering high quality, on-time results. As a consultant these high trust relationships form the life blood of your business, but even more than that they enhance your sense of satisfaction from the work you do. After deploying a complex new feature, you not only get the professional satisfaction of having solved the set of challenges that initially stood in the way of this project but you also get the relational satisfaction of having meaningfully supported the goals/needs of your counterpart within the client organization.

While client relationships can grow very strong and last the course of your entire career, they will never be quite the same as the bonds formed with the people you have chosen to build your business with. This was one of the main reasons I sought out partners to form a small consulting company after running a freelance consulting business for five years. Through the ups and downs of landing new clients, building the business's reputation, establishing an audience, perhaps launching and pivoting side products, and the countless other activities involved in running a successful consulting business, you get to know your partners at a level that simply doesn't compare to any other coworker relationship. You learn about the ins and outs of their lives, you take opportunities to support them and be supported by them, you celebrate their victories, and you offer a shoulder during challenging seasons. These experiences form the basis for not only a committed business partnership but a lifelong friendship.

Part Time and Overtime Work Opportunities

As a consultant you are directly in control of your workload and, with sufficient advance planning and communication, can generally dial this capacity up or down to align with your current needs and desires. If you want to pursue a passion project, take a set of courses to learn a new skill, or simply have more time to relax an enjoy the company of your friends and family, you have the ability to adjust your commitments to free up time in your schedule for these activities. On the other hand, if you are about to take a large block of time off (e.g. for a sabbatical or as your welcome a new child into your family), you may feel the need to build up reserves to support yourself during this upcoming period of decreased income.

The ability to fine tune your workload in this manner is something that few other professional, full-time roles afford. When leveraged in a wise manner, this provides opportunities that you would never be able to consider in a full-time employee role (e.g. going back to school part-time, extended traveling, caring for a parent or loved one, etc). In all of these scenarios, it is particularly important to stay in close communication with your clients, giving them enough lead time to adjust plans without impacting the commitments they have related to your work.

Less Corporate BS

Are annual performance reviews, corporate handbook trainings, and tedious office politics the most exciting aspects of your job? If so, I'm sure you'll enjoy twiddling your thumbs in that cozy cubicle for many years to come. However if you wouldn't mind never having to bother with these tasks again, a consulting role is a great way to sidestep these time consuming and often soul-sucking activities.

As a consultant, you will almost exclusively be evaluated based on the impact of your work and the resulting value delivered to your client, not based on the whims of the person positioned above you in the org chart.

As a consultant, you will almost exclusively be evaluated based on the impact of your work and the resulting value delivered to your client, not based on the whims of the person currently positioned above you in the org chart. Additionally, in this role you're free to share your thoughts and advice in a direct, unapologetic manner without being overly invested in the resulting decision made by your client. If they choose to ignore your advice, that is fully within their rights to do. As discussed in Part 2 of this series, this will require you to respect their decision while still finding productive ways to support the team throughout its execution. However, in most cases this is much easier than the political tightrope of either gaining relational capital by allowing another employee to "be right" versus ensuring the best possible decision is made to set the business up for continued success.

It is worth acknowledging that running a business comes with its own forms of overhead, such as financial bookkeeping, annual business filings, tax returns, legal contract reviews, etc. However as the business owner you can choose which of these tasks you appreciate handling yourself and which you'd prefer to outsource to qualified professionals with the experience needed to keep your business running smoothly.

While this is not an exhaustive list, these are a few aspects of running a freelance or small team consulting business that we've found most rewarding. What benefits of consulting do you find most appealing? Are there other perks we've missed? Let us know at hello@gobetweenlab.com. Thanks so much for reading this series. If you missed the first two posts on tips for launching your consulting business and challenges you will face operating it, be sure to check them out.

Summer '24 Recap

Truman Shuck — Thu, 26 Sep 2024 24:00:00 GMT

The Short-ish of It

We've been trying to figure out how to use our part-time availability effectively, and what "effectively" even means.
Dan read Slow Productivity and encouraged Harrison and I to read it too. We discussed it on hiking book club during our most recent Summit which capped off our summer.
Slow Productivity, among a lot of other useful framing devices, describes “missions:” major foci of your life, not bounded by time, where you place attention and energy, in some shared broad context.
- Within Go Between: consulting for others; our product development; audience building.
- Within ourselves: our families; potentially some set of our hobbies, but none of us are currently investing much time in our banjo playing, or marathon training, or fiddle leaf fig propagation.
Missions have context-switching and overhead/maintenance costs, so having fewer missions is better. Ideally one; realistically two or three.
We think we can do two missions within Go Between. One mission is consulting because we like working with fun and interesting clients, and because we have three houses, two dogs, one cat, and 5.89 children to take care of while we work on our product business.
We really like working directly together, so rather than divide Go Between's other missions among ourselves to work in parallel, we're picking one to focus on collectively.
In order to still make progress in all of the missions that we're interested in pursuing, we're going to set aside a certain amount of time to focus on each in turn.
These time blocks are going to be about six weeks each, but we'll allow this to vary a little bit.
We call them “Cycles” which is not our original term.
We're starting (continuing, really) with audience building.
Everything old is new again and you should really read Range if you haven't.

The Longer of It

When I have an epiphany I feel like 90% of the time the realization is something I already know and, often, have even used in some other context in my life. I think this might be something of a loose requirement for epiphanies because occasionally they do come out of nowhere. But having some connection to life-changing information is a strict requirement, so often an epiphany is the slow culmination of several years of conversations, and books I've read, and things I've tried before. I think this is why having a diverse set of experiences is so important. You really should read David Epstein's Range.

Personal philosophy corner aside, Dan, Harrison, and I recently had an epiphany about our work at Go Between: we're collectively a little too busy and a little too unfocused. While we do enjoy the time that we spend in consulting with external clients, owning our own time outright is still our ultimate goal. We'd been working toward this in various fits and starts: our first attempt at a product, Marginal; experimenting with a product announcement marketing page; creating a tiny slack app; building an audience. It's been slow going.

Slow going is still going

To say that it's been slow going is unequivocally true; to say that it feels like we're not going anywhere at all is something we've actually said in our virtual coffee chats. But we are going, it's just hard to see sometimes.

Dan started reading Cal Newport's Slow Productivity a few months ago and rediscovered a profound metaphor: progress is like the many small drops that fill a large bucket. It's hard to feel progress each day, or each week, because progress is not being made on those timescales. Feeling progress can take months, or years, or decades. But, also, progress is happening each day as long that bucket is getting filled a bit at a time.

Progress is like the many small drops that fill a large bucket. It's hard to feel progress each day, or each week, because progress is not being made on those timescales.

Maybe my epiphanies are really made of broad common wisdom that, eventually, I figure out how to incorporate (or reincorporate) into a specific moment of my life. Regardless, Cal Newport had sparked one for Go Between — and he had a few more thoughts for us.

How to fill a bucket

We recently had a company Summit in Saugatuck, MI, and made it a point to discuss Slow Productivity while hiking around Tallmadge Woods and Saugatuck Dunes State Park. While trudging up and down sand dunes we chatted about how to fill our progress bucket and, relatedly, Cal Newport's concept of “missions.”

My interpretation of a mission is that it's an intentional area of focus where I put attention and energy in an ongoing manner. A mission has a specific context that binds its projects and tasks together into a unified effort and brain-space. The intentional time we spend with family is a mission for Dan, Harrison, and me. Go Between is too diffuse to be a mission, but our focuses — consulting, product development, audience building — are each missions themselves.

A mission has a certain amount of maintenance that goes with it, and a certain context-switching cost. Imagine that you're filling your cupped hands with water flowing from a hose, and you are distributing each careful cup among one or three or five buckets. Each bucket has a different lid to navigate. A bit of water sloshes out across the uneven ground as you walk from one to another. Fewer buckets means less waste. Ideally you have one mission in life, but realistically you might be able to get it down to two or three. This is much better than trying for five.

Ideally you have one mission in life, but realistically you might be able to get it down to two or three. This is much better than trying for five.

Choosing missions

Cal Newport doesn't really discuss missions in the context of personal life, but we collectively believe that it's important to be intentional about the time we spend with our families. So within this framework we treat taking our kids to the zoo, and going on dates with our partners, and petting our animals on their small heads as a mission which is as important as any other. From within Go Between, we find that our consulting work remains an enjoyable and necessary mission. We are each left with one available slot.

Dan, Harrison, and I very much enjoy working directly with one another. This is, not incidentally, why we started a company together. We have worked collaboratively on a shared goal before — implicitly — when Marginal was our only project. We've gone solo, too, on blog post writing, on product marketing, on slack plugin creation.

In our mobile book-club discussion, while walking in the sand along the vast beach of Lake Michigan, we found that we are not interested in delegating missions and working in isolation. We've been writing and posting on a weekly cadence for a little while now and we figured that continuing this effort, to build an audience, was a good place to start our explicit and collective focus.

What about everything else

We think about building an audience like this: "wouldn't it be easier to launch a product if folks on the internet actually knew that Go Between existed?" Yeah, probably. And while having an audience supports a number of efforts — in addition to serving as an excuse to spill our thoughts out on to the internet — if one of our goals is to generate product revenue, then we'll eventually also have to build a few products to launch. How do you do three or five or seven things? One at a time.

The other thing about epiphanies is that they're rarely novel. Jon Yongfook wrote about flipping between building and marketing activities on a weekly basis, which works wonderfully if building and marketing are the sole weekly missions. We're splitting our work at about 75% consulting and 10-25% alternate mission time (0-15% gratefully spent in early Fridays, appointments, interruptions, errands), so context-switching on a weekly basis for this second mission would fill no buckets. In previous employment we felt a similar pinch: to do substantive work by decomposing tasks into weekly or bi-weekly sprints where focus might change at any time felt impossible. Dan discovered Basecamp's “Shape Up,” and for a while our product and engineering team worked in four or six week cycles.

This was an exceptionally nice way to do professional work and, though we lost the practice for a while, we have decided that it's time to start it again.

The Grasshopper and the Ants

The most common advice about building an audience is to maintain a consistent content publishing schedule. A post each week will start to gain traction eventually. A post each week for while and then a six or twelve week absence will probably flounder. Cycling into audience building activities means that Go Between will eventually cycle out and into another activity.

It's a little late in a long post for a new metaphor, and so I'll just say that it's the goal of our first cycle to both maintain our publishing schedule and also build up a large enough backlog such that we can continue posting weekly while we turn the majority of our attention to product development or another of our missions in the next cycle.

Do fewer things; work at a natural pace; obsess over quality.

So here is our epiphany, collected. As Cal Newport says: do fewer things; work at a natural pace; obsess over quality. Do you have an epiphany you'd like to share? We'd love to hear it in the comments below.

Thanks for your time and attention.

Note: While reading this post you might think, "Metaphorically, shouldn't the icons be Ants instead of Grasshoppers?" You would be correct except that we find the grasshoppers to be a cuter article adornment.

Lessons in Consulting - Part 2

Harrison Strowd — Thu, 19 Sep 2024 24:00:00 GMT

If Part 1 of this series only served to strengthen your desire to launch a freelance or small team consulting business, you should be aware of some of the obstacles you will face throughout this journey. While this path can offer a great deal of flexibility and independence, it is not without its own set of drawbacks. We strongly recommend thoughtfully considering these factors and honestly evaluating whether your personality and temperament are a good fit for this style of work.

The Boundaries of Your Role

One of the key benefits an outside consultant brings to each engagement is a fresh perspective on how to solve the problems currently facing the organization. In order to maximize the value you deliver for your clients, it's important to share your insights and thought process in a constructive and collaborative manner. At some point, you will encounter a client that disagrees with you and does not take your advice. This is a natural result of working to solve complex problems; there are multiple approaches and people don't always agree on the best approach.

As a consultant it is important to recognize and accept that selecting the direction to proceed in is no longer your role or responsibility.

In these cases it is crucial to voice your thoughts in a clear, honest manner and once you have done so, to set your opinion aside and embrace whatever approach your client has selected. When you have operated as the decision maker in similar situations in the past, it can often be difficult to fully support an approach that you disagree with. As a consultant it is important to recognize and accept that selecting the direction to proceed in is no longer your role or responsibility.

If you are unable to proceed in good conscience with the approach selected by your client, you should acknowledge this with them and seek to find an alternative way to leverage your skills for their benefit (e.g. finding another project to support, rolling off the engagement, etc). It is better to end an engagement earlier than intended with a client that values and respects your skills and contributions than to tarnish your relationship with the client by fighting a decision that they have made up their mind on or supporting its implementation in a lackluster manner.

Maintaining Work/Life Balance

Nearly all consulting engagements have a negotiated hourly rate or an expected hourly rate that can be calculated from the project fee and an estimate of the time required to complete the project. This provides a direct conversion rate between time and money, which it turns out can be a very dangerous thing. When you go to the movies you can multiply your hourly rate by the 2.5 hours you'll spend watching that movie and end up questioning whether this relaxing activity is really a worthwhile use of your time. Or after heading out early on a Friday to go hiking with friends, you can reflect later on in the weekend about how much that activity cost financially.

No matter what the activity is, you can now assign a concrete opportunity cost to it. This has the potential to significantly incentivize overwork and to sap the joy out of activities that would otherwise allow you to recharge and refresh. At the end of the day, the impact of this on each individual varies widely depending on their personality, but it's important to watch out for.

If you notice yourself constantly calculating the financial cost of your time, consider setting clear boundaries for your work day or blocking off time for activities that optimize joy rather than income.

If you notice yourself constantly calculating the financial cost of your time, consider setting clear boundaries for your work day or blocking off time on your calendar for hobbies or leisure activities. This will force you to stop measuring this time financially and instead optimize these blocks of time according to the joy and satisfaction they provide.

Extended Time Off

If you've always worked as a full-time employee at companies that had an "unlimited paid time off" policy, you may not fully appreciate how amazing the idea of "paid time off" actually is. Whether you're on vacation, caring for a newborn, or recovering from a medical procedure, you're still paid as if you're working full days. This is nothing short of magical.

As a consultant your first vacation or extended leave will quickly disabuse you of this misconception. If you're not working, you're not getting paid. This makes it particularly important to plan for these periods of decreased revenue. For example a two week vacation can result in your monthly income being cut in half. If you're planning to take a significant amount of time off (e.g. parental leave, medical leave, etc), it becomes even more important to prepare well in advance of this period of inactivity.

Taking time off to care for yourself and those around you is extremely important. The quality of your both work life and your personal life will suffer if you neglect these activities on an ongoing basis. With a bit of planning and preparation, we can attest that it is feasible to manage the financial and project scheduling impacts of anywhere from 2-8 weeks of uninterrupted time off.

Circumstances Outside Your Control

While there are a number of steps you can take to set yourself up for success as a consultant, these activities only cover about half of the factors that will make or break your business. As a full time employee, an economic downturn or a series of mistakes made by the leadership team can result in unexpected layoffs. However if you meet or exceed the expectations for your role, your sense of job security should be fairly high. As a consultant, engagements typically expire every three to six months unless explicitly renewed. This highlights the key role these external decision-makers play in the stability and longevity of your business.

In an ideal case, you'll get 4-6 weeks of advance notice when a project is about to ramp down. While this may sound like more than enough time to find your next project, it goes quickly. If you're not careful, you can feel rushed into taking on a project that is not be an ideal fit for your skills, desires, or availability. In extenuating circumstances the notice you receive about the end of a project can be much shorter. At the start of the COVID pandemic for example, one of our clients saw a significant downturn in their revenue stream and had to back out of our engagement abruptly. In these cases, the importance of having a growing network of potential clients and a few active business development conversations becomes immediately apparent.

Actively Seeking a New Project

At the same time, seeking out and landing a new project to backfill a gap in your availability is far easier said than done. Even if you have a strong network of potential clients, time spent performing outreach activities, vetting the interest you receive, and landing a project can become a distraction from the work at hand. Consultants without this network to draw upon are forced to use platforms like Upwork and Freelancer.com, which in my experience are a lot like seeking true love through a series of blind dates, you may get lucky every once in a while but you have to be willing to wade through a lot of bad experiences to find the few good apples.

As with finding a new full-time role, you want to make sure the client and project are a good fit for your skills and interest. If so, you will set yourself up to provide ample value to the client and enjoy working with this organization through many renewal cycles. Otherwise you're likely to find yourself right back in this same position a few months later with very little to show for the time and effort you expended landing this new project and getting ramped up with the team. We feel very lucky to have had wonderful projects and clients largely fall into our lap when the need has arisen. The few times we've had to work hard to line up our next engagement have led us to deeply value these relationships.

Operating like an Employee

One thing that is always in your control is the level quality and professionalism you demonstrate throughout all aspects of your work with a client. It's not uncommon for some full-time employees within an organization to view outside consultants as mercenaries whose primary goal is to make a few bucks with as little time and effort as possible. We've found that the best way to change peoples' opinions, or to at least to separate yourself from this class of consultants in their mind, is to maintain the same mindset as if you were a full-time employee. Strike the same balance between shipping the functionality being asked for while doing so in a way that best sets the team up for future success.

Invest in artifacts like documentation, observability dashboards, and automated test coverage that will equip the team to maintain and extend the features you deliver with ease.

For example, invest in artifacts like documentation, observability dashboards, and automated test coverage, that will equip the team to maintain and extend the features you deliver with ease. None of this should come as a surprise and in reality these are ordinary expectations for high quality work, but as a consultant who has no guarantee of being involved in the project for years to come, being particularly diligent about capturing these artifacts ensures that no matter what happens you have set the team up for success down the road.

If you're willing to remain mindful of and combat these challenges, you can certainly find success and satisfaction in running and growing your consulting business. Are there other aspects of this style of work that raise concerns for you? We'd love to hear about them and be happy to share any insight available from our experiences. Feel free to reach out to us at hello@gobetweenlab.com. And don't miss the next post in this series as we wrap up by sharing the biggest benefits we've realized from launching and operating our three person consulting business over the past three years.

The Go Between Summit

Dan Lavin — Thu, 12 Sep 2024 24:00:00 GMT

Background

Go Between is a fully remote company with roots in Chicago, where we first started working together. You can read more about our origin story here, but eventually, life led us to branch out. Harrison moved to the sunny coastline of California, while Truman relocated closer to family in Michigan. I stayed in Chicago for the freezing winters and amazing restaurants. I’ll let our readers decide who has their priorities straight.

Remote work is a great arrangement for us. We love the freedom and flexibility it provides, and most of what we do on a day-to-day basis is well suited to the remote lifestyle. Client work is done from the comfort of our home offices. We meet virtually multiple times a week to discuss both personal and professional topics. Every quarter, we meet to review our high-level goals and strategic objectives. We learn together. We listen to music together. We share pictures of our lives in Slack, just like any other company. These activities help keep us on the same page and ensure our relationship as a team remains strong. Also, it doesn’t hurt that we started Go Between after working together for many years.

There are certain aspects of collaboration and relationship-building that can't be replicated remotely. Whether you're brainstorming new product ideas or sharing something hilarious your kid said, there's a different energy and excitement when you're in the same room.

However, there are certain aspects of collaboration and relationship-building that can’t be replicated remotely. Whether you’re brainstorming new product ideas or sharing something hilarious your kid said, there’s a different energy and excitement when you’re in the same room. Plus, you can only sit through so many video meetings before you start to lose your mind. At some point, there’s undeniable value in getting together in person. Thankfully, we understood this from the start, which is why we made it a priority to meet in person at least once a year. We call each annual gathering a Summit.

Planning a Summit

Our first couple of summits took place in Chicago. It’s easy to get to, offers plenty of activities, and, perhaps most importantly, summer in Chicago is awesome. Plus, Harrison and Truman love coming back to enjoy all the great food the city has to offer. But this year, we decided to switch things up and chose the quiet, nature-filled beaches of Saugatuck, MI.

When planning a summit, the first thing we do is choose a date and location so we can secure transportation, lodging, and any activities that require reservations. Typically, this all comes together asynchronously over a few Slack calls, but for larger teams, this process might be a bit more involved. Once the logistics are set, we shift our focus to building out the summit agenda.

Like most things we do, this process is simple and lightweight. We create a Slack Canvas and begin adding discussion topics, ranging from general business updates and consulting services to new product ideas and website improvements. We also include any activities, restaurants, or coffee shops we want to check out while we’re together. Most of this planning happens asynchronously in the weeks leading up to the summit. This works well for us, but we’re a small team, so take it with a grain of salt. If you’re considering a summit, do what works best for your team and try not to put too much pressure on yourself. Keep the agenda flexible and ensure there’s a healthy balance of both work and play. Summits don’t need to be extravagant getaways, nor do they need to be planned down to the hour. The real value of a summit comes from being together.

Keep the agenda flexible and ensure there's a healthy balance of both work and play. Summits don't need to be extravagant getaways, nor do they need to be planned down to the hour. The real value of a summit comes from being together.

The Go Between Summit

We enter each summit with a list of discussion topics and high-level objectives, but beyond that, the goal is simple: have fun, eat well, and walk often. With that in mind, here’s a recap of our weekend together!

Day 1

We all arrived in Saugatuck around 4:30 p.m. ET. I picked up Harrison from the airport in Chicago, while Truman stocked our Airbnb with food and drinks for the weekend. Once we settled in at our cozy cabin, we headed downtown to explore. Truman, having visited Saugatuck before, knew the area well. We had dinner at a waterfront restaurant called “The Southerner” (definitely try the fried chicken!). Afterward, we strolled around town before heading back for a nightcap of board games*.

*Truman has a fun tradition of bringing a new board game to each summit for us to play in the evenings. This year, he chose Thunder Road, which was a great way to end each night.

Day 2

Our first full day started slow, which was perfect for me as a father of three—I’ll take all the sleep I can get! After everyone enjoyed Do-Rite donuts and coffee, we dove into our first block of meetings. The morning focused on our consulting business, where we reviewed current engagements and discussed adding new services, like fractional product and engineering leadership. We took a break afterward to visit the farmers market and pick up supplies for taco night. As our caffeine started to wear off, we stopped by Outside Coffee, one of Truman’s favorites—and for good reason. Afterward, we returned home, had a big lunch, and decided it was time to get active.

Before the summit, we decided to have an in-person Marginal session, so we all read Slow Productivity and came prepared to discuss it over the weekend. Harrison suggested reviewing the book while hiking, and it turned out to be a great idea—something about being in nature sparks creativity. The book was good, but the biggest takeaway was realizing we were trying to do too much. We need to focus on one thing for longer periods. With that, the idea of working in more focused cycles began to take shape. Afterward, we headed back to the house to relax before making dinner.

Something about being in nature sparks creativity. The book was good, but the biggest takeaway was realizing we were trying to do too much. We need to focus on one thing for longer periods.

Taco night was a great success, but once again, we felt the need to walk off our food-induced guilt. We went downtown for a stroll and stopped at Mitten Brewing Co.. for a flight of local beers before returning for round two of Thunder Road.

Day 3

Our last full day began with coffee and some slightly stale donuts. Truman found a nice long hike for us, and since the weather was warm, we decided to head out first thing in the morning. The conditions were perfect, and the scenery was beautiful. During the hike, we spent most of the time talking about working in cycles and how that fits into our current consulting workload. We explored potential areas of focus for each cycle, like growing our audience and building new products. The conversation was excellent.

After the hike, we were hungry and didn’t feel like cooking, so we grabbed lunch at The Butler. The food was good, but the view of the water was even better. We did some more walking, then stopped by a local toy store so Harrison and I could pick up some souvenirs for our kids before heading back to freshen up.

Our morning activities left us pretty tired, so we spent the next couple of hours brainstorming new product ideas on the couch. Harrison found a fancy restaurant called Coast236, so that became our plan for dinner. Before heading out, we decided to start documenting these summits and took a company photo on the deck. Dinner was fantastic. Naturally, we went for a final stroll along the water, then stopped at Charlie’s for ice cream before heading back for one last night of Thunder Road!

Day 4

Harrison had a flight out of Chicago around noon, so we woke up early and grabbed one last coffee at Uncommon Coffee before hitting the road. We used the time to review the outcomes of the weekend and make sure we were aligned on our next steps.

Next Steps

Each summit is a little different, but one constant is that we always leave with key insights and new priorities. These might include a new product idea to develop, updates to the website, or a shift in our consulting strategy. This year, we left Saugatuck with a plan to reintroduce the concept of working in cycles. You’ll hear more about cycles in a later post, but for now, this essentially means spending our non-billable hours intensely focused on one thing for 6 weeks at a time. To start, this “one thing” will be audience development, since we believe it adds value to both our business and future product initiatives. Our high-level goal for the next 6 weeks is to produce enough content to maintain our weekly LinkedIn posting schedule through the end of the year. After that, we’ll shift our focus to product development for 6 weeks. We plan to continue this cycle, alternating between audience development and product building, until our next summit.

Wrapping up

Summits offer a refreshing break from our daily routines and remind us of the value of good old fashioned human connection. Consider this your sign from the universe to step out of the office and spend some time with your coworkers. I promise that you and your team will return with stronger relationships and a renewed sense of focus and direction.

If you’ve done something like this before, we’d love to hear about your experience. And if you’re thinking about planning your first summit but don’t know where to start, feel free to reach out. We’d love to hear from you!

Lessons in Consulting - Part 1

Harrison Strowd — Thu, 05 Sep 2024 24:00:00 GMT

Do you catch yourself from time to time day dreaming about being your own boss? While it's probably not quite as care-free and leisurely as you envision, we are living proof that it's within reach. We launched Go Between in the summer of 2021, and while we had a clear and compelling vision of where we wanted this venture to lead (check out the Hello World post for more on this), it was far from assured that we would succeed. In this three-part series, we'll share some of the lessons we've learned throughout this journey starting with a few tips that proved beneficial as we got our business up and running.

Test the Waters

It should come as no surprise that your success in consulting will be largely determined by your professional skills and your ability to find companies who are both willing and able to leverage those skills. This is true both if you are starting as a freelancer or if you have a couple of trusted partners embarking on this journey alongside you. While these two key drivers of success are easy to identify, they turn out to be quite hard to confidently assess prior to getting started. Are companies looking for consultants with your skills? Can you find these companies and convince them to pay for your services?

In most software related fields, you don't have to "take the plunge" in an all-or-nothing manner to answer these questions.

In most software related fields, you don't have to "take the plunge" in an all-or-nothing manner to answer these questions. Finding projects on public platforms, like Upwork and Freelancer.com, or reaching out to a couple of people in your direct network, can allow you land a few initial projects before you have to decide whether to take this on as a full-time role.

Mindset Matters

If your main focus is on "selling your time", this attitude will be apparent in all of your interactions and in the artifacts you produce. It's far more beneficial to approach each engagement with a partnership mindset, identifying problems that you are well suited to solve and working collaboratively with your client to produce the best solution for their specific problem. This not only improves the quality of your work but also builds much stronger relationships with your clients, not to mention that you will have a ton more fun in the process.

It's far more beneficial to approach each engagement with a partnership mindset, identifying problems that you are well suited to solve and working collaboratively with your client.

Long-Term Career Goals

If your vision of success is managing a large team at a Fortune 500 company one day, consulting as an individual or as a small team is likely not the most effective path to get you there. Instead of developing management and leadership skills as you gain responsibility for larger and larger teams, this role will provide opportunities to build deep expertise in your craft and gain experience working across a wide range of teams, organizations, and industries. So if you aspire to be the go-to person when your client has a really challenging problem, has a project that's crucial to complete on time, or needs trustworthy, external advice, then this role could be a great fit and offer you tons of satisfaction for years to come.

Part-Time vs Full-Time Engagements

While your early projects may naturally be part-time engagements, as you test the waters while maintaining a full-time role, eventually you’ll land an opportunity that could consume all of your and/or your team's available time. At this point you'll face a key decision about how you want to run your business. Do you want to maintain multiple, concurrent part-time engagements at all times? Or do you want to devote all of your attention to a single team/project at any given time? It is particularly challenging to transition between these two modes of operation, making it something worth considering up front.

A few of the key benefits in working part-time across multiple projects are:

Being able to gradually build expertise in a new area
Avoiding periods of complete downtime between projects
Developing and maintaining active relationships with multiple clients

On the other hand, focusing on a single project allows you to:

Avoid the need for rapid context switching between projects
Devote your time and attention fully to a single client
Integrate more cleanly with an existing team of full-time employees working on the project

There is no strict right or wrong answer to this question, but it is crucial to be mindful of the tradeoffs as you embark in either direction.

There is no strict right or wrong answer to this question, but it is crucial to be mindful of the tradeoffs as you embark in either direction.

To Grow or Not To Grow

Is the strategy for your business to stay small, providing increasingly higher value services to your clients? Or are you aiming to grow by expanding your team over time as you attract new clients, while retaining your existing engagements? While both of these approaches can produce a great deal of success and satisfaction, they require starkly different skills from their founding members.

Strategically small consulting teams must be very thoughtful about where they choose to spend their time, turning away projects that are not the best fit for their skills or interests. Growth-oriented consulting teams on the other hand place a greater emphasis on sales and marketing activities in order to build and maintain a consistent funnel of new clients. These teams will also need an effective recruitment pipeline to attract talented new team members, either as subcontractors or as employees, who will deliver high quality results for the business' growing portfolio of projects.

Are there other key decisions or aspects of freelance or small team consulting that seem concerning or important to consider up front? Get in touch with us at hello@gobetweenlab.com and let us know. We'd be happy to share our insight and feedback. If this still sounds like an exciting adventure, keep an eye out in a couple of weeks for the next post in this series where we will share more thoughts on some of the challenges you'll face as you establish your consulting business.

Software Engineering for the Present & Future

Truman Shuck — Thu, 22 Aug 2024 24:00:00 GMT

Do you feel like you're pushing out one tangled pile of software after another? Or, fouled by experience with spaghetti code, do you endlessly polish, searching for that future-proof metaphor? Both roads lead to headache.

Software engineering is partly the act of writing code for our present needs — the feature that improves conversion or the bugfix that prevents the annoying on-call page. It is also the act of writing code for our future selves; when we're deep in some system that hasn't been touched in six months and wondering who in the world thought this structure was correct.
It's often you. It's often me.

Software engineering is partly the act of writing code for our present needs, and also the act of writing code for our future selves.

The tension between present and future, speed and maintainability, is a source of stress in engineers and engineering organizations alike. Too quick now and the future project is bogged down by hard-to-extend code and fails. Too deliberate now and there is no revenue for future projects.

A quote has followed me throughout my career. Carl, an exceptional software engineer that I had the pleasure of working with, once remarked that "all code is technical debt." Anish Kapoor shaped steel into Chicago's Bean, but mostly we use steel for i-beams and bolts. A function may be aesthetically elegant, but mostly we're writing infrastructure for CRUD applications.

All code is technical debt. A function may be aesthetically elegant, but mostly we're writing infrastructure for CRUD applications.

It's said that anyone can build a bridge that stands, but only a good engineer can build one that just barely stands. To create an application that just barely executes we have to build it on the right structures. Good engineering requires an understanding of the systems we're working in. It requires technical discovery and forethought. It also requires that we don't overbuild.

Code facilitates value but is not itself valuable. It's the tension cable and the reinforced concrete slab. It should be well designed, but we know that it must also be maintained. A lean system has less technical debt, less surface area to rust. We build just enough to get the job done, but we do so in acknowledgement that we'll return to work here again.

I've given up foretelling how to build perfect software, so these ideas help me in technical discovery, in planning, and in execution. I spend my extra 20% effort to get a metaphor that feels about 80% correct. I thank my past self and find joy in factoring a little better while extending that work six months later.

All of the best answers are the frustrating ones: it depends; it's about the feel of it; it's not at the extremes but somewhere in the middle. It helps to know that a little work now is worth it in the future.

Code facilitates value but is not itself valuable. A lean system has less technical debt, less surface area to rust.

Thanks for your time and attention.

The Right Kind of Lazy

Harrison Strowd — Fri, 09 Aug 2024 24:00:00 GMT

The software engineering community often alludes to the benefits of being lazy as a analogy for efficient execution. However too often this “laziness” becomes a scapegoat for avoiding mundane activities that are actually the grease that keeps things running smoothly within an organization. It’s time we drew a clearer distinction between the types of laziness that are productive/valuable and those that actually end up coming back to bite us.

The software engineering community often alludes to the benefits of being lazy as an analogy for efficient execution. However, too often this "laziness" becomes a scapegoat for avoiding mundane activities that are actually the grease that keeps things running smoothly.

Good Lazy: Just-in-time Optimization

Despite being done with the best of intentions, the tendency to prematurely optimize a feature or application is a common pitfall for teams and engineers across nearly all stages of experience. Here is one scenario where it truly pays to be lazy and leave tomorrow’s problems to be solved tomorrow. The justification for adding currently unnecessary capabilities is often that “we know we’ll need it eventually” but the reality is we are better engineers than fortune tellers. Not only is it difficult to predict what features will be needed down the road, it’s most likely that our current understanding of the problem to be solved or how the solution should be built will change between now and when the feature is actually needed. Waiting to build this feature will both allow you to do so with a more complete and accurate understanding of the problem and will also give you the most freedom and flexibility in how we design the best solution.

Waiting to build features will both allow you to do so with a more complete and accurate understanding of the problem and will also give you the most freedom and flexibility in how we design the best solution.

While overestimating the value of these premature optimizations can be very costly on its own, it is also quite common to underestimate their costs. First and foremost is the opportunity cost of the time to develop the feature. Instead of building a valueless feature, you could have been solving problems for your users. Furthermore, this unused functionality still incurs ongoing maintenance costs as you develop and maintain the system as a whole. Finally, if/when this feature becomes necessary it is likely to need modifications to fit the updated context and understanding of the problem being solved. In the best cases, this rework of the feature can be relatively straightforward but in some cases it will require significant refactoring of the implementation which can significantly increase the overall cost of developing the feature.

Bad Lazy: Leaving No Trace

When was the last time you come across a commit messages like “Fixes the thang”, a pull request description of “No description provided.”, or an entire sequence of changes like the following:

When you’re assigned to code review these changes, this is slightly annoying and wastes a bit of your time to dig up the true context for the changes being made, but when you’ve got a production bug that needs to be fixed ASAP and the root cause is traced back to a change like this, this type of laziness can end up doing real damage to your business.

At the end of the day I find this behavior typically stems from one of a few mindsets:

Selfishness: It’s a harsh label but the truth is that the author of these changes prioritized their own time and efficiency at the cost of their teammates’. While this isn’t typically done with malicious intent, it demonstrates a lack of discipline necessary to spend time capturing clear, concise code artifacts even when we get tired, busy, or distracted.
Being Funny/Cute: Trying to be funny in commit messages or playing up inside jokes within our teams has a cost that is often overlooked. This is frequently done under the guise of building culture or camaraderie within the team, which is a worthwhile endeavor, but should not come at the cost of reduced clarity in code artifacts or impediments to effectively maintaining the system.

It takes a bit of self reflection, but these states of mind are something we can detect and should choose to avoid.

Good Lazy: Enforced Consistency

Following consistent patterns within a code base (e.g. casing, tabs/spaces, types of quotes, max line length, etc). makes it much easier to get ramped up on a new system and to maintain that system over time. When managed by hand, these patterns can be difficult to enforce and time consuming to maintain, particularly as new engineers join the team and need to learn the set of patterns followed within the application. Automating this process using a linter that supports auto-correction, such as Rubocop, Prettier, etc, removes the mental burden of keeping track of and implementing changes in accordance with the coding practices adopted by the team. This ends up saving a ton of time and mental bandwidth, particularly when considered cumulatively across an entire team, that can instead be put to use shipping features that actually deliver value for your customers.

Getting this type of tooling setup from the initial launch of an application is certainly the easiest approach but it’s never too late to get started. Most of these tools include helpful features, such as customizable rule sets, a list of files/checks to ignore, and configurable thresholds, that allow teams to integrate the tool into their CI/CD pipeline with very little disruption to the codebase or development processes. Once setup the team can gradually migrate the codebase toward increased adoption of the set of selected best practices. While it’s still true that there’s no such thing as a “free lunch”, using an auto-correcting linter is pretty darn close.

Bad Lazy: Outsourcing to ChatGPT

While the allure of asking ChatGPT to implement your next feature may be high, there are some significant risks to this approach that are worth keeping in mind.

The Buck Never Stops with the AI: At the end of the day, if you copy the output of an AI bot and anything goes wrong with these changes, it will be your responsibility to explain and correct this logic. If you failed to fully understand and validate this functionality, you won’t be able to sufficiently answer questions about your approach or find and correct a nuanced bug in an efficient manner.
AIs are Imperfect: When the solution proposed by an AI bot contains a bug it can be extremely difficult for an engineer to find and fix this bug. In such cases the total time spent can quickly exceed the time it would have taken to develop a solution from scratch. In the worst case, if the bot’s bug cannot be fixed, the engineer is forced to start over from scratch with nothing to show for the time they spent debugging the solution proposed by the AI bot.
The AI Crutch: While AI bots can potentially help less experienced engineers execute more efficiently in the short term, this results in the engineer missing out on a lot of valuable learning that occurs when you struggle through a problem and experience the complete set of steps that lead to the eventual solution.

To be clear, ChatGPT and other AI co-pilot tools are valuable resources that are great to leverage in an advisory manner, to unblock your progress, or as a sounding board for alternative approaches you may not have considered, but at the end of the day, all final work products should be fully owned by the authoring engineer without assuming the correctness or superiority of the solution proposed by an AI. Rather than asking an AI bot for a complete solution to the task at hand, consider posing a smaller, targeted question that allows to bot to unblocked your progress but leaves the remainder of the solution for you to proceed through.

At the end of the day, if you copy the output of an AI bot and anything goes wrong with these changes, it will be your responsibility to explain and correct this logic.

In Summary

This is far from an exhaustive list but should serve as a starting place for thoughtfully considering where you choose to be lazy and where you recognize the value in a little bit of elbow grease. As with so many aspects of software development, there is judgement to be applied in each of the scenarios described above. Treating these examples or similar precept as a strict rule to be followed, regardless of the context or circumstance, will eventually lead to disappointing results. Regardless of whether you're taking the easy street approach or grinding it out, there is no substitute for giving thoughtful consideration to the decision and understanding the tradeoffs.

There is no substitute for giving thoughtful consideration to the decision and understanding the tradeoffs, regardless of whether you're taking the easy street approach or grinding it out.

Have you recently come across other examples of either good or bad forms of "lazy"? We'd love to hear about them. Drop us a line at hello@gobetweenlab.com and let us know.

Effective Context Switching

Harrison Strowd — Thu, 08 Aug 2024 24:00:00 GMT

For software engineers having time to focus exclusively on the single most important task is typically the most efficient way to solve a problem. And while there are steps we can take to optimize our work and our teams for uninterrupted periods of focus, the reality is that life often gets in the way of these plans.

As a result, we've found that it's important to embrace context switching. To learn how to continue delivering high quality results when we don't have the luxury of uninterrupted concentration. Context switching gets a bad reputation, but in reality most days get broken in to small blocks of time, so learning to use that time effectively can delivery significant productivity wins.

Context switching gets a bad reputation, but learning to use fragmented time effectively can deliver significant productivity wins.

Here are a few techniques we've found particularly valuable:

Breakdown large tasks into small executable steps.

Doing this not only provides safe stopping points throughout your work on a project, but it also ensures you have a solid understanding of the full scope of work. This will also help you avoid the dreaded "rabbit hole," an all too common culprit when it comes to wasting time.

Breaking down tasks not only provides safe stopping points throughout your work, but it also ensures you have a solid understanding of the full scope.

Find a personal to-do/task management app that works for you.

Multiple members of our team love using Todoist to manage both work and life related tasks. The key is finding something that allows you to quickly capture tasks in the moment without breaking your flow. Once those tasks are out of your head, you're free to organize and prioritize them when it makes sense for your schedule. Having a personal backlog of is a great way to make sure you're not wasting time trying to figure out what to work on next.

Using Comments

Drop a TODO comment for code you need to revisit or leave a test in an intentionally failing state when you have to turn focus to another item. Effective mid-development documentation and pointers like this help to quickly regain your train of thought and ensure you do not loose track of important details that need to be addressed before committing your changes.

While this is certainly not an exhaustive list, we've found that these small steps have an outsized impact on our productivity. Learning to context switch has helped us deliver high quality work in a more consistent and efficient manner.

These small steps have an outsized impact on our productivity, helping us deliver high quality work in a more consistent and efficient manner.

Pull Request Structure

Truman Shuck — Thu, 01 Aug 2024 24:00:00 GMT

An all-too-familiar scenario: you open a pull request in github. It has no description. It has three commits: "WIP," "Fixes issue," and "Whoops formatting." It has 24 file changes littered around the codebase. Your coworker opens your PR for review and promptly closes their browser window. Why? Your pull request did not communicate the motivation, reasoning, and proposed execution of your change. It's a difficult proposition even in good conditions.

Your coworker opens your PR for review and promptly closes their browser window. Why? Your pull request did not communicate the motivation, reasoning, and proposed execution of your change.

We can do better for ourselves and our fellow developers. Here are some strategies we use to make the intention of our own pull requests simpler to understand and their proposed changes easier to review:

Tale Telling

This will not be the first post to highlight how good a good commit message is. There's more we can do beyond a pithy description of a coherent unit of work. Commits can be made to tell a story in context from one to another: clearing the ground here; then, establishing the new system there; then, exercising the change in this path; finally, whoops, formatting. Rebase (-i) is a cantankerous but invaluable friend.

Commits can be made to tell a story in context from one to another: clearing the ground here; then, establishing the new system there.

Illustration

Changes to a user interface can be described visually with a set of images, a gif, or a short voiceover walkthrough which focuses on the new experience. Show, don't tell, can be taken literally to great effect.

Exercise

We execute the code we're authoring in order to make sure it works, right? (Right?) A living system is usually more than the automated tests that we also include. Record your setup, and interaction, and outcome. Flip back and forth between your console/UI, the code, the database. Show how everything breathes together.

Show how everything breathes together.

Finally, include a gif of a cute Koala at the end of your well-written description. Because diligent reviewers deserve a small treat.

The Opinion Zone™

Truman Shuck — Wed, 17 Apr 2024 24:00:00 GMT

Strong Opinions, Strongly Presented

The phrase "Strong Opinions, Weakly Held" (sometimes "Loosely Held") is attributed to Paul Saffo, and originated as a framework for making decisions in the face of certain uncertainty. Its general hypothesis is that it's less costly to make an imperfect decision than to delay until enough information has been gathered in order to make a more perfect one — and that moving forward with a decision unsticks the brain in a way that allows new information, and actions, and decisions, to continue flowing. Holding the opinion weakly, loosely, allows for that new information to alter the decision at hand or alter its following steps, without allowing ego or sunk cost to attach any unhelpful importance to the act and artifact of deciding.

The Cage Match of Ideas can sometimes be fun, but the conflict-laden language is adversarial and can be exclusionary. It self-selects for the style of an idea's presentation rather than the quality of the idea.

I am not the first to say that a common application of Saffo's idea allows for certain folks to stridently declare their strong opinion in such a way as to exclude feedback from anyone unwilling to force an equally strident debate. The Thunderdome, The Octogon, The Cage Match of Ideas — where the strongest survive and all others perish — can sometimes be fun, but the conflict-laden language is adversarial and can be exclusionary. It self-selects for the style of an idea's presentation rather than the quality of the idea. It excludes folks who prefer a more chill discussion, or who are working through conflict avoidance, or where power dynamics make direct opposition feel unsafe.

Strong Opinions, Equivocated

It's important to form opinions, to share advice, and to make decisions, because it's helpful to other people. The great Bell Hooks quotes M. Scott Peck in her book "All About Love" to say that "the will to extend one's self for the purpose of nurturing one's own or another's spiritual growth" is at the heart of the act of love. This is a strong and specific word, and I do not mean to co-opt her nuanced and important work in order to make a small point about professional life. Still, I think it's better to at least care for the people that I work with than to not — at least when I'm able. This is part of the responsibility that comes with knowledge: to share it in order to helps others grow, and to share it in a way that is helpful for them to receive.

This is part of the responsibility that comes with knowledge: to share it in order to help others grow, and to share it in a way that is helpful for them to receive.

Attempting to silently disappear from the world, or to equivocate an opinion into meaninglessness, is unhelpful. It fills a meeting with awkward silence or, worse, dithering noise. We're left with an obligation which includes the added complication of having to carefully think of others and how to invite them kindly into the conversation.

Strong Opinions, Qualified

I've found a strategy that I think works pretty well; it's in two parts. The first part is drawn from common advice on giving advice: to center my opinions in my own experience. Adding something like "what's worked for me before" acknowledges that my opinion is based on my circumstances, which are not universal, and so may or may not match with others' present situation. The second part I call the Opinion Zone™ and involves an imaginary box that's drawn in the air.

To admit my likelihood for being wrong is a small act of humility that I find to be a helpful reminder: to be a little less serious; to be a little more flexible; to be a little more open to the opinions and advice of others.

Some folks may joke that I'm outlining the soapbox that I'm about to metaphorically stand on, and it's true that have a tendency to speak in (brief!) diatribes. What I intend to call out, with a little humor, is a bit of shorthand by way of the gesture. To say that I have some thoughts to share, and that while I believe they are helpful, to reiterate that they are my own and are subject to my circumstances. To note that they are fallible and that I am fallible. To invite others into the conversation and to leave room for their own Opinion Zones® which may or may not overlap with mine.

To admit my likelihood for being wrong is a small act of humility that I find to be a helpful reminder: to be a little less serious; to be a little more flexible; to be a little more open to the opinions and advice of others. To try to help anyway is some part of my responsibility to care for others. I hope you find this helpful, too.

Thanks for your time and attention.

Musicbox

Truman Shuck — Fri, 16 Feb 2024 24:00:00 GMT

An office radio for your remote office

Many years ago I was part of a team that used the now-defunct plug.dj to take turns sharing music with one another during our workday. It was a magical and, due to their peculiar aesthetic and UX choices, inexplicable experience. At its heart, plug.dj allowed folks to pick songs that were then played for everyone simultaneously; this was fun, but more interestingly it often led to music-related anecdotes and other side-conversations that brought me closer to the folks I was working with.

Since the average person listens to music for 32 hours per week, we thought that getting coworkers to share part of their listening experience, and through that, to share part of themselves, might bring folks a little closer together.

Many years later, in the early history of Go Between, Musicbox started as a side project that sought to recreate the explicable parts of that early experience. Its core mechanic was similar: everyone queues songs, Musicbox cycles through in round-robin style and plays them. Where plug.dj focused on sharing music with strangers' dancing hyper-color avatars, Musicbox encouraged teams of people to connect over the tunes that had been chosen. It included chat, recommendations, and a feature that allowed you to "pin" a message as a memory to appear whenever a given song played in the future. Since the average person listens to music for 32 hours per week, we thought that getting coworkers to share part of their listening experience, and through that, to share part of themselves, might bring folks a little closer together.

When every nuanced human problem looks like a nail

As software engineers who moved to remote work during the pandemic and later started a remote company, we've had our share of uncanny-valley experiences that result from trying to use technology to facilitate connection. We've come to recognize that while technology can solve specific, defined issues, it often misses the subtleties of human interaction. The intention of Musicbox was not to serve as an all-encompassing solution for digital solitude -- but we've found that we like to build tools that speak to getting to know the people that we spend time with at work on a deeper, human, level.

We've come to recognize that while technology can solve specific, defined issues, it often misses the subtleties of human interaction.

As we used Musicbox we started having conversations like this:

While "Surfaces - Sunday Best" plays in the background

Dan: My sister originally shared this song with me and then I forgot about it until I was watching a recent episode of "Ted Lasso" and I was reminded of how happy this song makes me

Dan: Also, Ted Lasso is not only my favorite show right now, it's the only show I watch.

Spencer: Just watched the trailer, looks hilarious. I love Jason Sudeikis. Going to start watching that

At a parting of ways, we listen to "Nickelback - Photograph"

Truman: Did you know that Chad Kroeger and Avril Lavigne were married from 2013-2015?

Dan: https://www.theguardian.com/lifeandstyle/shortcuts/2017/may/15/avril-lavigne-melissa-cloning-conspiracy-theories

Dan: Was he though???

Truman: incredible. Reminds me of the "Bigger Luke" conspiracy: http://biggerluke.wikidot.com/bigger-luke

Spencer: I was just going to ask if you guys knew the obscure conspiracy theory about fake Avril Lavigne

During a 90s/00s kick with "Incubus - Stellar (Official Music Video)"

Truman: lol hey Incubus

Truman: "Stellar" reminds me of college because my freshman dorm neighbor would play Guitar Hero a _lot_. And then they graduated to Rock Band and played that a _lot_ after it came out.

Dan: was stellar in guitar hero? I don't remember that one

Truman: Yeah, it's in the first game -- https://guitarhero.fandom.com/wiki/Stellar

Dan: My best guitar hero songs were: the killers: when we were young; weezer: my name is jonas; bloc party: helicopter; rage against the machine: bulls on parade

Truman: I didn't play a ton of guitar hero myself, but I've heard "Don't Fear the Reaper" more times than I think anyone reasonably should

We listen to a lot of music in Musicbox (~12,000 songs enqueued in 2023), so please don't judge this incidental selection too harshly. And while these conversations are not the hearts-to-hearts strangers-turned-lifelong-friends via the magic of technology, they do highlight where a long day could be lightened by a shared Ted Lasso joke, or an awkward lunch whose ice might be broken discussing whether Avril Lavigne really was bodysnatched.

How to build a good product and fail to launch a good product business


        <div class="border-l-2 border-lime-800 ml-8 text-xl md:text-2xl lg:text-3xl">
          <blockquote class="not-prose font-light ml-8 mr-16">
            
We built Musicbox mostly because we wanted it to exist. We acknowledged but did not start with answering some of the questions that pose existential risk to real products.

            
          </blockquote>
        </div>

Musicbox was a nights-and-weekends project, so we chose tools that we were familiar with: a single-page React front-end (still source-available!), and a Rails api (where we mostly wrote tests and followed reasonable engineering practices). We worked on features that were fun, and we made it work and then made it nicer afterward. We built Musicbox mostly because we wanted it to exist. We acknowledged but did not start with answering some of the questions that pose existential risk to real products: will teams of people pay for this thing? Can we reach an agreement with the music provider at a scale and cost that allows this whole thing to work?

After about a year of off-and-on effort, we felt that we had a product that was usable enough to receive feedback from humans other than ourselves. We had a landing page and a manifesto. We invited former teammates to try it with their new teams, and people seemed to get its value proposition. We had a "maybe" to our first question, but it turns out that we had a hard "no" to the second.

While most of Musicbox's machinery is source-agnostic with regard to the music it plays, we built it first in integration with YouTube videos. As more folks were using the tool and we began bumping up against the "starter" API quota, we realized that we'd finally have to reach out to Google to see what it would mean to share the product with more people. After agonizing over their quota increase request form for a few days, we submitted our best description of a Musicbox which used YouTube's features -- and that it would like to use them more -- but which was primarily its own product that focused on creating shared experiences for teams of professionals. Our request was summarily rejected with the note that Musicbox "re-implemented core YouTube functionality," and our API request quota was reduced to zero.

Afterward

The blunt response to our quota request drove home a simple point: probably don't try to build a product whose value depends upon a third party's ad-monetized service. We could have appealed, or pivoted to another music provider (we had considered Spotify with the requirement that users have a premium account), but by this time our fledgling company Go Between had taken on a much clearer shape and we were ready to turn our attention elsewhere. We were -- and still remain -- interested in exploring ways to help teams of folks get to know each other, although we would change our tack a bit. We did not yet change the "create it for ourselves first, and figure out how to market it later" approach; you can read more in our post on Marginal, "How to build a simple Rails CRUD application in just two years."

Musicbox's Top 10 for 2023

Musicbox still lives on, but just for our small team. I'm listening to synth with Dan while I'm finishing this post and he's updating styling on Go Between's website. In 2020 we listened to 10,000 songs; 9,000 in 2021; 12,000 in 2022; and 13,000 in 2023. Most recently over winter break I merged some work to make our annual recap, "Musicbox Unwound," easier to generate. The repos are available for anyone's perusal -- and if you get the itch to contribute and move this whole thing to Spotify, well, we'll happily figure out a revenue share.

Thanks for your time and attention.

Hello World

Truman Shuck — Wed, 10 Jan 2024 24:00:00 GMT

Origins

Over the course of our lives, Dan, Harrison, and I began to realize that we were becoming unemployable. This was a few years ago for Dan and I; Harrison's unfettered love of problem solving had already brought him to his solo consultancy (Haresoft) back in 2016. Our perceived inability to be employed was not a matter of quality. We had been well regarded and had reached various senior positions over the course of our careers, but had begun to discover specifically what we wanted in our work. It was breadth: to act from customer interview to design, through engineering to delivery, and back. And it was what we thought it meant to build good software products at a sustainable pace in a psychologically safe environment.

We had begun to discover specifically what we wanted in our work. It was breadth: to act from customer interview to design, through engineering to delivery, and back.

I don't mean to say that we were in constant conflict with our employers, or that we regard them or their decisions poorly. We were not interested in setting our careers on a path to ascend an org chart such that it became any of our responsibility to decide how things should function. Advice has to be asked for in order to be valuable, and it was not our job to give it. Still, we had formed our opinions and despite attempts to keep them flexible (see the Truman Opinion Zone™), regular employment had started to chafe. We were figuring out what to do next.

Common narratives related to starting a business often speak to ambition or to an intense personal drive that precludes any other possibility. Neither of these are me, and I don't think they're especially Dan or Harrison either. The three of us had been working together for a while and we had discovered that we shared a specific common thread: that our personal relationships in the context of work mattered a lot to us, that we'd been extremely fortunate in finding one another, and that we wanted to keep building stuff together. Harrison put his thoughts in a document that we look back on fondly, the "Software Partnership Pitch." Collaborating on this document lead directly to Go Between.

Our personal relationships in the context of work mattered a lot to us, that we'd been extremely fortunate in finding one another, and that we wanted to keep building stuff together.

How to name a company

Dan, Harrison, and I are all interested in the various ways that technology products can support genuine human interaction. We'd been working on a related project called Musicbox in our spare time and our first step as a joint venture was to move its GitHub repositories out of my personal account and into a shared organization. Names are pretty hard, and we were bouncing between thesaurus.com and GitHub's new org form looking for something in the realm of human connection that hadn't been taken. Kindred, kin, folks, liaison, messenger, go between. A bit of an odd phrase, but unused. We snagged it.

Later, we were filling out our LLC paperwork on LegalZoom (we'd considered Stripe Atlas but Harrison already had experience incorporating so we figured we could save a few bucks) and while I don't remember the exact words I know that the "Company Name:" conversation was quite short. We figured we could always change it later (it's too late now — I have a Go Between branded hat), and it anyway fit pretty well. Our use of technology is among its best when it facilitates real relationships, and separately as a matter of our day-to-day work we'd become very good intermediaries between business, product, and engineering teams.

So Go Between was born as an LLC (taxed as an S Corp) with three equal partners and not a lot of additional bylaws. Technically I believe one document gives Dan 33.34 percent because fractions and floats and web forms are also pretty hard.

Hello, world

Really liking the folks that you're working alongside is not quite enough to hold a company together; it's also important to agree on all of the rest of the operational procedures. Like how you're going to make money to support your various cat, dog, tiny baby, mortgage, and coffee dependents and dependencies. Harrison had been solo consulting for five years and enjoyed always having something new to think about. We all love problem solving, and building things, and Dan and I specifically were really interested in continuing to build products for people.

I wouldn't say that we are overly risk-averse, but I would say that we are deeply uninterested in the type of life that soliciting venture funding, or lighting our savings on fire to fund a runway for some all-consuming business idea, would bring. A little later in our company history we started doing regular book clubs through Marginal, and Paul Jarvis' Company of One summed up where we had landed: starting a chill company where we could do work we found fulfilling and which had a strong sense of what was "enough" for us.

We started Go Between as a hybrid consulting/product business...with 75% of our working hours [on consulting]. The other 25% are spent on activities for Go Between and on product development.

So we started Go Between as a hybrid consulting/product business. Consulting with companies for product & technical leadership, product discovery, and team augmentation, has given us opportunities to solve problems across a variety of domains, to work with a lot of great folks, and has allowed us to continually pay our bills. We do that with 75% of our working hours. The other 25% are spent on activities for Go Between (like writing, hi!), and importantly on product development. We built Marginal that way, and now we're trying out other ideas — like a take on incident management. Our eventual goal is to find traction with one or more products and to swing the balance of our time toward product development bit by bit.

Happily so far after

I'm deeply grateful to have found my way to working with Dan and Harrison here at Go Between. I am writing this a few years into our collective history and I'm not surprised to be able to say that we still exist within the human condition: that there better times and worse times; that we have tried and failed and tried and succeeded; that we've learned; that we've invested in our relationships and have so strengthened them.

We've found it a lot harder to launch products on a few hours per week than we expected, and we haven't yet made progress with adjusting our time split. That we have to market, position, copy-write, and execute other tasks outside of our wheelhouse — building things — is part of the difficulty. Part comes from the various mistakes we've made with our strategies and types of tools we've tried to build. And part is that time taken off for appointments, or to head out a bit early for the beach on a Friday afternoon, usually comes from our small supply of Go Between hours rather than our billed time. Life is (among the myriad) a series of trade-offs and I appreciate that we get to trade for flexibility. We'll write more about this another time.

The value of our principles is not in their rigid application; they are better used to creatively inform how we respond to the varied, wild, wacky, situations that life presents.

It might also be said that consulting with other folks' businesses is not the wildly free activity that we may have imagined as we contemplated our impending unemployability. That's alright. Consulting is still fun and satisfying, and we derive fulfillment from delivering a ton of value to the companies we work with. And anyway the value of our principles is not in their rigid application; they are better used to creatively inform how we respond to the varied, wild, wacky, situations that life presents. And, as it's been said, you can't always get what you want. But we are working to get what we need.

Thanks for your time and attention.