Episode 04

Headshot of Jeff Veen

with Jeff Veen of True Ventures

In this episode, we’re joined by special guest, Jeff Veen. Jeff shares what he’s learned about the importance of design and performance, we talk about why slow page load speeds are a big problem for content providers, what Facebook is trying to accomplish with Instant Articles, and so much more.

Direct Download

Sponsors:

O’Reilly Velocity Conference - Web performance, optimization, DevOps, continuous delivery, and more. Attend Velocity in Santa Clara May 27-29, New York October 12-14, and Amsterdam October 28-30. Network with engineers & developers and learn from experts to build resilient systems that scale. Register with code 20PATH to save 20%.

Transcript:

Katie Kovalcin:

Welcome! You’re listening to episode four of the Path to Performance, a podcast for everyone dedicated to making the web faster. I’m Katie Kovalcin.

Tim Kadlec:

And I’m Tim Kadlec. This week’s episode is sponsored by Velocity Conference, which actually both Katie and I will be speaking at in just a couple of weeks. Velocity is O’Reilly’s performance conference, actually it is the performance conference as far as I know. There’s not a better event if you’re interested in performance or dev-ops or anything like that, this is the event to be at.

They have three events: one in Santa Clara which is May 27-29 and that’s the one we’ll be at. They have one in New York—October 12-14—and one in Amsterdam also in October—28-30. I don’t know if either of us will be there or not, but you have a couple options depending on where you’re at. It’s a fantastic event, it’s huge, there’s a lot of people there. What I like about it is because of the narrow focus everybody who is there is really passionate about the same thing so you end up having this neverending awesome conversation about performance. You get to hear from other companies about what they’re doing to improve performance, and case studies how they’re selling performance, and building a culture of performance in their organization which is of course of interest to us. Lots of great stuff there. They actually gave us a discount code too: 20PATH, gives you 20% off any of those three events. Highly recommend it, you can get more information at velocityconf.com.

Katie:

Yeah, that’s awesome. I’m super excited to go. We’re gonna hang out, have a good time, you should totally come and meet us.

Tim:

It’ll be good. Yeah, cause you’ve never been?

Katie:

I have not been, this will be my first one.

Tim:

It’ll be good. And then maybe we’ll do that karaoke we threatened. I think maybe we could get Steve Souders and a few other people in on the karaoke thing. Like a performance karaoke roundup.

Katie:

A performance… performance?

Tim:

Ohhhh. I like what you did there. I really like what you did there, Katie. That was good. Yeah, a performance performance. Oh my gosh, why is there not a performance performance event already? Like an after party thing?

Katie:

We’ll make it happen. Point is, you should definitely go. It will be a good time.

Tim:

Absolutely.

Katie:

So, in other news people are talking a lot about this Facebook thing. The Instant Articles. Do you want to give the lowdown on that, Tim?

Tim:

Sure. Yeah, so Facebook announced this new feature it’s iOS only at the moment and it’s only for certain publishers at the moment. They’re calling it instant articles. It’s actually, from Facebook’s perspective, kind of cool. They’re displaying these rich, immersive articles within Facebook instantly as the idea. In fact, that’s what I found most interesting that they’re pushing performance as the major selling feature for this. Their whole pitch is that the mobile web is slow and sites can take up to 8 seconds to load so they’re giving these publishers a way to have their content displayed within Facebook’s little garden and displayed instantaneously without any sort of delay.

Katie:

So… there’s at least one positive there in that a huge company like Facebook is thinking about performance and prioritizing that. That’s really cool. But, there’s also a lot of problems with it which is what a lot of the fuss has been.

Tim:

Yeah. I’m all for the fast as a feature thing. I think that’s awesome, I think that’s great. That’s a huge selling point honestly for anybody who is performance-minded web wise to be able to say “Hey, look. Facebook thinks performance is so important that they built an entire feature because of it” …or at least on the surface. I’m sure having that content within Facebook without ever having you leave I’m sure was a big driving point for them as well. A little Hotel California can never leave action going on. Do you know that song…?

Katie:

[Laughs] I know that’s like a dad rock reference, but I don’t know who it is.

Tim:

[Laughs] Dad rock? Alright. That’s cool. We went from Missy Elliott in one episode to the Eagles in the next. That’s great. What were we talking about, the performance thing?

Yeah, so basically I think it’s nice to be able to say hey look they think performance is so important they’re selling an entire feature based off of it. I’m not a huge fan of closed environments or closed platforms like Facebook so I’ve got my own skepticism there.

Katie:

It’s definitely not as shiny and amazing as at first glance hearing about like “Oh that sounds cool, that sounds like a good time” but it poses a lot of problems with Facebook owning that content of course.

Tim:

And I’m sad. I’m sad that they get to say “mobile sites takes up to 8 seconds to load” so we’re gonna do this cause it’s faster. I’m sad that they get to tout performance as a reason you shouldn’t use the web but instead use the Facebook application. That’s a bummer.

Katie:

Yeah! It’s not like oh we’re all working together to make it faster and to fix this problem. It’s like “Well, here, just hand it over to us and we’ll crank it out faster. Don’t worry about it, your websites can still be slow!”

Tim:

Yeah! That’s the way it feels. It feels like punting on the problem. Jason Grigsby had this tweet about it being so hard for these publishers and it being bad for the publishers that they have no control over making their sites faster but Facebook can do it for them. It’s kind of ironic, if you’re looking at this as a publisher as a way to get your content quickly to the hands of people on a mobile device it’s kind of sad that you’re not then turning around and prioritizing performance on your actual site itself instead of just punting it over to some other environment that’s taking care of it for you.

Katie:

Right, cause also that’s still not the big free open web that everyone can get all the content as fast as we can get it to them. You have to little asterisk, be on Facebook to get that really fast content in an instant. Which is kind of a bummer, I don’t really like having a Facebook. I only reactivated it because of stuff like this that you can only do certain things if you have a Facebook which is not a really cool thing.

Tim:

So, the one thing that is better than we thought when we first were looking at it, the one plus is that the content is still living on those publishers’ sites. It’s being consumed by Facebook and displayed within Facebook but the actual post itself lives on National Geographic or whatever it happens to be. So, I mean that’s kind of nice.

Katie:

But it’s still like “Oh, it can be slow on our site cause Facebook is making it fast.”

Tim:

Exactly! I think what got me fired up about it too is there was another thing recently where Flipkart, which is this big e-commerce thing based out of India, they basically did away with their mobile site entirely and are probably going to do the same thing with their desktop site in lieu of apps. One spokesperson when they were explaining their decision “Well, our app is designed to perform well even in low bandwidth situations unlike our mobile site” and I was like …alright, so, why not [laughs] design your mobile site to work in low bandwidth situations?

Katie:

[Laughs] Yeah, there’s a pretty obvious solution here, everyone.

Tim:

Yeah, I don’t understand. I could really spend a lot of time ranting about this, but for me the thing to come out of this was there’s no reason why sites need to be slow or fat or sluggish from a technical perspective. The browsers are better than ever, standards have improved, our tooling has improved. It gets back to, and probably the reason we started this podcast, is that the real issue is that performance is not prioritized enough. And that gets back to cultural issues, and those are a lot more difficult to change but that’s where the change needs to happen so that we can stop hearing about things like this where a native application is boasting about being 10x faster than a standard website.

Katie:

Yeah. Yeah!

Tim:

Yeah! So listen to this podcast. [Laughs]

Katie:

Yeah, that’s the root of what we’re trying to do!

Tim:

I also notice the irony in telling the people who are listening to this podcast to listen to this podcast.

Katie:

Tell your friends to listen to this podcast.

Tim:

There we go, yeah. That’s better.

Katie:

[Laughs] So I’m really excited to talk to Jeff Veen and learn about all of his awesome experiences at Typekit and Google and True Ventures now so let’s take a quick break and come back with Jeff Veen.

Tim:

That sounds good to me!

Katie:

Cool!

Tim:

Alright and we’re back with Jeff Veen. Jeff, how ya doing?

Jeff Veen:

I’m doing great! How are you guys?

Tim:

Very great. Can’t complain. For those listeners that maybe don’t know you, could you tell us a little bit about yourself and where you’re working?

Jeff:

Yeah, sure I’d be happy to. In fact, relatively recently I got a new job. I am now a design partner at a venture capital firm called True Ventures here in San Francisco, California. Before that, I was at Adobe where I was Vice President of Design. I was there as a result of Adobe acquiring the company that I co-founded called Typekit which did webfonts as a service. I did a lot of stuff before that too but that could just go on all day.

Tim:

Already that’s quite the background. When you say “design partner” just for those who aren’t maybe familiar with that role, what do you do as a design partner at a venture capital firm?

Jeff:

Oh my gosh, nobody would be familiar with that role because I don’t think it existed more than a year ago.

Tim:

Made up titles are the best.

Jeff:

They’re the best, yeah. But I did take the title from a tiny little micro-trend that I saw happening in the industry. So, there’s a variety of different types of partners that can work for a venture capital firm. I noticed I think about a year ago that John Maeda, who used to be the president of the Rhode Island School of Design had moved to the bay area and was a design partner at Kleiner-Perkins and I found that intriguing and started sniffing around trying to find out what he was doing. Then, somebody that I worked with very closely at Google when I was there years ago, Irene Au, she had been the Vice President of User Experience at Google and she had taken the same title at Coastal Ventures. It sort of became this conversation about how design is becoming not just a competitive advantage but a core competency across all kinds of business and that people with perspective and experience on design might be able to help in the investment community to figure out which companies are going to be more viable. Or to help companies that have already been invested in to reduce the risk of that investment by helping them practice better and better design. Which makes better and better products. Which, ostensibly, we all believe affects the bottom line in a really positive way.

Tim:

That makes a lot of sense. And sounds pretty smart. And when you’re talking about design in this sense, you’re not just talking about pixels on the screen and the colors or whatever or shapes they might take, correct? I assume you have a much deeper view of what designing for the web is based on your background.

Jeff:

Yeah. And to be honest not just for the web, it’s even at the level of the very service that a company provides. Most venture capital firms have a pretty diverse portfolio and True Ventures does too. Not just consumer web apps or mobile apps but also cosmetics and bio-tech and all over the place. And all of it can be traced to a user-centered methodology. A user-centered way of thinking that as you point out really transcends interfaces and fonts and colors and things like that.

Tim:

How does performance factor into that? Into your view on design as a holistic approach?

Jeff:

So, there’s a lot of ways to define performance. Do you mean responsiveness of applications and stuff like that?

Tim:

Yeah, when we talk about performance what we’re focusing on a lot is how responsive things are. How quickly things load. Hopefully not a lot of jank in the interface. Those sorts of things.

Jeff:

Oh, yes. Jank. The eliminiation of it.

Tim:

My favorite technical term.

Jeff:

[Laughs] That’s so funny. One of my co-founders at Typekit who was our CTO, Ryan Carver. That’s his favorite term, “We have to get rid of all the jank. This is way too janky.”

Tim:

He interjects it into every random conversation possible?

Jeff:

Absolutely. We could be making coffee and he would.

Tim:

“This coffee machine has too much jank?”

Jeff:

[Laughs] Yes, anyways to get back to your question. Oh my gosh, yes. That was one of the core principles when we founded Typekit is that the addition of typography to a website should in no way affect or decrease the performance of that website. The team that built Typekit was a team that I had worked with very closely at Google. And at Google it’s beyond religion. I don’t even know how to describe how important performance is to Google. It’s almost where they start before anything else is instrumenting for milliseconds and going from there. So, that was a core part of our value and offering was that with Typekit we could actually improve the performance of adding fonts to your website instead of trying to do it yourself. And I thought we were very successful in doing that.

And, yeah. Across the board, I think everybody that embraces that kind of philosophy is ostensibly going to be doing better and seeing better engagement from their users. I mean look at the big news this week has been Instant Articles from Facebook. That was kind of the whole point. Obviously there’s business model implications and advertising dollars and a lot of strategic reasons to do that. But the whole message that they came out with was these are engaging experiences with content that happen instantly. And they were frustrated cause it could take up to 8 seconds to send someone over to see an article on the web. So, they brought it inside with the goal of performance. So, yeah, I can’t stress enough how important that is.

Tim:

Yeah, I don’t know if I’ve seen another company or feature that prominent where performance was so upfront and center in all of the marketing around that feature. I mean I’ve heard “fast” used as a marketing thing before “fast as a feature” but it was clearly the primary thing that they were focusing on and selling and why this new feature they were rolling out was a good thing.

Jeff:

I found that fascinating. It was interesting but the message was much more technical when Flipboard did this with their web app as an SVG app to try to get to 60 frames per second with the scrolling and everything 2-3 months ago?

Tim:

Something like that.

Jeff:

Yeah, and exactly the same thing. Just overall frustrated with performance and looking for any way they can to squeeze every ounce of speed out of their interface.

Katie:

So, this was something that you came into Typekit as a founder thinking this was something that was going to be centrally important. How did that affect all of the design decisions and everything building out from there and what were some of those pain points?

Jeff:

Yeah, it was honestly absolutely core to our architecure of the entire application. It was performance and availability, both of those hand in hand. Because we were kind of making a pretty big promise to our customers in that we were going to essentially host the look and feel of their websites. And these are some big names, we had customers like the New York Times and many, many other significant properties on the web. And to be able to say to them that not only would their performance not decrease but their site wouldn’t look broken and that we wouldn’t go down was key to how we put the architecture together.

And I think one of the most important decisions that we made architecturally was the separation of what we called “delivery” from “configuration.” Which meant that the web app that we created for browsing fonts and looking at specimens and looking at rendering performance and attaching those fonts to selectors in your markup, and doing all of that stuff. That whole website was entirely isolated from the actual serving and content distribution that we did of the fonts and code that goes with them themselves. So, by completely separating those things it took more development effort to keep things in sync and do all of that computer science-y stuff but at the end of the day that meant we could do continuous integration and multiple deploys a day to the web app to make the user-experience of that better without ever touching the fonts that are on the sites of our customers.

Tim:

So this was an internal app that you were using for testing purposes or the way they were setup in general overall?

Jeff:

Overall. Every decision that we made towards the development of the application that was Typekit was around that core value of making sure the fonts are delivered quickly and making sure it never, ever goes down.

Tim:

You had a fairly harrowing story that I believe you told at Velocity at one point about that. [Laughs]

Jeff:

Yeah, that’s right. That’s one of those things that happens probably multiple times in the life of any startup. Where you get some of that happens and some of that step function in scaling a site where all of the sudden one day we’re at 10x which is a problem that every business person wants to have and no engineer ever wants to have [laughs]

So, yeah, we went through that. Nt only did we do individual fonts for individual designers and their websites but we also had an API that we would work with very large partners and they would use that. And one of our partners was announcing an acquisition and got a tremendous amount of traffic and all these new sign-ups and yeah it was one of those moments where you step back and go “alright, are we gonna get through this?” It was the weekend before Christmas and everyone was going on their ski holiday or visiting their families and we’re like no, we have to stay and fix this. So we spent 3 days literally not sleeping doing that re-architecture around certain aspects of our application which we had planned to do but set aside 3 months and instead did it in about 36 hours. So, it’s not only about being clever around architecture but it’s also about developing culture with your team that can weather those sorts of scenarios.

Katie:

So, did you bring a lot of that culture from Google to Typekit to try and get everybody to be able to be excited about that and thinking about that?

Jeff:

Well they certainly weren’t excited about losing their weekend [laughs]

But, yeah to some degree what we picked up working at Google was around engineering excellence. We were generally very design focused and had been for my whole career, I’ve been doing this stuff for 20 years and started my career at Wired Magazine. And design excellence and the deep, deep commitment to user-experience were something that from the very earliest days of my career were drilled into me. But understanding that engineering excellence was part of that user-experience was something that came to me in a big way and a fundamental way when I was at Google for sure.

Tim:

Did you have any difficulty getting people to understand that connection and see that engineering side and design side of things as an interconnected thing versus one piece after another in sort of a waterfall?

Jeff:

At Typekit not really but at Google in the other way. Trying to communicate that the user-experience was bigger than just computing horsepower and performance was very, very difficult at the time. I mean that was 10 years ago that I was at Google and in that 10 years you can really see the shift that has happened with the material design and the consistency across their apps and all of that kind of stuff coming top down from Larry Page who really got that religion a number of years ago and mandated all that stuff happen across all the teams.

But when I was there it was really hard to be a designer and have a seat at the table. The fact that qualitatvive research would yield results that were anywhere near as important as quantitative research was a very difficult conversation. And that investing in even the visual layer of design builds trust with an audience in a way that nothing else does. And that was a very difficult conversation. When I left, I used to tell people that being a designer at Google in the mid 2000s was like being a baseball player in Europe [laughs] everybody had heard of it and knew something about it but had no idea what it was all about.

But when we started Typekit that was our core premise and that was a shared belief and shared value in our early team. So, as we grew, it was a very deliberate part of our culture. Anybody that we would hire whether it was a salesperson or office manager or even the hardcore ops engineer that wears the pager (metaphorically) all of those people would be like “Okay, I work at a place where design is very important” and they would step up. And we would work really hard on having a culture and a vocabulary around design and how we talked about design. And again I’m talking about that whole, almost like fullstack design, but the term “fullstack” is getting abused now. But this idea that design is everything. We would spend as much time with a user-centered methodology to write our terms of service or to negotiate business development deals with partners as we would on the interface because eventually that holistic system is going to create the user-experience that we believe is a differentiator and the best thing we can do for our customers. And that is something that takes a lot of rethinking for a lot of people. Don’t you just get a document from the lawyers and make people click through it? And, no, this is a blueprint for our product and a contract and the start of a relationship with our users, of course we’re going to spend a lot of time on our terms of service! Stuff like that. It’s just down in the DNA all the way through.

Katie:

This is music to my ears having design be the center!

Tim:

[Laughs]

Katie:

Cause Tim is a developer and I’m a designer and when we talk about performance there’s a lot of different conversations to have on both sides. And I think you’re perfectly encapsulating both of those experiences and having each of them being the center. It sounds like having design at the center and projecting that all the way out through performance is what worked really well for you at Typekit.

Jeff:

Yeah, absolutely. It kind of maps to my weird career trajectory. Honestly, 10 years ago or 15 years ago if you asked me if I was going to be a CEO of a company I would have laughed and said of course not. I love design, I love practicing design. But it was through the act of battling contraints that felt artificial that led me to want to control all aspects of everything that goes into product development and ultimately the user-experience. So, if you were trying to accomplish something that you knew was great for users but didn’t work with the business model at the place that you work. Like, you can imagine a designer at one of those publications that has 400 ad banners on the page and a pop-up thing that gets in front of their users that you have to dismiss just to see the content that the designer is working on. That’s at odds. The user-experience and the business model have friction and that’s frustrating. As opposed to starting from the beginning with the user-experience and making such a great user-experience that it informs the business model in a way that is sustainable. That’s the way that I saw being able to achieve what I imagined from a design perspective.

Tim:

That career trajectory you mentioned I think is really interesting. You’ve been at Wired, Google, Adobe and Typekit, and now True Ventures. You’ve had experience at a variety of companies at a variety of levels within those different companies and all the way one of the things that’s been common has been having this focus and understanding of performance being intertwined with the user-experience. You wrote a book in 1999 or 2000.

Jeff:

[Laughs] Shortly after the war, I think.

Tim:

[Laughs] Right. So way back then. In that book, you were even making the case that performance was something you were talking about pretty heavily there. You were talking about being bandwidth challenged and constrained, in 2000 definitely the situation, and being a good thing for design. So, all this time this common theme you’ve had in different companies and different positions within those companies is you’ve understood the two are intertwined. I’m curious how you’ve seen it evolve over the 20 years or so you’ve been involved. How have you seen the conversation move forward or have you?

Jeff:

In some regards, I have and in others I haven’t. It’s both. At the time that I was writing back in the late 90s about all of this stuff, you have to undrestand a big portion of the people online at that time were doing so via modem, via AOL. Sorry, Verizon now. I can’t even believe that! [Laughs]

But it was so slow! I remember watching line by line jpegs and oh my god it was so slow! So, certainly bandwidth has gotten better and better. Frankly, in most parts of the worlds besides the United States it’s gotten better. But what’s been interesting is that we increasingly, the designers who are working today either have fully embraced that change in the way we were thinking and did it from a native perspective. And, we probably have 2 generations now of designers who have only designed for the web and learned design as web design and didn’t have to shift their career like many of us were doing in the 90s. So, that means they come from the perspective of “Well, yeah, of course design is responsive. Of course there’s multiple devices.”

And when we started on the web in 1994, this is forever ago, the notion that you wouldn’t have a fixed page size was so disorienting for most designers. You didn’t have control of fonts, you couldn’t even control the flow of text for crying out loud! So, it was baffling. So, they would push back against that and made stuff that didn’t work very well for web browsers and would just be so slow and so unsuccessful. I think that is one aspect where we’ve had a ton of change. The idea of the native web designer that doesn’t think of it as contraints but just thinks of it as an opportunity to do interesting work.

But on the other hand, as bandwidth grows, and as processing power grows, and as browsers get better we just keep filling everything up. We often lose track of the discipline of now that bandwidth is faster let’s work on making our sites load faster rather than now we can do more with that available bandwidth. But that’s just human nature, that’s always the case. Then we go through a big reset. I think honestly right now there’s a lot of hand-wringing around the web by web designers who have been doing this for a while as they see the changes that are happening in native mobile apps. Just the unbelievable high-performance and the insistence on that high performance from users. And we’re kind of trying to figure that out right now. What’s going to be left to do with the web as mobile apps keep getting better and better and better? I just think it’s such a huge challenge and a wonderful one. And I think that’s going to be our focus for the next few years.

Katie:

So how does that impact your current role now being at a venture capital firm now and all of those decisions around this ambiguous change and everything that’s going on now?

Jeff:

Well, that’s the job [laughs]. Just continuously floating around in ambiguity and wondering what’s next and hoping that your instincts are right about some of that stuff. For me, my entire career, even my early days at Wired where I was writing continuously for Web Monkey my audience and my work has always been around making the tools for the people who make the web. So, if you look at things like we did at Google we designed Google Analytics and Typekit for fonts on the web and Adobe all the Creative Cloud stuff we’re doing, they’re all tools that help people make better stuff for the web. That’s always been my goal.

And so that’s a little bit how I frame up the work that I’m doing now. To be honest, I don’t go to a lot of meetings where the conversation is bio-tech. I find it fascinating, but I have no expertise and experience in that area so that’s not something I feel I can really contribute to. At least at the core at the value proposition for a product there. But when it comes to the layer of tools from the bottom to the top, the layer of tools we use to help make the web whether it’s new kinds of databases or analytics platforms or middleware or frameworks or whatever it is all the way up to new tools that are taking on the new position that Photoshop has always held. That whole stack, I find it absolutely fascinating. I love all of that stuff, I have strong opinions about that stuff. That’s the kind of stuff I look at now.

Tim:

One of the things I’ve been thinking about is tying in this tooling perspective with what you were talking about with the hand-wringing that’s been happening a lot in terms of native and particularly in terms of what we focus on the performance side of things. One of the things I’ve been kind of wondering about is the perception that a lot of people have at the moment that, or really what was really pushed with the Instant Articles thing the performance improvements or with Flipcart in India deciding that the native app was optimized for bandwidth when the website is not. I’m tempted to call those out because you can build fast sites but at the same point is there something to the argument that maybe making things perform on the web versus making things perform well in a native container or inside of some other thing that we need better tooling around that to make that simpler? Are there things we need to be doing in terms of simplifying the process of building performant websites that maybe that’s why things like Instant Articles where the publisher really doesn’t have to do anything to make it perform well is really appealing because of its simplicity?

Jeff:

Yeah, I do. I think we have this web platform right now that by and large to make a regular content page on the web we’re sending 2MB of stuff: frameworks and JavaScript and pre-processing with CSS and Sass and all that. We’re doing all of this stuff to accomodate the diversity and fragmentation in the browser world. It’s frankly much better today than it was 10-15 years ago but it’s still the case. And so what it feels like is when you land on a page out on the open web you are downloading an app almost to present that piece of content. When the content itself might only be less than 100KB or maybe a little more with a few images. But you see what we’re doing there, right? We’re sending over and over again all of this stuff to try to make it easier to develop across what it supposed to be publish once and view anywhere. So, yeah, I think something’s wrong there with all of that.

And I think all Facebook did, well they did two things. One is to setup with publishers a set of constraints. You can’t do everything and you’re not going to load all of these frameworks and banners and banners from different places and all of these tracking and analytics packages on every single page, Typekit included! You’re not going to do any of that stuff, you’re going to design something with basic HTML and CSS and then we’re going to put the entire framework around it but bake it into our app so that nobody has to download it ever.

The other thing I think that they’re doing and I haven’t looked very deeply into this, is that they’re pre-fetching everything in your timeline. Because they know what things you may or may not be able to click on. It’s not like they have the entire internet in their timeline, they just have the stuff that they’re going to display to you so why not just grab all of that beforehand so that literally it can pop up in an instant. So, there’s two places that I think we can get better at making our websites. I don’t have an answer for the previous one for every website sending me a big chunk of React code that I have to download over and over and over again. But I think therein lies the place we’re going to start looking at as we start wringing our hands.

Tim:

Absolutely. I feel like the tooling is certainly a big piece of it. Especially throwing more things at a site. Our stack of tools that we use to build a site has grown incredibly complex and we throw more and more stuff at websites for sure. And there needs to be some sort of return to the norm at some point to simplify that stack instead of overwhelming every site.

Jeff:

Yeah, you’re right.

Tim:

Jeff, this was fantastic. Thank you very much. Are there any parting shots you want to take? If anyone is listening here and looking for gems about building up culture of performance or not overwhelming the sites they’re building now?

Jeff:

I would say that the best design in the world doesn’t matter at all if it never gets to your users. That could come in multiple ways. One is the performance that we’re talking about. The other is just all of the great work that gets left on the floor because designers don’t have enough influence in the organizations that they work for. So, I would encourage the people who are practicing design at least these days, and the same is true for engineering. It’s very fuzzy between design and developers these days and I love that. But I would say honestly keep working to have more control over the work that you do. Keep working to push back on the constraints that are being imposed by the place that you work. We are in an era where designers and developers and anybody regardless of their pedigree or discipline or anything has an opportunity to be an entrepreneur. It’s a very particular way to do your work but it’s also one that affords an amazing opportunity to do the best work you’ve ever done in your life.

Tim:

That’s a fantastic farewell shot.

Katie:

Yeah, that was amazing.

Tim:

Yeah, well done. I’m sure Katie’s okay with that too.

Katie:

That all sounds amazing, designers having more power yay!

[Laughs]

Tim:

Katie’s loving this for sure.

Katie:

Yeah, this has been an amazing interview. I’ve just been listening to everything you have to say and you have such amazing insight and background and experiences to share. I’m really, really happy you were able to take the time to meet with us today.

Jeff:
It’s been super fun, thanks for inviting me!
Tim:

And if people want to follow along after and find out what Jeff’s been up to nowadays where would they do that?

Jeff:

Twitter is the best place and it’s my last name, @Veen.

Tim:

That’s easy enough. Alright, well thank you, sir!

Jeff:

Thanks guys.

Katie:

Bye!

Tim:

Thank you for listening to this episode of the Path to Performance podcast. You can subscribe to the podcast through iTunes or on our site, pathtoperf.com. You can also follow along on Twitter @pathtoperf. We’d love to hear what you thought, so feel free to drop us a note on Twitter or leave a raving and overly-kind review on iTunes. We like to read those. And if you’d like to talk about being a guest or sponsoring a future episode, feel free to email us at hello@pathtoperf.com.