Forem: Brian Leonard

Data Makes Your Tools Smarter

Brian Leonard — Wed, 26 May 2021 17:47:03 +0000

When I was in charge of Product/Engineering at TaskRabbit, it was always challenging to prioritize integrations being requested by our Marketing, Sales, and Customer Success teams.

First and foremost, most engineers just do not like working on this sort of thing. Often, this is the deciding factor in organizations. The work that gets done is the work that energizes people and no one was excited to brainstorm how we could most effectively sync data to Marketo.

What they do want to work on is the core product. That is why they joined the company and critically, they know how to be successful there. The requirements for the Intercom integration are much fuzzier. It is hard to know what success looks like. The ambiguity prevents the momentum often necessary to get the work started, much less to the finish line.

Of course, we also had our own goals. There were features to build, bugs to fix, metrics to move. When combined the the other factors, the integrations were at the bottom of the list despite the outsized opportunity to impact the business.

Customer Success

One practice we had at TaskRabbit was periodically shadowing coworkers on other teams. It is enlightening and helps build the empathy that makes the business much stronger. If you have ever done this, particularly with a customer success representative, you will know what I am talking about when I say that it is very difficult to watch.

The primary job is working tickets in a tool like Zendesk. As an engineer, the problems themselves made me sad because they were often bugs or fundamental misunderstandings on how the product worked. However, I had much more anxiety over the process of solving the ticket itself. Specifically, the data to help close those tickets is everywhere. Each ticket leads to multiple tabs just to get the right context and few more to solve the problem.

When this data inefficiency is multiplied for all the customers and all the tickets and all the coworkers, it is a huge waste of time that negatively affects everyone: the customer, the coworker, the business.

The key concept of integrations is leverage.

An data integration makes it possible to route the tickets better and surface key data right there in Zendesk. I've seen this result in 10x efficiency increase which as a huge impact on customer and coworker satisfaction, leading to a much stronger business.

The leverage here is tremendous because of the volume, scale, and how manual things were to begin with.

Marketing and Sales

In Product organizations, we thing in product terms. What can we build that will attract more users? What feature will make them stay around longer? However, it often turns out that's the wrong solution space altogether.

After the minimum viable product stage, the difference in many businesses is channels.

Let's agree that if nobody knows about the product, it doesn't matter what features you have. The solve for that isn't always a better landing page. It might be a Facebook ads integration to allow the Marketing team to create lookalike audiences.

If someone has signed up or used the product, what's going to bring them back? Not your social proof on the funnel. And probably not the generic newsletter each month. The most effective tool here is personalized communication about their needs where they are in the journey, accomplished by syncing their data to tools like Mailchimp and leveraging that to be more relevant.

B2B cases are all about timing. How can you reach the right people at the right time with the right message? It's not going to be a feature and it's not going to be blindly emailing all of the accounts. When Salesforce knows about recent activity in the product, you can use that data to trigger the right communication to better qualified leads.

A Common Language

Even with these strong business cases, integrations were always still hard to prioritize because of the unfamiliarity. Eventually, they had to happen for the company to scale. At that company and 100 more I've spoken with, it was always done later than it should have been.

The cause of this delay is the lack of a common language between engineers and operational teams. When looking to solve this organizational problem, we set out to fill this gap with Grouparoo. By defining patterns through an open source framework, both sides can engage on consistent footing. This approach makes data enablement easier and adds confidence, the core challenges for the engineers.

I don't have any illusions about how exciting we can make data sync. It's unlikely product engineers will wake up in the morning thinking about Marketo's rate limits. My bar is pretty low.

I just want to make it possible for an engineer to respond with "Oh yeah, what do they need?" instead of "No, thanks." to an integration ask.

This response is a signal that integration work is on an equal footing with other features. At that point, everyone starts to realize the leverage and power of these integrations. They are low-hanging fruit that make a huge difference. Then, they get done, the tools get smarter, everyone has a better experience, and the whole business wins.

Debugging image dimensions with Next.js

Brian Leonard — Wed, 19 May 2021 17:31:57 +0000

I was writing a blog post. In grand engineer tradition, I got distracted while blogging and spent a few hours writing tools to increase blogging efficiency.

Specifically, I was having trouble knowing the correct width and height props to put on the screenshots I was making for the blog post. I would take the screenshot and then use image tools and even a spreadsheet to figure out the right ratio/dimensions for how I wanted it to show up in the UI.

Now, if I get the dimensions wrong (or just want to see the correct ones), it will show it as a little red overlay in development. The banner uses the passed in dimensions to suggest changes that would match either the given height or width.

With the correct sizing, it goes away.

Migration

Next.js has a fancy new image component that requires you pass in these width and height props. These are likely necessary to prevent the page shifting as images load, but if they do not match the ratio of the actual image, it will become distorted as above.

When I was implementing the next/image component the first time, we had to add these props for all of our website images. I made this script that went through all of them and output the true widths, making this spreadsheet.

Then, I went through all our images and filled in the dimension (maxWidth or maxHeight) that I wanted to set. It then gave me the other dimension.

This worked pretty well for the migration.

However, the spreadsheet wasn't working for me as I was writing blog posts, though. I was figuring out the size from the MacOS "Get Info" menu item and adding them to the sheet manually. It took me out of the flow of writing.

Implementation

For example, the code for the logo above was the following:

<Image src="/images/logos/nextjs.png" height={300} width={600} />

The banner is accomplished with a new DebugImage component that adds an an API request after the page loads. The server-side code seems to be needed to actually inspect the actual image on disk.

The component checks with the API:

GET /api/imgdim?w=600&h=300&url=%2Fimages%2Flogos%2Fnextjs.png

{
  "optimized": false,
  "message": "W x H: 600 x 539, 334 x 300",
  "dimensions": [
    { "w": 600, "h": 539 },
    { "w": 334, "h": 300 }
  ],
  "ratio": 1.1136363636363635
}

When it gets fixed (by changing the width to 334):

GET /api/imgdim?w=334&h=300&url=%2Fimages%2Flogos%2Fnextjs.png

{
  "optimized": true,
  "message": "Optimized",
  "dimensions": [
    { "w": 334, "h": 300 },
    { "w": 334, "h": 300 }
  ],
  "ratio": 1.1136363636363635
}

The code in the DebugImage component takes the following steps:

Doesn't do anything unless the NODE_ENV is "development"
Otherwise, wraps the component in a div with no border, padding, etc
If the image is not optimized shows the message in the top left corner

Conclusion

I guess now, I have some work to do...

Maybe there's also a way to catch this in our test suite. There seems to be a few options there:

Use selenium and look for this banner, but that would be pretty slow
Compile the site, but with a stubbed Image component that records what's being used. Compare those dimensions to the ones on disk.

Anyway, I made my original blog post, will make future ones easier, and even got an extra one out of it!

Here is the pull request with all the code.